Соло, научи меня | Системный анализ

Почему дорожки в BPMN - это плохо? Рисуйте пулы!🥺 Коллеги, давайте разберем одну из самых частых ошибок в BPMN-диаграммах. Многие системные и бизнес-аналитики рисуют несколько участников внутри одного пула, используя дорожки (Lanes). И получают вместо правильной диаграммы - источник путаницы и неоднозначностей. 💛❤️❤️❤️❤️ 📌 Главное отличие: пул vs дорожка

Пул (Pool) - это независимый участник процесса: организация, внешняя система, клиент. У каждого пула свой собственный процесс.

Дорожка (Lane) - это внутреннее подразделение одного участника: роль, отдел, должность. Дорожки делят один общий процесс и не создают новых границ.

💛❤️❤️❤️❤️ ❌ Почему дорожки - это плохо (когда речь о разных участниках) 🔸Нарушается семантика потоков Внутри одного пула используются потоки управления (Sequence Flow) - сплошные стрелки. Между пулами - потоки сообщений (Message Flow) - пунктирные. Если вы "склеили" несколько пулов в один с дорожками, вы теряете возможность показать, что между участниками происходит обмен сообщениями, а не просто передача управления. 🔸Вводите читателя в заблуждение Когда вы подписываете дорожки как "Пользователь", "Телеграм Бот" и "Нотификатор" - это не роли внутри одной системы, а разные независимые участники. Читатель диаграммы думает, что видит один процесс, а на самом деле - три взаимодействующих. 🔸Нарушаете границы ответственности Дорожки не изолируют процессы - потоки управления свободно пересекают их границы. Это создает иллюзию, что один участник может управлять действиями другого, что не соответствует реальности. 💛❤️❤️❤️❤️ ✔️ Когда использовать пулы Всегда, когда на диаграмме участвуют независимые стороны: ⚫️Разные компании (ваша компания и клиент) ⚫️Разные системы (CRM, ERP, Платежный шлюз) ⚫️Внешние сервисы (Telegram Bot, нотификатор) Каждый такой участник обязательно должен быть отдельным пулом. 💛❤️❤️❤️❤️ ✔️ Когда дорожки уместны Только для внутреннего распределения ответственности внутри одного участника: ⚫️"Наша компания" с дорожками "Менеджер", "Бухгалтерия", "Склад" ⚫️Роли внутри одной системы 💛❤️❤️❤️❤️ 📌 Главный критерий Задайте себе вопрос: могу ли я нарисовать каждый из этих участников как отдельный "черный ящик" с независимой логикой? Если да - это разные пулы, а не дорожки. Дорожки - это про "кто делает" внутри одной организации. Пулы - про "кто участвует" как независимый игрок. 💛❤️❤️❤️❤️ 🔥 🔸🔸🔸🔸 Разделяйте пулы! Это: ⚫️Правит семантику - потоки сообщений vs потоки управления ⚫️Улучшает читаемость - сразу видно, где границы участников ⚫️Облегчает реализацию - разработчики видят четкие интерфейсы взаимодействия А если вам кажется, что диаграмма с пулами занимает слишком много места - используйте свернутые пулы для участников, чей внутренний процесс неважен. 💛💛💛💛💛💛 А вы сталкивались с такой ошибкой? Как объясняете коллегам разницу между пулами и дорожками? Делитесь в комментариях! 🤩 #bpmn #системныйанализ #бизнесаналитик #бизнеспроцесс

