Event Storming для сбора требований: сценарий воркшопа

Зачем проводить Event Storming для требований

Event Storming помогает собирать требования там, где знания о процессе распределены по людям, а «как оно работает» спрятано в чатах, письмах и в голове у ключевых сотрудников. Вместо длинного документа вы быстро получаете общую картину: что реально происходит, где возникают задержки и почему разные команды по-разному понимают одни и те же слова.

Чаще всего метод снимает три боли. Первая - разрозненные требования: каждый помнит свой кусок, но никто не видит процесс целиком. Вторая - терминология: «заявка», «заказ», «счет» могут означать разное для продаж, бухгалтерии и ИТ. Третья - скрытые исключения: «а если клиент меняет адрес», «а если поставка частичная», «а если нет согласования» обычно всплывают только когда вы проходите цепочку событий шаг за шагом.

Метод особенно полезен, когда нужно синхронизировать процесс между несколькими ролями и быстро понять, где автоматизация даст ощутимый эффект. Например, при запуске внутреннего сервиса для обработки обращений: поддержка описывает шаги «как принято», разработка думает категориями статусов, а руководителю нужны метрики. Карта событий помогает всем говорить об одном и том же, а не спорить о формулировках.

Но это не универсальный инструмент. Если задача небольшая и понятная, быстрее провести короткие интервью и сразу набросать макет. Если команда еще не договорилась о целях продукта или нужно проверить пользовательский сценарий на «живых» людях, прототипирование и тесты дадут больше пользы.

Успех сессии стоит мерить не количеством стикеров, а результатами:

• есть общая лента процесса от начала до конца, включая частые исключения;
• согласован словарь ключевых терминов (что именно означает каждое слово);
• видны узкие места и вопросы, которые нужно уточнить после воркшопа;
• команда может перейти от карты событий к списку задач без потери смысла.

Если эти пункты выполнены, дальше уже проще выделять команды, агрегаты и превращать обсуждение в реальный backlog.

Какие артефакты вы должны получить на выходе

Ценность сессии не в том, что вы «поговорили», а в том, что у команды остаются артефакты, по которым можно продолжать работу без повторного пересказа. Они должны быть одинаково понятны бизнесу и разработке.

Доменные события - это факты, которые уже произошли, поэтому они формулируются в прошедшем времени: «Заказ оформлен», «Счет выставлен», «Поставка подтверждена». Такая форма дисциплинирует: вы фиксируете результат изменения, а не обсуждаете намерения или экраны интерфейса.

Команды отличаются от событий тем, что инициируют изменение. Это действие, которое кто-то запускает: человек, внешний сервис или регламентный процесс. Команда обычно звучит как глагол в повелительном наклонении: «Оформить заказ», «Проверить лимит бюджета», «Подтвердить отгрузку». Событие отвечает на вопрос «что уже стало правдой», команда - «что нужно сделать, чтобы это произошло».

Агрегат (DDD) простыми словами - это граница, внутри которой правила должны соблюдаться согласованно. Внутри агрегата данные меняются вместе и по одним правилам, а снаружи другие части системы не должны напрямую эти правила обходить. Например, в процессе закупки агрегатом может быть «Заказ»: у него есть статус, позиции и допустимые переходы (нельзя «Подтвердить поставку», если заказ не «Оплачен»).

После воркшопа у вас должен остаться набор вещей, которые легко перенести в рабочие документы и превратить в план разработки:

• карта событий (хронология) с ключевыми ветками и вариантами;
• список команд, привязанных к событиям, с явными инициаторами (роль или система);
• черновые агрегаты и их границы (где правила, где статусы, где нельзя делать «напрямую»);
• отдельный список спорных мест: разногласия по терминам, правилам, ответственности;
• гипотезы и открытые вопросы: что нужно уточнить у юристов, безопасности, бухгалтерии, пользователей.

