Event Storming — это фасилитируемая сессия, где команда на одном полотне собирает события предметной области (что реально происходит в бизнесе), чтобы быстро сделать анализ бизнес-процессов, найти пробелы в требованиях и договориться о модели системы без месяцев переписок и «как-нибудь потом уточним».

Если вы когда-нибудь пытались описать процесс «как проходит заказ» в интернет-магазине, а на третьем созвоне выяснялось, что «оплата» бывает в 7 вариантах, то вы уже знаете, зачем появился event storming. Это способ не спорить о терминах, а вытащить факты: что случилось, когда случилось и что меняется в системе.

Для новичков в IT это спасает от типичной боли: вы читаете требования, а там вместо логики — легенда. Для тех, кто уже в разработке 1–3 года, это хороший способ перестать быть «программистом по заявкам» и начать говорить на языке предметки (домена), как BA/SA/PO. Кстати, такие тексты и практики я регулярно разбираю на https://itokno.ru — без обещаний «войти в IT за 2 недели», только земля и цифры.

Что такое Event Storming и почему его путают с “нарисуем BPMN”

Event Storming придумал Альберто Брандолини в DDD (Domain-Driven Design, предметно-ориентированное проектирование). База простая: событие домена — это факт, который уже произошёл и важен бизнесу: «Заказ создан», «Оплата подтверждена», «Товар отгружен», «Возврат оформлен».

В отличие от BPMN/регламентов, вы начинаете не с “кто что делает”, а с “что в итоге случается”. Это резко снижает количество «фантомных требований»: когда в документе есть действие, но непонятно, какой бизнес-результат оно фиксирует в системе.

• Event Storming: вытаскивает реальность и конфликтующие версии процесса за 1–2 часа.
• BPMN: хорошо фиксирует согласованный процесс, но плохо добывает его из голов.
• User Story Mapping: помогает разложить продукт по пользователям и шагам, но не всегда видит внутренние события и правила.

Подводный камень: пытаться “сразу рисовать идеальный процесс”. Event Storming ценен тем, что сначала показывает бардак. Это не баг, это фича.

Event Storming анализ бизнес-процессов: пошаговый гид (без магии и с понятными артефактами)

Шаг 0. Подготовка: кого звать и что принести

Тезис: качество сессии определяется составом участников, а не цветом стикеров.

Кого звать: 1 фасилитатор (часто BA/SA/PO), 2–4 эксперта бизнеса (операции, поддержка, бухгалтерия/финансы — по ситуации), 2–4 технаря (разработчик, тестировщик, аналитик, архитектор). Если у вас российская реальность с 1С, то зовите человека, который реально знает, где в 1С “живут” статусы документов, иначе будете моделировать сказку.

Формат: офлайн — идеален (стена + бумага), онлайн — ок (Miro/аналог), но нужен строгий таймбокс.

Вывод: лучше 8 людей на 2 часа, чем 25 людей на 4 часа. Большая толпа не даёт больше правды, она даёт больше микрофонов.

Подводный камень: не позвать поддержку/операторов. А потом внезапно выяснить, что 30% заказов обрабатываются «вручную в исключениях».

Шаг 1. Собираем события (Domain Events): “что произошло”

Тезис: события — это скелет процесса, а не его фантазия.

Все участники пишут события в прошедшем времени: «Счёт выставлен», «Платёж получен», «Накладная проведена», «Чек пробит», «Заказ отменён по инициативе покупателя», «Возврат денег выполнен». В российском e‑com/ритейле всегда всплывают нюансы: касса, маркировка (Честный ЗНАК), частичные отгрузки, постоплата, возвраты через разные платёжные шлюзы.

Вывод: пока не спорим. Просто выкладываем «ленту событий» слева направо (временная ось).

Подводный камень: смешивать события с командами. «Отгрузить товар» — команда (что хотим сделать), «Товар отгружен» — событие (что уже стало фактом).

Шаг 2. Ставим “боли” и вопросы: hot spots

Тезис: Event Storming нужен не ради красивой стены, а ради обнаружения неопределённости.

Поверх событий добавляем маркеры проблем: где часто случаются ошибки, где ручные операции, где «непонятно кто ответственный», где данные не сходятся между CRM, 1С и складом. В России типовой конфликт: CRM считает заказ “оплачен”, а 1С не видит подтверждение платежа, потому что интеграция живёт своей жизнью (точнее, падает по ночам).

Вывод: это список тем для уточнения требований, а ещё — зачаток бэклога рисков.

Подводный камень: пытаться “решить всё на сессии”. Задача — назвать проблему, а не провести терапию интеграций.

Шаг 3. Добавляем команды и акторов: кто инициирует изменения

Тезис: команда (Command) отвечает на вопрос “кто и зачем инициирует событие”.

Пример: команда «Подтвердить оплату» может исходить от платёжного провайдера, кассы, оператора, или быть автоматической. Если актор — внешний сервис (СБП, эквайринг банка), фиксируем это явно. Дальше связываем: Команда → (система выполняет) → Событие.

