Business | System analyst

Event Storming: как за один сеанс вытащить из бизнеса всё что нужно Салют! Расскажу про технику, которая перевернула мой подход к сбору требований. Я до неё несколько лет ходила на интервью с бизнесом по старинке — вопрос-ответ, протокол, снова вопрос. Долго, сухо, и всё равно что-то важное всплывало уже в процессе разработки. Потом познакомилась с Event Storming. И поняла что теряла время. ❓ Что это вообще такое Event Storming — это фасилитационная техника, которую придумал Альберто Брандолини в 2013 году. Суть простая: вы собираете в одной комнате всех причастных — бизнес, разработку, аналитику — и вместе моделируете процесс через события. Не через функции системы. Не через экраны. Через события — то, что происходит в бизнесе. Главный материал — стикеры. Цвет каждого имеет значение. Язык стикеров — запомните один раз 🟠 Оранжевый — доменное событие Что-то произошло в системе. Формулируется в прошедшем времени: “Заказ создан”, “Оплата подтверждена”, “Товар отгружен” 🔵 Синий — команда Действие, которое инициирует событие: “Создать заказ”, “Подтвердить оплату” 🟡 Жёлтый — актор Кто выполняет команду: пользователь, менеджер, система 🟣 Фиолетовый — политика Правило или реакция: “Когда заказ создан — отправить уведомление” 🔴 Красный — проблема или вопрос То, что непонятно прямо сейчас. Не пытаемся решить на месте — фиксируем и идём дальше. Как проходит сессия — по шагам: Шаг 1. Хаотичный штурм — 20-30 минут Все участники одновременно пишут оранжевые стикеры — доменные события. Без порядка, без очерёдности. Просто всё что происходит в процессе. Здесь важно не останавливать поток. Дубли — нормально, противоречия — отлично, значит нашли точку для обсуждения. Шаг 2. Выстраиваем хронологию Берём все события и раскладываем на стене слева направо — по времени. Именно здесь начинается самое интересное: бизнес видит свой процесс целиком, часто впервые. И сам находит дыры. Шаг 3. Добавляем команды и акторов К каждому событию добавляем — кто и что сделал чтобы оно произошло. Здесь выясняется кто реально принимает решения, а не кто написан в регламенте. Шаг 4. Фиксируем политики и проблемы Правила бизнеса, автоматические реакции, спорные моменты — всё на стикеры. Красных стикеров не бойтесь, чем их больше — тем честнее сессия. Живой пример: интернет-магазин Вот фрагмент того, что получается на стене: [Пользователь] → Оформить заказ → 🟠 Заказ создан → 🟣 Когда заказ создан — проверить наличие товара → 🟠 Наличие подтверждено → [Система] → Создать платёж → 🟠 Платёж инициирован → 🟠 Оплата подтверждена → 🟣 Когда оплата подтверждена — передать в склад → 🟠 Заказ передан на сборку И вот тут кто-нибудь из бизнеса обязательно скажет: “Стоп, а если товара нет — что происходит?” И выясняется, что этот сценарий никто не описал. Вешаем красный стикер. За один такой вечер находим больше пробелов, чем за месяц переписки в почте. Почему это работает лучше классических интервью На интервью бизнес отвечает на ваши вопросы — то есть вы ограничены тем, что догадались спросить. На Event Storming бизнес сам моделирует свой процесс и сам видит где он не доработан. Аналитик здесь не интервьюер, а фасилитатор. Вы не задаёте вопросы — вы создаёте условия чтобы знания вышли наружу сами. Когда это особенно полезно — Старт нового проекта когда процессы ещё не описаны — Сложные интеграции между несколькими командами — Когда разные отделы по-разному понимают один и тот же процесс — Рефакторинг legacy-системы где документации нет вообще Что важно для хорошей сессии Несколько вещей которые я поняла уже на практике, не из книжек: — Зовите всех кто принимает решения, не только исполнителей. Без ЛПР сессия даёт половину результата — Физическая стена и стикеры работают лучше любого онлайн-инструмента. Miro — только если нет выбора — Сессия не должна длиться больше 4 часов. После люди перестают думать — Фасилитатор не эксперт в предметной области — и это хорошо. Глупые вопросы вскрывают самые интересные противоречия Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Хочешь сделать хорошо — сделай сам: как у нас появилась собственная система работы со стендами ⏳ 12 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

