EventStorming: польза, ограничения и практика

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

Что такое EventStorming за 30 секунд

EventStorming — формат совместного исследования предметной области, предложенный Альберто Брандолини. Участники размещают на физической или виртуальной доске значимые доменные события в прошедшем времени: «Заказ создан», «Оплата подтверждена», «Товар зарезервирован». На базовом уровне этого уже достаточно, чтобы увидеть ход процесса и спорные места.

В зависимости от цели сессии на доску добавляют команды, правила, внешние системы, людей и агрегаты. Не обязательно вводить все обозначения сразу: для Big Picture важнее общая картина, а для Process Modelling — разбор конкретного процесса, для Software Design — проектирование поведения и границ программных компонентов.

Что реально хорошо

1. Общее понимание домена. Бизнес, аналитики, разработчики и смежные эксперты видят один процесс и постепенно выравнивают терминологию. Визуальный формат помогает заметить знания, которые раньше оставались только у отдельных участников.

2. Выявление пробелов и конфликтов. На последовательности событий проще увидеть пропущенные ветки, неоднозначные состояния, ручные операции и разные трактовки одного правила. Такие вопросы полезнее обсудить до реализации, чем обнаружить уже после релиза.

3. Предметное обсуждение. Общая доска делает расхождения видимыми. Участники могут ссылаться на конкретный участок процесса, проверять гипотезы и фиксировать вопросы, а не обсуждать несколько мысленных моделей одновременно.

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

Где начинается боль

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

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

3. Нужен фасилитатор. Ведущий следит за темпом, возвращает разговор к цели, вовлекает участников и выносит отдельные вопросы в parking lot. Эта роль особенно важна, когда у участников разный уровень полномочий или экспертизы.

4. Иллюзия завершённости. Доска фиксирует понимание участников на момент сессии, но сама по себе не становится спецификацией или источником истины. Решения, границы и открытые вопросы нужно перенести в рабочие артефакты команды.

Как не слить сессию

1. Сформулируй вопрос и выбери формат: Big Picture для обзора домена, Process Modelling для конкретного процесса, Software Design для проектирования программной модели.
2. Пригласи людей, которые знают разные части процесса и могут прояснить бизнес-правила, данные, интеграции и ограничения.
3. Назначь фасилитатора, задай timebox и договорись, какие темы будут вынесены за рамки встречи.
4. Начни с доменных событий. Остальные типы элементов добавляй тогда, когда они помогают ответить на вопрос сессии.
5. В конце собери решения, пробелы, допущения и следующие шаги с ответственными.
6. Реши, какие результаты нужно перенести в спецификации, backlog, диаграммы или журнал архитектурных решений. Сама доска может остаться временным исследовательским артефактом.

Что команда должна унести со встречи

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

Подход описан на сайте EventStorming, а различия трёх форматов — в материале команды автора, Avanscoperta.

Пример: заказ оплачен, а товара нет

Возьмём учебный интернет-магазин. На доске сначала появляется удобная линия: «Заказ создан», «Оплата получена», «Заказ отправлен». Она выглядит законченной, пока человек со склада не задаёт вопрос: «А когда мы резервируем последний товар?»

Здесь сессия начинает приносить пользу. Выясняем, что резерв может истечь до подтверждения платежа. Добавляем события «Резерв истёк» и «Оплата получена после истечения резерва». Обсуждаем, кто выбирает дальнейшее действие: повторный резерв, замена или возврат. Не рисуем сразу новый микросервис — сначала договариваемся о правиле.

Результат такой сессии — несколько предметных артефактов:

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

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

---

Впервые опубликовано в моём Telegram-канале @it_underside.

Ваш ДПУПП