Внеплановый даунтайм или почему бэкенд в горах стабильнее, чем фронтенд в аэропорту🥺 Тайм-аут на восстановление ресурсов закончился, возвращаюсь в прод. Получилось галопом по Европам, но тем не менее: маленький фотоотчет  в стрим. Краткий системный анализ поездки по Дагестану (без воды, только сухие факты и баги). 🙂Что зашло (Acceptance Criteria пройдены): 1. Ландшафт (бэкенд-архитектура). Реальная природа - это вам не плоский монитор... Основное время провели в горах, масштаб, к которому мы привыкли в распределенных системах, здесь выглядит иначе. Впечатляет, когда серверные мощности развернуты вертикально на 3000 метров. 2. Юзер-экспириенс (Community). Люди - огонь. Доброжелательность, гостеприимство и отменное чувство юмора. Похоже, местный софт зашит на уровне ядра, без багов и зависаний. Приятное исключение из правил. 3. Еда (энергоэффективность). Отвал башки. Если честно, я думал, что знаю толк в мясе, но местный стек технологий в кулинарии - это хардкор. Калибровка вкусовых рецепторов прошла на ура. 🙂Что не зашло (Баг-репорт): 1. Тайминги (Дедлайны). Катастрофически мало времени. Заказчик (семья) требовал фичи, а мы успевали только базовый функционал. Галоп по Европам это не про релакс, а про деплой в пятницу вечером. 2. Сеть (Транспортный уровень). Самолет задержали и туда, и обратно. Ожидаемо, принимаем как legacy-код, с которым ничего не сделаешь, но осадочек все равно остаётся. 3. Sleep-режим. Спал мало, нагрузка на CPU была выше 90%😒 Устал как собака, но эмоциональный кеш переполнен. Футбол же еще.. Итоговый вывод (Ретроспектива): Мы обязательно вернемся в этот дата-центр. Возьмем больше итераций (дней) и пересмотрим спринт, чтобы программа была не бешеной, а больше похожей на Agile с постоянным рефакторингом отдыха. Кстати, задержка рейса навеяла мысль: если бы самолеты были распределенными системами, они бы задерживались хотя бы с нормальным логгированием ошибок, а не просто технические причины. ©️ Кто был в Дагестане - ставьте плюс Кто не был - на заметку, маппинг маршрутов делаю.

Угадаешь куда лечу, привезу магнитик💪 На сколько задержут рейс, ставь ставки в комментариях🍴🤣

Немного лирики🤪 Чем выше ваш уровень в системном анализе, тем меньше разница в базовых навыках. Когда ты переходишь на уровень Senior или Lead, оказывается, что харды уже не являются главным конкурентным преимуществом. С каждым шагом вверх требования становятся только жестче. И ценится уже не тот, кто просто больше читает про паттерны или пишет многостраничные ТЗ. 💃 Все достаточно быстро мапят бизнес-процессы в BPMN 💃 Все достаточно сильны в декомпозиции требований и SQL 💃 Все умеют описывать интеграции и проектировать API на высоком уровне Казалось бы, база у всех одинаковая. Но почему тогда одни аналитики тащат сложные проекты, а другие буксуют? Решающими становятся детали: 🙂Умение видеть неочевидные edge-case'ы и узкие места до того, как они упадут на проде. 🙂Понимание истинного бизнес-контекста, а не просто слепой перенос хотелок заказчика в постановку. 🙂Фокус на нефункциональных требованиях и архитектуре. 🙂Soft skills: способность услышать стейкхолдера и договориться там, где кажется, что это невозможно.

База - это просто пропуск. Системное мышление и внимание к контексту - это то, что делает вас незаменимым.

Именно на проработку этих самых деталей и системного мышления я делаю упор в менторских сессиях. Если хотите вырасти из крепкого Middle в сильного Senior - welcome💪 #системный_анализ #жизньаналитика #bpmn #системныйаналитик