Как читать чужую документацию на API, чтобы не наступить на грабли Салют! Решила еще написать пару постов на тему API и рассказать случай из практики:

Получаю как-то документацию на внешнее API — для интеграции с платёжным сервисом. Открываю Swagger, всё красиво, эндпоинты на месте. Согласовываю интеграцию, передаю в разработку. Через две недели разработчик приходит с вопросом: “А что возвращает API если платёж завис в статусе pending дольше часа?” И тут выясняется — в документации этого нет вообще. Ни слова. Хорошая документация — редкость. Поэтому аналитик должен уметь читать её критически, а не просто принимать как есть.

Вот на что я теперь смотрю в первую очередь: 1. Есть ли вообще схема ошибок Если описаны только успешные ответы — это красный флаг. Спрашиваю прямо: “пришлите список всех кодов ошибок и их тела ответов”. Если в ответ тишина или “ну, обычно 400 и 500” — закладываю время на уточнения в процессе разработки. Они будут точно. 2. Что значит “опциональное” поле на самом деле Поле помечено как optional. Окей, а что если его не передать? — Подставится дефолт? — Просто проигнорируется? — Или вернётся ошибка, потому что поле опциональное только формально, а по факту обязательное при определённых условиях? Третий вариант встречается чаще, чем хотелось бы. Проверяю на реальном запросе, документации на слово не верю. 3. Идемпотентность — спрашиваю прямо Если интеграция создаёт сущности — платёж, заказ, бронирование — обязательно уточняю: что при повторном запросе с теми же данными? Дубль? Та же сущность вернётся? Для платежей это критично — повторный запрос из-за обрыва сети не должен списать деньги дважды. Если в документации об этом ни слова, это не значит что идемпотентности нет. Значит, про неё просто забыли написать. Спрашиваю у владельцев API напрямую, не додумываю сама. 4. Лимиты и троттлинг Сколько запросов в секунду разрешено? Что происходит при превышении — 429 Too Many Requests, как и положено по спецификации? Или, как бывает на практике, сервис просто молча обрывает соединение либо отдаёт 503? Это нужно знать заранее, а не выяснять на проде в пятницу вечером. 5. Версионирование — какая версия актуальна на самом деле Иногда документация описывает v2, а в реальности эндпоинт всё ещё на v1, потому что миграция не завершена. Смотрю дату последнего обновления документации. Если её нет — тоже звоночек. 6. Тестовая среда — её поведение реально совпадает с продом? Самое неприятное открытие — когда на тестовом стенде всё работает идеально, а на проде логика чуть другая. Уточняю у поставщика API: гарантируется ли идентичность тестовой и боевой среды, или есть нюансы, о которых стоит знать заранее. Документация — это обещание. Но обещания не всегда выполняют полностью. Задача аналитика — найти дыры до того, как их найдёт разработчик в проде, а не после. 🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией)) ___________ Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

ТЗ на API: что написать, чтобы разработчик не придумывал за вас Однажды я получила от разработчика готовый эндпоинт, который работал. Технически. Но в таком формате, что фронт не мог его использовать без дополнительного преобразования. Когда спросила почему — пожал плечами: “в ТЗ не было написано как, я сделал как удобнее”.

И знаете что? Он был прав.

С тех пор у меня есть чеклист того, что обязательно должно быть в ТЗ на API. Делюсь. 1️⃣ Название и назначение Не “создать API для заказов”, а конкретно:

Эндпоинт: Создание заказа
Используется: мобильное приложение, личный кабинет
Контекст “кто вызывает” влияет на авторизацию и требования к нагрузке.

2️⃣ Метод и URL

POST /api/v1/orders

Точный адрес, метод, версия. Без этого разработчик придумает сам. 3️⃣ Авторизация

Bearer token (JWT)
Authorization: Bearer {token}

Не написали — получите либо открытый эндпоинт, либо неожиданную схему авторизации. 4️⃣ Тело запроса Каждое поле с типом, обязательностью и ограничениями:

{
  "userId": 123,       // integer, обязательное
  "items": [...],      // array, обязательное, min: 1
  "comment": "..."     // string, необязательное, max: 500
}

Для необязательных полей — что происходит если не передали? Дефолт? Игнорируется? Напишите явно. 5️⃣ Ответ при успехе

