Перейти к содержанию
Все инструменты
ОперацииСредний

Моделирование событий EventStorming

Совместно исследуйте предметный процесс, располагая значимые события во времени.

За одну минуту

Совместно исследуйте предметный процесс, располагая значимые события во времени.

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

Какую проблему решает

Специалисты по-разному описывают процесс, а требования к ПО скрывают исключения.

Платформа доставки еды считает, что возврат начинается с жалобы клиента, но склад сообщает: замена товара происходит до уведомления покупателя.

Когда применять

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

Когда не применять

Не заменяйте методом данные, ответственное решение и участие затронутых людей.

Превращать встречу в спор об архитектуре ПО до согласования того, что фактически происходит.

Необходимые входные данные

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

Пошаговый процесс

1. Определите границы решения и ответственного.

До встречи запишите границы работы, ответственного за решение и тех, кто вправе остановить или пересмотреть результат.

2. Соберите необходимые данные и мнения затронутых людей.

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

3. Выберите границы процесса и результат.

Согласуйте начало и конец истории и пригласите тех, кто знает разные её части.

4. Соберите события области в прошедшем времени.

Записывайте произошедшие события области, например «Платёж отклонён», а не экраны и будущие функции.

5. Расположите события и отметьте сомнения и конфликты.

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

6. Добавьте запускающие действия, роли и правила.

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

7. Проверьте реальными случаями и превратите спорные места в вопросы.

Проведите по карте два реальных случая и превратите каждое спорное место в вопрос для исследования или проектирования.

8. Запишите результат, следующую проверку и повод пересмотра.

Сохраните артефакт со ссылками на данные, ответственным, ограниченной следующей проверкой и датой либо условием пересмотра.

Взгляд на ИИ-автоматизацию

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

Визуальная модель

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

Интерактивный пример

Ситуация: Платформа доставки еды считает, что возврат начинается с жалобы клиента, но склад сообщает: замена товара происходит до уведомления покупателя.

Разбор: Покажите принятие заказа, отсутствие товара, выбор замены, отправку уведомления, согласие и возврат; выделите отсутствующее событие согласия.

Заметки для фасилитатора

Запишите разногласия до обобщения; спросите, чьих данных не хватает; определите, кто вправе пересмотреть результат.

Ожидаемый результат

  • Проверяемый рабочий артефакт, допущения и данные, ответственный, ограниченная следующая проверка и дата пересмотра.
  • Проверьте реальными случаями и превратите спорные места в вопросы.
  • Ответственный, проверка и дата пересмотра.

Типичные ошибки

Превращать встречу в спор об архитектуре ПО до согласования того, что фактически происходит.

Чек-лист качества

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

Шаблон

Открыть рабочий шаблон.

Проверка знаний

Вопрос: Какая ошибка подорвёт применение метода в этой ситуации?

Ответ: Превращать встречу в спор об архитектуре ПО до согласования того, что фактически происходит.

Связанные методы

Источники

  1. EventStorming — источник метода (откроется в новой вкладке). Проверено 2026-09-28.
  2. Независимый практический источник (откроется в новой вкладке). Проверено 2026-09-28.

Профиль метода

Метод структурирует обсуждение и проверку; сам по себе он не доказывает причинность и не гарантирует успех.