Монолит, SOA и микросервисы: в чём разница😤 Вопрос, на котором плывёт половина джунов на собеседовании, а зря, ведь это база. Аналитик проектирует ещё и то, как система разбита на части и как эти части общаются между собой. Разберём три подхода на одном сквозном примере: платформа зарядок для электромобилей. Функции внутри всегда одни: авторизация, управление станциями, пользователи, бронирования, биллинг, уведомления. Меняется только то, как они разложены по коду и базам данных. Монолит, всё в одной кодовой базе🥺 Все модули живут внутри одного приложения и деплоятся вместе. БД: обычно одна общая. Интеграции: компоненты общаются прямо в коде, внутренние API между ними не нужны. Кому подходит: старту, MVP, небольшим проектам. Быстро разрабатывать и выкатывать. Где болит: вырос - тяжело менять, упала одна часть - рискует всё приложение, масштабируется только целиком. SOA, система из крупных сервисов🤪 Функции вынесены в отдельные сервисы, они общаются через сеть: по API, через шину данных (ESB) или брокеры. БД: у сервиса может быть своя, а может быть общая сразу на несколько. Кому подходит: средним и крупным системам, где важна доступность и производительность отдельных частей. MSA, много мелких независимых сервисов🤪 Каждый микросервис отвечает за одну бизнес-функцию. Общаются по лёгким протоколам (REST, gRPC) плюс брокеры для асинхронности, сверху API Gateway. БД: у каждого своя собственная. Кому подходит: большим и быстро растущим продуктам. Но сопровождать дорого, нужна сильная команда. Как отличить SOA от микросервисов за один вопрос Их постоянно путают. Держите разграничитель: могут ли два сервиса делить одну базу данных? 🙂В SOA могут, общая БД тут в порядке вещей. 🙂В MSA нельзя, у каждого микросервиса своя БД, и точка. Микросервисы мельче по функциональности, чем сервисы в SOA. По сути MSA - та же идея SOA, доведённая до предела: дробим мельче и убираем общие базы ради полной независимости. Что выбрать🤪 Архитектуру подбирают под нефункциональные требования и стадию продукта. На практике часто стартуют с монолита, а через 3-5 лет переезжают на SOA как первый шаг дробления на микросервисы. И все эти решения аналитик фиксирует в документации: схемы, контракты API, правила развития. Собрал по теме методичку, 20 слайдов: три архитектуры на сквозном примере, схемы, сравнительная таблица и разбор, как выбирать. Напиши коммент, как отдавать тебе методичку? За лайки, за деньги, за просто так?😴 #ТеорияБезВоды #Архитектура #Микросервисы #СистемныйАнализ #Обучение #СолоНаучиМеня

👍 Аналитика для маленьких: объясняем UML бабушке Новая рубрика: беру страшный термин с собеса и объясняю на пальцах🤩 Сегодня - UML. Если совсем просто: это язык чертежей для проектов. Словами всё описать тяжело и долго, поэтому некоторые аналитики рисуют схемы - чтобы заказчик и разработчики поняли друг друга одинаково. Как чертёж здания: по нему и строят. На примере ремонта. Ты, бабуль, заказчик. Я - аналитик. Рабочие - разработчики. Чтобы всё не развалилось, нам нужны три чертежа: Чего хотим? Просто переклеить обои или ещё и плитку менять? Сначала давай договоримся, что вообще делаем. Из чего делаем? Опись: стол, стул, лампа. Чтобы я и бригада не путали табуретку с барным стулом. В каком порядке? Сначала обои снять, потом шпаклевать, потом клеить. Свет → вода → розетки. Местами не поменяешь. Вот и весь UML. Это мост между "хочу" заказчика и "сделаю" разработчика. Нет моста - получаешь розетку под потолком и дверь, которая бьёт тебя в лоб. P.S. Если захотите загуглить/вспомнить - по-взрослому эти три чертежа называются Use Case, Class Diagram и Sequence Diagram. Но бабушке это знать необязательно🙂 💬 А вы какой аналогией объясняли свою работу не-айтишникам? Делитесь - соберём ТОП🤣 📎 Шпаргалки по UML #системныйаналитик #шпаргалка #сменапрофессии

👍 Аналитика для маленьких: объясняем UML бабушке Новая рубрика: беру страшный термин с собеса и объясняю на пальцах🤩 Сегодня - UML. Если совсем просто: это язык чертежей для проектов. Словами всё описать тяжело и долго, поэтому некоторые аналитики рисуют схемы - чтобы заказчик и разработчики поняли друг друга одинаково. Как чертёж здания: по нему и строят. На примере ремонта. Ты, бабуль, заказчик. Я - аналитик. Рабочие - разработчики. Чтобы всё не развалилось, нам нужны три чертежа: Чего хотим? Просто переклеить обои или ещё и плитку менять? Сначала давай договоримся, что вообще делаем. Из чего делаем? Опись: стол, стул, лампа. Чтобы я и бригада не путали табуретку с барным стулом. В каком порядке? Сначала обои снять, потом шпаклевать, потом клеить. Свет → вода → розетки. Местами не поменяешь. Вот и весь UML. Это мост между "хочу" заказчика и "сделаю" разработчика. Нет моста - получаешь розетку под потолком и дверь, которая бьёт тебя в лоб. P.S. Если захотите загуглить/вспомнить - по-взрослому эти три чертежа называются Use Case, Class Diagram и Sequence Diagram. Но бабушке это знать необязательно🙂 💬 А вы какой аналогией объясняли свою работу не-айтишникам? Делитесь - соберём ТОП🤣 📎 Шпаргалки по UML