HTTP 201 Created
{
  "orderId": 789,
  "status": "created",
  "createdAt": "2026-06-17T10:00:00Z" // UTC, ISO 8601
}

Формат даты фиксируйте явно — иначе получите локальное время сервера и долгие поиски расхождений. 6️⃣ Ошибки — то, что забывают в 80% ТЗ 422 - Не передан обязательный параметр 404 - Пользователь не найден 401 - Нет авторизации 409 - Товар недоступен Для каждого кода — тело ответа с понятным error code. Договоритесь о едином формате ошибок на весь проект и зафиксируйте один раз. 7️⃣ Бизнес-логика Самое недооценённое. Структура понятна — но что происходит внутри? Пишите явно: заказ создаётся только если все товары в наличии, после создания резервируется остаток, уходит email-уведомление. Если этого нет в ТЗ — разработчик придумает сам. Иногда угадывает. Чаще нет. 8️⃣ Нефункциональные требования

Таймаут: не более 2 секунд
Нагрузка: до 100 запросов в минуту

Если нужна защита от дублей — опишите механизм явно через Idempotency-Key в заголовке. Само собой не появится. Хорошее ТЗ — это не формальность. Это единственный способ получить то, что вы имели в виду, а не то, что разработчик имел в виду за вас 🙂 🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией)) ___________ Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Что такое нейросети и как они устроены под капотом (на пальцах, с примерами на python) ⏳ 6 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

3 бесплатных курса, 30+ уроков, 100+ задач 🫠 Кажется, Симулейтив сошли с ума, они отдают бесплатно три курса, за которые многие берут деньги. Если вы хотите прокачаться в аналитике данных - начните с бесплатных курсов по самым важным разделам. Именно эти блоки помогут вам вкатиться в профессию, спрос на которую не падает из года в год. В наборе вы получите: 🐍 Основы Python — 10 уроков, 100+ практических задач, 3 проекта для портфолио. Реальные кейсы: аналитика продуктовых метрик, автоматизация обработки чеков. Спойлер: именно с этого начинается карьера аналитика. 🗄 Основы SQL — 12 уроков, 70 задач на PostgreSQL, оконные функции, финальный проект. Без SQL не возьмут ни на одну позицию, связанную с данными. 🐼 Pandas — библиотека, которую аналитик использует каждый день. ABC/XYZ-анализ, EDA, динамика продаж, реальный проект на данных аптечной сети. Всё это с нуля, с поддержкой в чате и доступом сразу после регистрации. Забирайте, пока не передумали 👉 [Забрать набор курсов]

Дарим подарки нашим подписчикам 🎁 Мы с ребятами решили порадовать вас интересными подарками от наших каналов: - Внешний жесткий диск - Настольная игра от Школы Систем Аналист - Футболка BA | SA Условия максимально простые: - подписаться на каналы; - нажать «участвую». 1. Системный анализ | Ольга Пономарева 2. Business | System analyst 3. Analyst IT 07.07 в 17:00 мы проведем розыгрыш и троим из вас улыбнется удача)))

Средовой подход вместо системного: как проектировать ИТ-продукты, которые растят сами себя ⏳ 12 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

Системный аналитик помогает бизнесу и разработке говорить на одном языке: разбирает задачи компании, описывает требования, проектирует IT-решения и следит, чтобы система работала на реальные цели бизнеса. Онлайн-магистратура СПбГУ и Нетологии «Системный анализ и интеллектуальные системы управления бизнес-процессами» готовит специалистов на стыке IT и управления. В программе сочетаются академическая база СПбГУ и прикладные инструменты Нетологии. Студенты изучают математическое моделирование, алгоритмы, системный анализ, Python, BI-системы, no-code-инструменты, управление проектами и подходы к внедрению искусственного интеллекта. Такой набор навыков помогает работать со сложными бизнес-процессами: находить узкие места, снижать риски при разработке, формулировать требования к системам и сопровождать внедрение IT-решений. Обучение проходит полностью онлайн. После выпуска вы получаете диплом магистра СПбГУ очного образца по направлению «Прикладная информатика». Подробнее о программе Реклама. ООО “Нетология” ОГРН 1207700135884 Erid: 2VSb5yADhXg

