Event Storming без иллюзий: плюсы, минусы и стикер на лбу
Личный разбор Event Storming по итогам не одного «штурма событий»: где он реально спасает команду, где превращается в бесполезную стикеротерапию и что нужно, чтобы сессия не улетела в трубу.
Когда ты приходишь к команде с идеей «давайте проведём Event Storming», реакция всегда делится надвое. Одни радостно достают стикеры и маркеры, другие крутят пальцем у виска в стиле «опять эти ритуалы». И вот честный вопрос: у тебя в команде правда все настолько прошаренные, что знают, зачем вообще это нужно? У меня за плечами не один «штурм событий», так что давай начистоту — разберём, что тебя ждёт хорошего, а что не очень.
Что такое Event Storming за 30 секунд
Если совсем коротко: это воркшоп, где команда выкладывает на большую доску (физическую или виртуальную) события, которые происходят в системе, — в хронологическом порядке, стикерами. «Заказ создан», «Оплата прошла», «Товар зарезервирован», «Уведомление отправлено». Разными цветами помечают команды, агрегаты, внешние системы, болевые точки. И вот из этой мозаики внезапно проявляется то, что раньше жило только в головах отдельных людей и нигде не пересекалось.
Звучит красиво: собрались, поговорили, поделились мыслями, нашли инсайты. На практике любой такой формат — тот ещё квест, особенно если у людей в глазах усталость вперемешку с желанием «уже просто ничего не трогать». Поэтому давай по пунктам, без розовых очков.
Что реально хорошо
1. Общее понимание домена. Это главный приз. Все — от разработчика до бизнес-аналитика — наконец начинают говорить на одном языке. Когда события видны визуально, инсайты приходят даже к тем, кто до этого «молчал в тряпочку». Те самые коллеги, которые обычно не отсвечивают, но про которых внезапно вспоминаешь, когда начинаются разборы «а кто это вообще проектировал». На доске у них появляется голос — и часто именно они подсвечивают то, что все остальные считали очевидным и потому ни разу не проговорили вслух.
2. Выявление пробелов и конфликтов. «А что происходит после того, как оплата прошла?» — «Э-э, не знаю…» Вот этот диалог гораздо лучше всплывёт на встрече с маркерами в руках, чем на проде в три часа ночи. Event Storming безжалостно вытаскивает белые пятна: ветки, которые никто не додумал, состояния, в которые система формально может попасть, но что с ними делать — вопрос открытый. Дешевле найти это на стикере, чем в постмортеме.
3. Ускоряет командное взаимодействие. У вас появляется общая доска с «картиной мира» — и обсуждать спорные места становится проще. Люди охотнее спорят, когда всё видно как на ладони, а не когда каждый держит свою версию системы в голове и уверен, что именно она правильная. Спор у доски — это спор о фактах. Спор без доски — это спор о том, кто кого неправильно понял.
4. Повышение вовлечённости. Тут работает простая психология. Кто любит бумажки — тот счастлив, что можно лепить стикеры и двигать их по стене. Кто бумажки ненавидит — внезапно замечает, что идея «оцифровывается» через доску быстрее, чем через часовые созвоны и переписку в тредах. Физическое действие вовлекает даже скептиков: сложно оставаться в стороне, когда у тебя в руке маркер.
Где начинается боль
1. Затраты времени. «Штурм событий» может занять пару часов, а может сожрать целый рабочий день. И некоторые разработчики — особенно интроверты — искренне предпочли бы потратить это время на реальный код, а не на перекладывание бумажек. Это нормально. Просто закладывай, что сессия — это инвестиция, и она должна окупаться найденными проблемами, а не галочкой «провели Event Storming».
2. Риск увязнуть в деталях. Если модератор не «рубит» бесполезные ветвления, сессия превращается в бесконечную дискуссию о том, как правильно назвать ивент — OrderPlaced или OrderCreated. Полчаса спора о неймингах — и все забыли, зачем вообще собрались. Уровень абстракции надо держать сознательно: сначала крупная картина, потом углубление в рисковые участки, а не наоборот.
3. Нужен толковый фасилитатор. Без активного ведущего легко получить хаос. Кто-то будет «подминать» обсуждение под себя, кто-то наоборот молча спрячется за спинами и просидит два часа в телефоне. Хороший фасилитатор — это не тот, кто больше всех говорит, а тот, кто следит за темпом, вытаскивает молчунов, гасит доминирующих и держит фокус на цели. Без этой роли сессия проваливается независимо от того, насколько крутая у вас команда.
4. Иллюзия завершённости. Даже если вы шикарно расписали всё на доске — это лишь «снимок» ситуации на конкретный день. Система живёт, требования меняются, и вчерашняя красивая картинка через квартал может врать. Модель надо пересматривать, а не считать, что «всё, мы изучили ивенты навечно». Самая опасная ловушка — когда команда думает, что доска и есть источник истины, хотя источник истины давно уехал вперёд.
Как не слить сессию
Если собрать наблюдения в короткий чек-лист — вот что отличает рабочий Event Storming от дорогой стикеротерапии.
Во-первых, заранее договорись о цели. «Разобрать флоу оплаты» и «нарисовать всю систему» — это две совершенно разные сессии по масштабу и глубине. Без явной цели вы гарантированно расползётесь.
Во-вторых, назначь фасилитатора и дай ему право резать дискуссии. Это не диктатура, это тайм-менеджмент: у сессии есть бюджет времени, и кто-то должен его защищать.
В-третьих, фиксируй результат сразу. Фотография доски, экспорт из виртуального борда, список найденных пробелов с ответственными — иначе через неделю от инсайтов останутся только смутные воспоминания «вроде что-то важное нашли».
И в-четвёртых, заложи цикл пересмотра. Модель — живая. Если к ней не возвращаться, она устареет ровно с той же скоростью, с какой меняется система.
Итог
Event Storming — мощный инструмент, который объединяет людей вокруг единого понимания системы. Но это не магия, которая решит все проблемы за пару часов возни со стикерами. Нужен человек, способный направлять обсуждение, и готовность потом поддерживать модель в актуальном состоянии. Зато если подойти к делу с умом — избежишь внезапных «белых пятен» в логике и заметно улучшишь командное взаимодействие. А это, поверь, окупается быстрее, чем кажется на входе.
P.S. Если после сессии кто-то приклеит себе на лоб стикер PaymentFailed — это нормально. Главное, чтобы он понимал, как этот ивент ведёт к PaymentRetried и PaymentSucceeded.
Впервые опубликовано в моём Telegram-канале @it_underside.
Ваш ДПУПП
Похожие статьи
Форматы обмена данными: от JSON до protobuf
Большой разбор форматов обмена данными: где живёт JSON, зачем нужен XML, чем хорош YAML и когда пора переходить на бинарные Protobuf, Avro и MessagePack — с привязкой к API и брокерам сообщений.
UML: что за зверь такой и почему аналитики его избегают
UML умеет визуализировать, специфицировать и документировать систему — а в реальных командах его почти не встретишь. Разбираемся, зачем он нужен, почему аналитики его сторонятся и где он всё-таки окупается.
Микросервисы или монолит?
Выжимка по выбору архитектуры: достоинства и недостатки монолита и микросервисов, что лучше для небольшой компании, какой уровень специалистов нужен и чек-лист для выбора подхода.