🔮 Залип на выходных и собрал вам имбу Знаете эти колоды... Таро? Только моя - не про любовь и судьбу, а про наши будни. Вместо "казённого дома" - упавшее демо, вместо "дальней дороги" - интеграция, которую заказчик назвал "просто одно поле". 22 карты, коты-аналитики и предсказания, в которых вы себя узнаете. Например: 🌙 "Актуальная документация есть. Она в голове у Сергея. Сергей уволился в марте." 😶 "Демо пойдёт как по маслу. Ровно до вопроса из зала, который ты не предусмотрел" Вытяните свою карту дня 👇 🔗 solo-teach.github.io/oracle #таро #таро@solo_teach #системный_анализ #системныйаналитик

Вас подводили плохо сформулированные требования?😤 Написал об этом тут #системный_анализ

BMW X1 🙂🙂🙂🙂, или почему нельзя показывать пользователю то, чего он не должен видеть😐 На днях заказывал на свою 🚗 заднюю полуось - для владельца не новой 🤓 это считай ритуал, что-то всегда отваливается, главное успевать заказывать. Ну и.. оформил заказ, жду подтверждение, падает на почту письмо, открываю, а там в графе модель написано X1 null 😐 Сижу и думаю, надо же.. не знал, что у меня такая редкая комплектация. На самом деле это не комплектация и не пасхалка для своих, это значение прямиком из базы данных, которое спокойно дошло до клиента. У модели есть поле под модификацию, в этом заказе оно пустое, в базе там лежит null. А в шаблоне письма кто-то просто склеил строку, "модель плюс пробел плюс модификация", и про пустое значение никто не подумал. Система честно подставила то, что было, и клиент получил "X1 null" Многие скажут.. баг разработчика, проглядел. Отчасти да, но корень глубже. Разработчик сделал ровно то, что было в требованиях, а в требованиях про пустое поле не было ни слова. Никто не описал, что показывать, когда показывать нечего, прятать графу целиком, ставить прочерк, оставлять пусто. Этого вопроса просто не задали на этапе анализа, поэтому система и повела себя как умела🤗 Вот эта мелочь и есть работа системного аналитика. Описать не только счастливый сценарий, когда все поля заполнены и красиво, но и пустые состояния, когда данных нет. Пользователь не должен видеть null, undefined, NaN и прочую внутреннюю кухню, для него это просто мусор на экране, который подрывает доверие ко всему сервису. Если в письме клиенту вылезает null, дело редко в кривой вёрстке, чаще это симптом непроработанной документации и пропущенного сценария. 👍Запчасть мне, к слову, привезли, правильную, несмотря на то, что письмо подкачало. #системныйаналитик #системный_анализ #соло_досуг

😠 Ты в QA? Следующий грейд - системный аналитик. Ты уже знаешь продукт изнутри лучше многих в команде! Осталось научиться не находить требования, а создавать их😐 Практикум "НСА 2.0" - переход из тестирования в системный анализ: ⚫️ требования, UML, BPMN, SQL, REST API ⚫️ практика в Jira, Confluence, DBeaver ⚫️ портфолио + диплom, помощь с резюме и топ-50 вопросов с собеседований ⚫️ ведут практики: 15 лет в IT Системные аналитики зарабатывают заметно больше QA - а опыт тестировщика тут твоё преимущество, а не старт с нуля. 👌 Программа и набор на новый поток: https://new-sa.ru/qa Идёт 2-й поток, набираем третий. Места ограничены.