Простой признак качества: если через день после сессии вы можете открыть карту и ответить «какие 5-10 вещей строим первыми и почему», значит артефакты получились рабочими. Если остались только стрелки и общие слова без событий, команд и правил, сессию придется повторить.

Подготовка: люди, границы, материалы

Сильная сессия начинается не со стикеров, а с выбора правильного процесса. Для сбора требований лучше брать один поток ценности, который можно пройти от начала до конца за время встречи. Если попытаться охватить сразу продажи, склад, бухгалтерию и поддержку, получится длинная стена и мало договоренностей.

Заранее определите границы: где процесс стартует (триггер, входящий запрос, событие), где заканчивается (что считаем «успехом»), и что точно вне рамок. Помогает прием «записать исключения заранее»: 3-5 типовых «а если…». Например, если вы разбираете «закупку и ввод в эксплуатацию серверов для организации», гарантийные ремонты или списание оборудования лучше вынести в отдельную сессию.

Состав участников должен отражать реальную работу процесса, а не оргструктуру. Обычно достаточно 6-10 человек: владелец процесса/продукт-оунер, представитель операций, аналитик, разработчик, QA. Важно, чтобы среди участников были и те, кто принимает решения, и те, кто выполняет работу каждый день.

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

Материалы держите простыми. Офлайн нужна стена, стикеры и маркеры. Онлайн подойдет любая доска, где удобно перетаскивать карточки и видно курсоры участников. Обычно хватает 3-4 цветов (события, команды, вопросы, заметки) и трех правил именования:

• события - в прошедшем времени («Заказ подтвержден»);
• команды - в повелительном («Подтвердить заказ»);
• агрегаты - существительные («Заказ», «Счет»).

Если готовы границы, люди и материалы, сессия идет быстрее, а результатом становятся понятные события, команды, агрегаты и список работ для команды.

Пошаговый формат сессии (1 день или 2 по 2 часа)

Этот формат подходит, когда вы хотите закончить не просто «картой на стене», а понятными следующими шагами.

Вариант на 1 день (примерно 3,5-5 часов чистого времени)

Начните с короткого открытия: зачем вы собрались и что считается успехом сегодня (например: согласованная карта событий, список вопросов к бизнесу, черновик backlog). Сразу договоритесь о правилах: события пишем в прошедшем времени, спор о формулировках не держим дольше пары минут, все спорное помечаем и идем дальше.

Дальше двигайтесь по шагам, сохраняя темп:

• Лента событий: участники выкладывают доменные события по времени, объединяют дубли, выравнивают порядок.
• Боли и неизвестное: рядом отмечают вопросы, ручные шаги, места, где «часто ломается».
• Команды и акторы: для ключевых событий добавляют, кто инициирует действие и какая команда к нему ведет.
• Системы и интеграции: помечают, где автоматизация, где ручная передача, какие внешние системы участвуют.

Чтобы не утонуть в деталях, держите принцип «сначала ширина, потом глубина». Сначала закройте цепочку от начала до конца, затем углубляйтесь в самые важные 3-5 узлов.

Короткий пример для B2B-процессов поставки: «Запрос на поставку ПК получен» -> «Коммерческое предложение отправлено» -> «Договор подписан» -> «Поставка отгружена» -> «Оборудование принято» -> «Поддержка зарегистрирована». На каждом шаге обычно быстро проявляются ручные согласования, права подписи и интеграции (CRM, учет, сервис-деск).

Вариант: 2 сессии по 2 часа

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

Между сессиями назначьте одного человека (часто аналитик или фасилитатор), который приведет карту в порядок: перепишет события единым стилем, уберет явные повторы, сгруппирует вопросы в 5-10 тем и отметит 3-5 узких мест, куда вы точно вернетесь.

Закрытие в любом формате держите жестким по времени. За 15-20 минут зафиксируйте: что согласовано, какие вопросы остались открыты (и у кого мяч), что команда берет в проработку первой волной. Это экономит недели переписки после воркшопа.

Как перейти от событий к командам и агрегатам