Год назад я думал, что ИИ заменит архитектора. Я ошибался ⏳ 15 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Займи слот ИТ-Пикником от Т-Банка 8 августа — время отложить ноутбуки и встретиться офлайн на ИТ-Пикнике от Т-Банка в музее-заповеднике «Коломенское». Вот сколько всего запланировано: — научпоп-лекции; — мастер-классы; — дискуссии об ИИ и больших языковых моделях; — доклады о кибербезопасности; — примеры, как данные из логов становятся решениями; — много музыки. Бери с собой друзей, супругов и детей — каждый найдет себе что-то по душе. Зарегистрироваться и узнать больше можно здесь

Реалтайм-аналитика «без боли»: миграция из PostgreSQL и Kafka в ClickHouse и визуализация в Superset ⏳ 21 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

⚠️Профессия системного аналитика продолжает меняться: появляются новые инструменты, растут требования к качеству решений, усиливается роль аналитика в проектировании архитектуры и взаимодействии с бизнесом. При этом одни навыки становятся критически важными для карьерного роста, а другие постепенно превращаются в базовый минимум. ✅Мы подготовили для вас актуальную программу обучения на курсе «Системный аналитик. Управление командой». Изучите программу обучения на сайте. 🎁Записывайтесь на бесплатный вебинар: «Какие навыки прокачать, чтобы стать экспертом в системном анализе в 2026 году». ⏰25 июня в 20:00 мск Задайте вопросы спикеру и познакомьтесь подробнее с программой обучения на живом вебинаре! Перейти на сайт ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Что на самом деле мешает работе с ИИ Типичный сценарий выглядит так: в ChatGPT ставится задача, прикладываются документы, объясняются внутренние термины, уточняется актуальный регламент — и только после этого появляется полезный ответ. Через день все начинается заново. Может показаться, что проблема в промптах, что нужно просто лучше формулировать запросы. Но дело не в этом. Обычный чат не знает компанию. Не знает регламенты, требования, протоколы встреч и накопленный контекст. Поэтому каждый новый диалог начинается с ручной передачи знаний, которые уже давно существуют внутри организации. Чем больше документов и процессов появляется в компании, тем заметнее становится проблема. ИИ используется для ускорения работы, но значительная часть времени по-прежнему уходит на объяснение того, что система должна знать сама. Поэтому главный вопрос сегодня уже не «как правильно писать промпты». Главный вопрос — как дать ИИ доступ к знаниям компании. 23 июня пройдет бесплатный вебинар от karpovꓸcourses, на котором покажут, как устроен ИИ-ассистент, который работает с регламентами, требованиями, протоколами встреч и базой знаний компании. И почему обычным промптингом такого эффекта не добиться. Узнайте, как дать ИИ доступ к знаниям компании и перестать объяснять одно и то же в каждом чате: https://clc.to/erid_2W5zFGPpEYH Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFGPpEYH

Плохое ТЗ — это не вина одного человека. Это результат работы команды ⏳ 10 мини | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

🔥24 июня в 20.00 мск. приглашаем на открытый урок: "Отказоустойчивый и высоко-доступный кластер RabbitMQ" На вебинаре разберём практические подходы к созданию отказоустойчивой и высоко-доступной очереди сообщений для высоконагруженных систем. 📌 Что будет: — Запуск и настройка кластера: Quorum Queues и Mirrored Queues (синхронная репликация) — Синхронизация очередей и обеспечение согласованности — Dead Letter Queue + правильные настройки durability — Гарантии доставки для Producer: баланс между надёжностью и производительностью — Asynchronous cluster-to-cluster message routing: Exchange Federation и Shovels 🎯 После вебинара вы сможете: — Самостоятельно развернуть отказоустойчивый кластер RabbitMQ — Настраивать Quorum Queues и Mirrored Queues под разные сценарии — Правильно работать с Dead Letter Queues и гарантиями доставки — Организовывать межкластерное взаимодействие сообщений — Проектировать надёжные асинхронные коммуникации в микросервисной архитектуре 👉 Регистрация открыта: https://clck.ru/3UErYW Вебинар приурочен к старту курса «Высоконагруженные системы: архитектура и масштабирование». 🎁При покупке курса вы получите в подарок мини-курс по Kafka, который поможет подготовиться к собеседованию в бигтех Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

AIналитик v2 по BABOK: как я переписал AI-платформу для бизнес-анализа, чтобы она работала c любыми LLM ⏳ 16 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