👍 Освободилось 2 места в личное менторство Читаешь это в обеденный перерыв в офисе, до которого добирался час в набитом транспорте? Тогда дочитай до конца.. Я каждый день вижу одно и то же: умные, способные люди годами сидят не на своём месте. Не потому, что не тянут - а потому, что им никто не показал дорогу. Я прошёл этот путь сам и теперь провожу по нему за руку. 😳 Что значит "выйти на удалёнку и жить в удовольствие" 🙂утром ты не бежишь на электричку, а спокойно пьёшь кофе 🙂в обед - не столовая, а прогулка или зал 🙂география больше не диктует тебе зарплату 🙂ты сам решаешь, где жить: город, дом у моря, другая страна 🙂и при этом получаешь больше, чем на "стабильной" офисной работе Чем отличается менторство: 🙂маршрут под ТЕБЯ, а не «для всех» 🙂разбираем реальные ТЗ, API, диаграммы 🙂готовлю к собеседованиям и репетирую их 🙂помогаю с резюме и откликами - до оффера 🙂отвечаю между встречами, а не "через неделю" 🥺 Почему всего 2 места Это работа руками, а не вебинар на тысячу человек. Освободилось ровно два места - закроются, и следующего набора придётся ждать. 😐 Пиши "МЕНТОР" в личку - расскажу детали, посмотрим твою точку старта. Бесплатно и ни к чему не обязывает, можем просто поболтать 😁 #менторство #системныйанализ #удалёнка #сменапрофессии #СолоНаучиМеня

Ванечка пишет свой первый эндпоинт🤗 После того как Ванечка разобрался с use case и user story, ему доверили первое настоящее дело - спроектировать REST API для справочника пользователей. Ванечка вывел: GET /v1/users/{id} Красота! По-взрослому, как в учебнике. Через день прилетел вопрос от разработчика: "А {id} - это id чего? Пользователя? Его карточки в CRM? Внешний id партнёра? У нас их три, я не угадаю." 😄 Единорог материализовался над клавиатурой, с пиццей под мышкой: Помнишь наши пиццы и client_id? Представь, ты кричишь курьеру: "Готово номер пять!" Пятый столик? Пятый заказ? Пиццу №5 из меню? ❌ GET /v1/users/{id} ✔️ GET /v1/users/{user_id} Назови сущность прямо в параметре. Заявка → {request_id}, заказ → {order_id}. Самодокументируемый эндпоинт экономит десятки вопросов в чате. 💡 Что запомнить: • {id} - это "номер пять": непонятно, чего именно • В path-параметре всегда называйте сущность • Best practice - это про то, чтобы тебя поняли с первого раза 👍 А у вас как принято - {id} или {user_id}? #ВанечкаИЕдинорог #СистемныйАнализ #REST #API #Обучение

Схемы и диаграммы: рисовать или не рисовать. Вот в чём вопрос🥺 Финальный пост цикла  и, наверное, самый спорный. Потому что сейчас я пойду немного вразрез с классическими учебниками🙂 Что говорит стандарт. Если используете диаграммы - оформляйте их через PlantUML и прячьте под макрос "Раскрыть". PlantUML - это код, а не картинка: его можно версионировать, а макрос не перегружает полотно документа. А теперь секрет из практики. В ТЗ для API мы полностью отказались от Sequence-диаграмм. Совсем. И вот почему. Ловушка рассинхрона (Desync). Как красивая диаграмма превращается в исторический артефакт: 🗓 День 0 - нарисовали красивый сиквенс 🗓 Спринт 1 - добавили кеширование, текст обновили, разработчик закодил 🗓 Спринт 2 - поменяли маппинг, добавили вызов… а про диаграмму все забыли 🗓 Через полгода - диаграмма врёт, и ей перестали верить Наше решение - текст как единый источник истины. Для описания внутренней логики метода я оставил только текст - тот самый чёткий алгоритм из Блока 3: 🙂 если / иначе 🙂 локальные ПЕРЕМЕННЫЕ 🙂 явные переходы к шагам 🙂 маппинги под "Раскрыть" Такой текст читается и обновляется в 10 раз быстрее, чем PlantUML А когда диаграммы всё-таки нужны? Я их не отрицаю - просто знаю им место: 🙂Интеграция - высокоуровневые взаимодействия между сервисами 🙂Архитектура - на груминге быстро показать процессы 🙂Бизнес-процессы — BPMN для глобальных процессов А для конкретного REST-метода - только текст, только хардкор. Не рисуем сиквенс, не вставляем PlantUML внутрь метода, не плодим устаревшие картинки. Описываем алгоритм текстом в формате Блока 3. Цикл завершён. Спасибо, что были со мной🤗 Что мы разобрали: 🙂 Скелет идеального ТЗ 🙂 Блок 1 — Бизнес-цель 🙂 Блок 2.1 — Параметры запроса 🙂 Блок 2.2–2.4 — Ответ и ошибки 🙂 Блок 3 — Логика работы 🙂 Блок 4 — Схемы и диаграммы Какой блок зашёл больше всего? Пишите в комментариях 🙂 #тзапи #системныйаналитик #изхзделаютз