Когда карта событий готова, ее нужно превратить из истории в модель, с которой может работать команда: команды (commands) и агрегаты. Не пытайтесь «спроектировать» все сразу. Идите от смысла и правил, которые уже проявились на стене.

От событий к смысловым блокам и границам агрегатов

Сгруппируйте события в небольшие фрагменты, отвечающие на вопрос: «Про что этот кусок процесса и кто за него отвечает?» Обычно блоки возникают вокруг одной цели: оформить заказ, согласовать, отгрузить, принять, закрыть.

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

Признаки удачного агрегата:

• одна ответственность (не «все про клиента», а «заказ», «поставка», «акт приемки»);
• единые правила рядом, а не размазаны по системе;
• минимальный размер: внутри только то, что нужно, чтобы соблюсти правила и зафиксировать изменения;
• понятный «владелец» изменений: кто может менять состояние и при каких условиях.

Как из событий получить команды и действия

Команда - это намерение что-то сделать, которое приводит к событию (или отказу, если правило нарушено). Для каждого события спросите: «Что должно было быть сделано, чтобы это случилось?» и «Кто инициирует: пользователь, система, внешний контрагент?» Так вы получите и пользовательские действия, и команды уровня API.

Держите команды в форме «глагол + объект + уточнение»: «Создать заказ», «Подтвердить заказ», «Отменить заказ по причине», «Зарегистрировать отгрузку». Если команда не приводит к событию, скорее всего, она слишком техническая или описывает чтение.

Короткая проверка качества команды:

• есть явный инициатор (роль или система);
• понятно, какой агрегат она меняет;
• понятно, какие данные нужны на вход;
• можно ожидать конкретные события на выход.

Фиксация инвариантов рядом с агрегатом

Инварианты записывайте рядом с агрегатом короткими формулировками: «нельзя», «всегда», «только если». Это превращает карту в набор правил, которые потом станут тестами.

Пример из процесса поставки оборудования: события «Заказ создан», «Заказ согласован», «Поставка отгружена», «Приемка подтверждена» часто показывают два агрегата - «Заказ» и «Поставка». Рядом с «Заказом» фиксируйте: «нельзя отгрузить, пока не согласовано», «только если есть лимит бюджета», «всегда сохраняем причину отмены». Рядом с «Поставкой»: «нельзя подтвердить приемку без серийных номеров», «только если отгрузка зарегистрирована».

Так вы получаете связку: событие -> команда -> агрегат + инварианты. Это и есть мост от карты к задачам.

Как собрать backlog по результатам Event Storming

Карта превращается в backlog, когда вы переводите события в понятные единицы работы: эпики, истории и задачи, которые команда может оценить и взять в спринт.

Сначала «нарежьте» карту на логичные куски. Эпики удобно строить либо по участкам процесса («заказ», «оплата», «доставка»), либо по ключевым агрегатам («Заказ», «Счет», «Отгрузка»). Выберите один основной подход, а второй используйте как проверку, чтобы не потерять важные границы.

Дальше превращайте цепочки событий в истории. Хороший прием: берите цель пользователя и проверяйте, какие события должны случиться, чтобы цель считалась достигнутой. Если на карте видны провалы или спорные места, это тоже попадает в backlog как исследовательская задача.

Рабочий шаблон:

• выбрать один сценарий от начала до конца (happy path);
• сформулировать 1-3 истории, которые запускают и завершают этот сценарий;
• добавить задачи на интеграции, которые разблокируют следующий шаг;
• выписать риски и неизвестности как spike/исследование;
• повторить для исключений (ошибки, отмены, возвраты, частичные поставки).

Acceptance criteria удобно писать через события, потому что они проверяемые. Формат простой: «когда произошло X, должно появиться Y». Например: «Когда событие “Заявка одобрена”, должно появиться “Заявка передана в закупку”, а статус в системе меняется на “В работе”».