Вывод: вы начинаете видеть границы ответственности и точки интеграций.

Подводный камень: забыть “внешний мир”. А он потом приходит в виде инцидента: “банк прислал статус задним числом”.

Шаг 4. Политики и правила: почему событие вообще случилось

Тезис: правила (Policy/Business Rules) превращают набор событий в управляемую систему.

Например: «Если оплата не подтверждена 30 минут — заказ переводится в “ожидание”, резерв на складе снимается». Или: «Если возврат частичный — формируется корректировочный чек». Эти правила — главный источник “скрытых требований”.

Вывод: получаете список бизнес-правил, который можно тестировать и автоматизировать.

Подводный камень: правила остаются “в головах” у одного сотрудника. До первого отпуска.

Шаг 5. Агрегаты/границы (DDD): где заканчивается одна ответственность и начинается другая

Тезис: границы (Bounded Context) помогают не строить «единую систему всего».

После базовой сессии часто видно, что “Заказ”, “Оплата”, “Доставка”, “Возвраты” живут по разным законам. Это кандидаты на отдельные контексты/подсистемы. В реальности это может означать: отдельный сервис, отдельный модуль в монолите, отдельный контур в 1С + интеграция через шину/очередь.

Вывод: меньше связности, меньше случайных побочных эффектов при изменениях.

Подводный камень: резать на микросервисы “потому что модно”. Event Storming не про моду, а про границы ответственности.

Два кейса из практики: как выглядит польза (и как выглядит провал)

Кейс “взлетело”: интернет-магазин + 1С + склад

Сессия на 2,5 часа. На стене нашли 14 разных вариантов “оплаты” (карта, СБП, постоплата, частичная, подарочный сертификат, оплата юрлицом и т.д.). Ключевой инсайт: событие «Оплата подтверждена» для бизнеса ≠ «Деньги захолдированы». После фиксации событий и правил команда переписала интеграционный контракт: какие статусы и когда считаются окончательными.

Результат: меньше отмен “по технической причине”, меньше ручных сверок с бухгалтерией. И самое важное — требования перестали быть романом, стали списком проверяемых фактов.

Кейс “не взлетело”: 20 человек, 4 часа, ноль решений

Собрали всех, включая тех, кто “просто посмотреть”. События писали в настоящем времени (“проверяем”, “звоним”), спорили о названиях, фасилитатора не было. Итог: красивая стена и ощущение активности, но ни одного списка вопросов, ни одного решения по границам, ни одного артефакта для разработки.

Причина: перепутали Event Storming с корпоративным тимбилдингом.

Таблица: что вы получаете на выходе и как это монетизируется в карьере

Коммерческая реальность: сколько это стоит и почему “бесплатно на созвоне” дороже

Event Storming можно провести без бюджета (переговорка + стикеры), но стоимость — в людях. 8 участников × 2 часа = 16 человеко-часов. Если усреднить внутреннюю стоимость часа хотя бы в 1500–3000 ₽ (для смешанной команды в РФ это не выглядит фантастикой), одна сессия “стоит” 24–48 тысяч ₽. И это нормально, потому что одна крупная ошибка в требованиях обычно стоит дороже: переписать интеграцию, откатить релиз, разгрести поддержку.

• Скрытая цена №1: отсутствие фасилитатора — сессия превращается в спор “кто прав”.
• Скрытая цена №2: не зафиксировали выводы в Confluence/Notion/таск-трекере — через неделю всё улетучилось.
• Скрытая цена №3: зовёте только IT — получаете модель системы, а не модель бизнеса. Потом бизнес удивляется.

Экспертный вердикт и инструмент вместо рекламы

Event Storming — лучший “ускоритель правды” для сложных процессов, где много исключений, интеграций и ручных действий. Он особенно полезен, когда вы начинаете проект, переделываете легаси (например, связку CRM + 1С) или не понимаете, почему в проде всё “как-то не так, хотя по ТЗ было правильно”.

Мини-чеклист: 7 вопросов перед тем, как проводить (или идти на) Event Storming

1. Какой процесс моделируем и где его границы (от чего до чего)?
2. Кто реально знает, как процесс выполняется руками (операторы/поддержка/бухгалтерия)?
3. Какие внешние системы участвуют (банк, касса, 1С, склад, доставка)?
4. Какие “статусы” считаются финальными, а какие предварительными?
5. Где у нас больше всего возвратов/отмен/ручных корректировок?
6. Какие 5 ключевых бизнес-правил обязательно должны быть формализованы?
7. Как мы зафиксируем результат: список решений, открытых вопросов, следующий шаг?

Если вы “перебежчик” в IT: учитесь формулировать события и правила — это прямой мост в бизнес-анализ и системный анализ. Если вы джун/мидл разработчик: потренируйтесь отделять команды от событий и видеть границы контекстов — это повышает вашу ценность сильнее, чем ещё один фреймворк “в копилку”.

Частые вопросы