#соло_досуг Вернулись из Николы-Ленивца – и это было нечто. Останавливались в "Скворчках", уютных домиках в лесу, откуда рукой подать до главных арт-объектов парка. Просыпаешься, выходишь на крыльцо – а вокруг тишина, туман над полями и только ветер в кронах🥰 Хозяева Скворчков – душевные до мурашек. Лена уже писала про них отзыв на Яндексе, и каждое слово – правда. Встречают как родных, и чувствуешь себя желанным гостем. 🏃‍♂️В парк мы пошли пешком, от велосипедов отказались – и, как оказалось, правильно. Через километр пути нас накрыл ливень. Не просто дождь, а настоящий водопад с неба. Он то утихал, выглядывало солнце, мы начинали подсыхать – и тут же снова заряжало. Тропинки превратились в ручьи, кроссовки хлюпали, как губки. И знаете что? Мы шли и улыбались до ушей. Промокшие, грязные, но невероятно счастливые. Вокруг – лес, поля и знаменитые арт-объекты Николы-Ленивца. Они здесь такие, будто не люди их поставили, а они сами выросли из мха и корней. Каждый хочется рассматривать и трогать, про каждый можно рассказывать полчаса. Огромные конструкции из веток, сено, дерево – всё дышит и живёт вместе с природой. Но самый мощный момент – храм 1802 года. Мы зашли внутрь и оказались там совсем одни. Только мы двое, тишина и эхо веков. Стоишь, дышишь – и время останавливается🤩 Если соберётесь туда – напишите мне, я с огромным удовольствием подскажу, какой домик выбрать и у кого бронировать. Эти выходные мы запомним надолго. Никола-Ленивец – это про свободу, стихию и настоящее единение с природой. #НиколаЛенивец #Скворчки #Звизжи

🥺Логика работы метода: как написать алгоритм, по которому код напишется сам Когда-то я писал в ТЗ "делаем маппинг данных из БД" - и считал, что задача описана. А потом получал шквал вопросов от разработки и QA: 🙂А если в БД null? 🙂А если записей несколько? 🙂Откуда вообще берём поле X? 🙂Какие приоритеты у источников? Я понял: хороший стандарт закрывает эти вопросы на берегу, а не в чате во время разработки. Вот как устроен Блок 3. 3.1 Авторизация и 3.2 Валидация - не изобретаем велосипед. Готовые блоки вставляются макросом "Включить выборку": "401 - Авторизация KeyCloak", "400 - Валидация вх. параметров". Если доп. бизнес-валидации нет - так и пишем: ОТСУТСТВУЕТ 3.3 Алгоритм - 5 железных правил: 🙂 если / иначе - каждая ветка закрыта 🙂 Локальные переменные - имена КИРИЛЛИЦЕЙ в верхнем регистре 🙂 Навигация - явные "перейти к шагу N" 🙂 Глубина - не больше 3 уровней вложенности 🙂 Маппинги - под макрос "Раскрыть" Локальные переменные различаю сразу: ССЫЛКА - одиночное значение из шага N, ЗАПРОСЫ[] - массив. Кириллица в верхнем регистре мгновенно отличает переменную алгоритма от поля БД или JSON. Что даёт чёткий алгоритм: ✔️ QA сразу видит негативные кейсы ✔️ Разработчик понимает, что переиспользовать ✔️ Бэкенд не ходит в БД дважды ✔️ Текст ТЗ читается линейно Алгоритм = предсказуемый код. И спокойный сон аналитика. А у вас бывало безумное ТЗ? Расскажите в комментариях🤗 #системныйаналитик #системный_анализ #системныйанализ