Приоритизацию держите на трех осях: ценность, риск, разблокирование. Ценность - то, что дает пользователю результат. Риск - то, что может дорого сломаться (правила, деньги, безопасность, юридика). Разблокирование - интеграции и инфраструктура, без которых остальные задачи не поедут.

Пример сценария: от карты событий до первых задач

Представьте воркшоп про процесс закупки и поставки ИТ-оборудования для учреждения: от появления потребности до приемки и закрывающих документов. Это типовая история, когда организация закупает ПК или серверы, проходит стандартные согласования, получает поставку и оформляет документы.

На стене появляется цепочка доменных событий: «Заявка создана» -> «Бюджет подтвержден» -> «Поставщик выбран» -> «Договор подписан» -> «Оборудование поставлено» -> «Акт принят». Сразу отмечайте развилки: что происходит, если бюджет не подтвержден, если поставка частичная, если акт не подписан из-за брака.

Дальше превращайте ключевые события в команды: «Создать заявку» приводит к «Заявка создана», «Согласовать бюджет» к «Бюджет подтвержден», «Выбрать поставщика» к «Поставщик выбран», «Зарегистрировать поставку» к «Оборудование поставлено». Здесь же уточняйте инициатора и место проверки правил (лимиты, полномочия, сроки).

Затем обозначьте кандидатов в агрегаты, чтобы понять, где живет состояние и какие правила должны соблюдаться согласованно. В этом сценарии обычно всплывают: «Заявка» (позиции, суммы, статусы), «Договор» (реквизиты, условия, версии), «Поставка» (накладные, партии, серийники), «Приемка» (результаты проверки, замечания, акт).

После этого уже можно собрать первый backlog. Не пытайтесь расписать все сразу: цель первого релиза - провести сквозной путь для самых частых случаев.

• Заявка: создание, список позиций, статусы «Черновик/Отправлена»
• Бюджет: правила лимитов, маршрут согласующих, фиксация подтверждения
• Выбор поставщика: критерии, протокол выбора, фиксация решения
• Договор: карточка, подписание (дата/номер), переходы статуса
• Поставка и приемка: регистрация факта поставки, частичная поставка, акт принят/отклонен

Чтобы добрать до 10-15 задач, разбейте каждый пункт на 2-3 конкретных истории: роли и права, поля и валидации, статусы и переходы, уведомления, простые отчеты, плюс 1-2 интеграции (например, справочник номенклатуры и контрагентов). Так у команды появится понятный первый релиз, а карта останется опорной точкой для следующих итераций.

Фасилитация: как удержать темп и договориться о терминах

Фасилитация держится на простом принципе: сначала фиксируем доменные события, потом обсуждаем детали. Если группа рано уходит в схемы, статусы, поля и интеграции, карта перестает расти, а участники быстро устают.

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

Набор правил, который обычно работает:

• события пишем в прошедшем времени: «Заказ подтвержден», «Сервер отгружен», «Запрос в поддержку зарегистрирован»;
• спорим только о том, что влияет на событие или его порядок; остальное отправляем в «вопросы»;
• одна карточка - одна мысль; не помещается - значит это две карточки;
• если застряли, включаем таймер и принимаем решение или переносим в «парковку».

Конфликты терминов неизбежны. Задача фасилитатора не «решить за всех», а дать группе безопасный способ договориться. Рабочая техника: фиксируйте альтернативы рядом («клиент» vs «заказчик», «отгрузка» vs «передача в доставку») и задавайте вопрос: «Какое слово используем на этой карте сегодня, чтобы двигаться дальше?» Временное определение помогает сохранить темп, а «официальное» уходит в список вопросов.

Чтобы вовлекать тихих участников, делайте паузы и задавайте адресные вопросы без давления: «Что происходит сразу после этого в вашей части процесса?» или «Как вы узнаете, что это событие случилось?» Хорошо работает «по кругу на 30 секунд», когда каждый добавляет по одному событию или уточнению. Для доминирующих участников держите рамку: фиксируйте мысль на карточке и возвращайте слово группе.

Таймбоксы спасают от бесконечных дискуссий. Практичный вариант для конфликтных моментов:

• 5 минут: сформулировать два варианта определения или порядка событий;
• 3 минуты: назвать последствия каждого варианта;
• 2 минуты: выбрать рабочий вариант на сегодня и назначить владельца вопроса.

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

Частые ошибки и ловушки

Самая частая проблема - потеря цели. Вы вроде собираете требования, но через час обсуждаете все подряд: исключения, интеграции, отчеты, будущие релизы. Держите рамку: какой процесс, какой продуктовый кусок и какой горизонт по времени вы разбираете.

Типовые ошибки и быстрые способы поправить ситуацию:

• Слишком широкий охват. Если на стене одновременно продажи, бухгалтерия, логистика и поддержка, остановитесь и выберите один поток ценности. Остальное вынесите в отдельный воркшоп.
• Смешивание событий и действий. «Клиент оплатил и мы отправили» - это два факта. Событие - то, что уже случилось, команда - то, что делают, чтобы событие произошло.
• Уход в проектирование БД и экранов. «В таблице будет поле status» и «давайте нарисуем форму» слишком рано. Сначала договоритесь о событиях, правилах и границах ответственности.
• Нет владельца процесса и права на решение. Если спорят два отдела, а решать некому, группа застревает. Нужен человек, который может принять решение или хотя бы зафиксировать вариант и назначить разбор.
• Не фиксируются открытые вопросы и следующий шаг. Без списка вопросов и владельцев вы унесете со стены красивые стикеры и ноль действий.

Прием против путаницы формулировок: проверка «можно ли написать это в прошедшем времени». Если нельзя - это не событие. «Проверить клиента» - команда, «Клиент проверен» - событие.

Еще одна ловушка - рисовать идеальный процесс и забывать про возвраты, ошибки и ручные обходы. После основного потока сделайте короткий проход по исключениям: что ломается чаще всего, где возникают задержки, какие решения принимаются вручную.

Чтобы не утонуть в спорах, заведите отдельную зону для вопросов и решений. Простое правило: любой спор дольше 3-5 минут превращается в карточку вопроса с владельцем и сроком.

Короткий чеклист и следующие шаги

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

• Карта событий: события в прошедшем времени, нет разрывов в цепочке, понятны акторы (кто запускает и кто получает результат).
• Команды: у каждой есть инициатор и проверяемый результат (что именно должно измениться).
• Агрегаты: у каждого есть ответственность и правила (инварианты), нет дублирования одной логики в разных местах.
• Backlog: задачи сгруппированы по ценности, есть приоритеты и зависимости, назначен следующий созвон для уточнений.
• Риски и неизвестное: спорные места отмечены, понятно, как их закрывать (данные, решение, прототип).

Если на карте нашлись «дыры», не пытайтесь закрыть их в чате. Быстрее собрать короткую уточняющую встречу на 45-60 минут с нужными людьми и добить конкретный кусок процесса.

Следующие шаги (что сделать на этой неделе)

1. Зафиксируйте словарь: 10-20 ключевых терминов и простые определения.
2. Согласуйте первый срез: какие 1-2 сценария идут в работу первыми и почему (ценность, риск, зависимости).
3. Сделайте быстрый прототип: скрин-поток или черновой интерфейс, чтобы проверить общее понимание результата.
4. Набросайте план интеграций и инфраструктуры: какие системы трогаем, какие данные нужны, кто отвечает за доступы.
5. Назначьте контрольную точку: дата ревью карты, обновления backlog и решений по спорным вопросам.

Если проект упирается в инфраструктуру (серверы, рабочие места, дата-центр), интеграции и требования к эксплуатации 24/7, полезно заранее подключить системного интегратора. В Казахстане эту часть часто закрывает GSE.kz: от подбора и поставки оборудования до интеграции и дальнейшей поддержки, чтобы результаты воркшопа быстрее доходили до работающего решения.