Архитектурный крест: как приручить System Design interview ⏳ 10 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

Салют! Хочу тоже затронуть тему, проектировать REST API и рассказать на своем примере Знаете, что меня до сих пор выбивает из равновесия? Когда на ревью спрашиваешь разработчика: “почему эндпоинт называется именно так?” — и в ответ: “ну, так исторически сложилось” 🤯 За 10 лет я слышала это столько раз, что уже завела внутренний счётчик. 🚨 Давайте разберём REST API нормально — один раз, по-человечески, с примером. Сначала главное: REST — это не технология, это договорённость REST — архитектурный стиль. Просто набор правил о том, как клиент и сервер общаются через HTTP. И первое правило, которое нарушают чаще всего — ресурсы именуются существительными, не глаголами. ❌ Так не надо:

POST /getUser
POST /createOrder
GET  /deleteProduct?id=5

✅ Так правильно:

GET    /users/{id}
POST   /orders
DELETE /products/{id}

HTTP-методы сами несут смысл действия — GET получить, POST создать, PUT/PATCH обновить, DELETE удалить. Глагол в URL — это дублирование, которое потом запутает всех, включая вас саму через полгода. 💡 Живой пример: API интернет-магазина Есть товары, заказы, пользователи. Поехали. Базовые операции:

GET    /products        — список товаров
GET    /products/{id}   — конкретный товар
POST   /products        — создать товар
PATCH  /products/{id}   — обновить часть данных
DELETE /products/{id}   — удалить товар

Здесь сразу вопрос, который почти никогда не задают вслух: PUT или PATCH? PUT — заменяет ресурс целиком и обязан быть идемпотентным — то есть хоть десять раз вызови с одними данными, результат одинаковый PATCH — обновляет только то, что передали На практике PATCH выигрывает почти всегда — никто не хочет слать весь объект ради изменения одного поля статуса. Вложенные ресурсы — и вот тут начинается самое интересное Заказ принадлежит пользователю. Отражаем это в структуре:

GET  /users/{userId}/orders             — все заказы пользователя
GET  /users/{userId}/orders/{orderId}   — конкретный заказ
POST /users/{userId}/orders             — создать заказ

Но если заказы нужны и сами по себе — например, в админке — добавляем отдельно:

GET /orders/{id}

И вот моё личное правило, выстраданное на проектах: Вложенность глубже двух уровней — тревожный сигнал. Если у вас /users/{id}/orders/{orderId}/items/{itemId}/reviews — это не REST, это маршрут до боли. Коды ответов — то, на что аналитики машут рукой зря “Разработчик разберётся” — нет. Или разберётся по-своему, и тогда фронт получает 200 с телом {"error": true} и тихо плачет. Минимальный джентльменский набор: 200 - Успешный GET, PATCH, PUT 201 - Успешный POST — ресурс создан 204 - Успешный DELETE — тело пустое 400 - Синтаксически сломанный запрос (битый JSON и т.п.) 401 - Не авторизован 403 - Авторизован, но нет прав 404 - Ресурс не найден 409 - Конфликт (дубль email, например) 422 - Запрос понят, но данные не прошли валидацию 500 - Ошибка сервера Отдельно про 400 vs 422 — это путают постоянно. 400 — когда запрос синтаксически сломан, сервер вообще не смог его прочитать. 422 — запрос понятен, но внутри что-то не то: поле обязательное, формат не тот, логика не сходится. Для ошибок валидации форм почти всегда нужен именно 422. И 401 vs 403 — классика жанра: 401 = “кто ты вообще?”, 403 = “знаю кто ты, но нет”. Формат ошибки — договоритесь до начала разработки Лучший момент для этого — старт проекта. Худший — когда фронт уже написал сорок обработчиков. ✅ Хорошо:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Поле email обязательно",
    "field": "email"
  }
}

❌ Плохо: Второй вариант — это не API, это квест.

{
  "status": false,
  "msg": "err"
}

Версионирование — заложите сразу API когда-нибудь изменится. Поменяется логика, добавятся поля, что-то удалится. Если не заложить версионирование с самого начала — первое же обновление превратится в боль для всех. Самый простой и понятный способ:

/api/v1/products
/api/v2/products

___________ Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

System Design: проектируем Rate Limiter, ограничитель запросов ⏳ 29 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA