На схеме возврат товара выглядит просто: заявка, согласование, получение, выплата. Но спросите специалиста поддержки, сотрудника склада и разработчика, что значит «возврат одобрен», — и вы можете получить три разных ответа. Для одного покупатель уже может отправить товар обратно. Для другого товар прошёл проверку. Для третьего платёжная система приняла поручение на возврат денег.
Воркшоп EventStorming помогает обнаружить такие расхождения: участники вместе восстанавливают историю значимых событий в работе компании. Разберём условный процесс возврата у розничного продавца и покажем, как перейти от противоречивых описаний к модели, которую можно обсуждать с людьми, выполняющими эту работу.
Ограничьте встречу моделированием одного процесса
Формат EventStorming Process Modelling Альберто Брандолини подходит как для изучения существующего процесса, так и для проектирования нового. С него удобно начать, когда вопрос касается конкретного рабочего потока. Более широкий формат Big Picture охватывает значительную часть предметной области, а Software Design углубляется в вопросы реализации. Не рассчитывайте полноценно пройти все три уровня на одной короткой встрече.
Для нашего продавца граница звучит так: «Покупатель возвращает один приобретённый товар и получает деньги либо объяснение отказа». Обмен товара, расчёты с поставщиками и расследование мошенничества оставим за пределами первого разбора. Места их соприкосновения с процессом можно отметить, не отдавая им всю доску.
Пригласите тех, кто знает разные части этой истории: поддержку, сотрудников, принимающих возвраты, специалистов по платежам и разработчиков. Особенно полезен человек, который отвечает за правила возврата. Одни разработчики могут точно описать программную систему, но не заметить, что сотрудники делают за её пределами.
Начните с понятных участникам событий
Дайте людям возможность записать события до того, как группа начнёт согласовывать их последовательность. Событие предметной области описывает уже произошедший значимый факт: например, «Возврат запрошен» или «Товар проверен». Записывайте такие формулировки в прошедшем времени на оранжевых стикерах. «Проверить товар» — намерение выполнить действие; «Товар проверен» — его результат. Эти обозначения и дополнительные элементы процессного моделирования разобраны в глоссарии DDD Crew.
Попросите каждого привести примеры из своей работы. Сотрудник склада добавит «Посылка получена», а специалист поддержки — «Этикетка для отправки выслана». Оба события могли отсутствовать в первом описании разработчика. Пока не ясно, означают ли похожие карточки одно и то же, не удаляйте их как дубликаты.
Осторожнее с названиями экранов и полей базы данных. «Статус обновлён» не объясняет, что изменилось в работе. Спросите, какой факт теперь известен покупателю или сотруднику. Так же нужно уточнить «Возврат денег завершён»: поручение отправлено, принято платёжным провайдером или расчёт подтверждён? Если после этих событий принимаются разные решения, разделите их.
Вместе восстановите историю возврата
Выстройте правдоподобную последовательность и попросите участников проговорить её вслух. В нашем примере первый вариант может выглядеть так: Возврат запрошен → Возврат разрешён → Посылка получена → Товар проверен → Возврат денег запрошен → Возврат денег подтверждён.
Это модель для обсуждения учебного примера, а не универсальное правило для всех продавцов. Если компания возвращает деньги до получения товара, отразите это на её схеме. Если проверка и другая операция независимы, расположите их на отдельных дорожках, не создавая впечатления, что одна всегда ждёт другую.
В паттерне Брандолини Conversational System разбирается опасность жёстко упорядочивать поведение, которое допускает параллельность или разную очерёдность. Важно понять зависимости, а не добиться идеально ровного ряда стикеров.
При разногласии добавьте ярко-розовую карточку Hot Spot рядом с соответствующим событием. Сформулируйте вопрос: «Разрешение на возврат гарантирует выплату?» полезнее, чем «Проблема с правилами». Продвиньтесь достаточно далеко, чтобы увидеть соседние этапы, а затем вернитесь к вопросу с нужными участниками.
Свяжите события с действиями и нужной информацией
Когда история событий станет понятной, добавьте действия, благодаря которым они происходят. Для команд или действий используйте синие карточки и укажите, кто их инициирует — человек или система. Информацию, необходимую для решения, добавляйте там, где она помогает объяснить поведение. Если сразу показать все возможные обозначения, воркшоп превратится в урок нотации.
Первый подробно разобранный участок процесса может выглядеть так:
| Событие или ситуация | Действие для разбора | Нужная информация | Нерешённый вопрос |
|---|---|---|---|
| Возврат запрошен | Разрешить возврат | Заказ, товар и применимые правила возврата | Кто вправе согласовать исключение? |
| Посылка получена | Проверить товар | Ожидаемый товар и указанная причина возврата | Что делать, если в посылке другой товар? |
| Товар проверен | Запросить возврат денег | Результат проверки и идентификатор исходного платежа | Любой ли результат проверки позволяет вернуть деньги? |
| Возврат денег запрошен | Проверить результат платежа | Ответ провайдера и идентификатор операции | Как отличить неизвестный результат от отказа? |
Политика в этой нотации описывает реакцию на событие. Команда из примера может предложить правило: «Когда проверка подтверждает допустимость возврата, запрашиваем выплату». Поместите его на сиреневую карточку между событием и действием. Пока ответственный за правила не подтвердил формулировку, отмечайте её как предложение. Соединительная линия не заменяет согласование.
Обратите внимание на промежуток между запросом и подтверждением возврата денег. Если считать их одним событием, можно упустить задержки ответа или повторные запросы. Воркшоп не обязан сразу решить вопросы проектирования платёжной системы, но должен сделать это различие заметным.
Проверьте модель на одном нестандартном возврате
После обычного случая выберите исключение, которое меняет ход обсуждения. Допустим, посылка пришла без ожидаемого идентификатора товара. Поддержка нашла заказ покупателя, но склад не может уверенно сопоставить его с содержимым посылки.
Попросите группу продолжить историю. Произошло ли событие «Товар проверен» или пока только «Посылка получена»? Кто может запросить дополнительные сведения? Какое событие сообщит поддержке, что возврат требует внимания? Если ответ — «кто-то отправит сообщение», уточните отправителя, получателя и значимый факт, который передаёт это сообщение.
Не придумывайте срок или право на выплату, чтобы заполнить пробел. Поместите невыясненный вопрос о правилах рядом с соответствующими карточками. В паттерне Брандолини Rush to the Goal предлагается сохранять возражения и альтернативы на виду, одновременно выстраивая базовый поток. Здесь это полезнее, чем останавливать каждое обсуждение до разрешения всех исключений.
Когда бизнес-поведение станет понятным, отдельная блок-схема обработки исключений (на английском) поможет детализировать рабочие ветвления. EventStorming прежде всего помогает участникам договориться о смысле событий, от которых зависят эти ветвления.
Соберите модель возврата в Boardmix
Откройте Boardmix и создайте пустую доску для обсуждения возвратов. Над просторной рабочей областью напишите границы процесса. Сбоку разместите небольшую легенду, чтобы участники различали события, действия, политики и Hot Spot не только по цвету.
До добавления заметок объясните группе условные обозначения. Легенда онлайн-доски с подписями и цветами помогает одинаково понимать каждый символ. Сохраните используемые здесь значения EventStorming, а не переносите цветовую схему из другого воркшопа.
- Добавьте оранжевые стикеры для шести событий исходной истории. Подписи должны читаться во время созвона.
- Оставьте между событиями место для синих карточек действий. Разместите «Запросить возврат денег» перед событием «Возврат денег запрошен», а не вместо него.
- Добавьте предложенную сиреневую политику рядом с результатом проверки. Соединяйте только те элементы, связь которых группа обсудила.
- Рядом с «Возврат разрешён» поместите розовый вопрос «Разрешение = гарантия выплаты?». Нерешённые вопросы должны оставаться возле поведения, которого они касаются.
- Откройте участникам нужный доступ на редактирование. Попросите представителя каждой части процесса проговорить историю, пока остальные уточняют карточки.
На онлайн-встрече держите в поле зрения один и тот же участок, пока участник его объясняет. Если несколько человек одновременно переставляют карточки в спорной области, приостановите редактирование и попросите описать альтернативы. Доска поддерживает разговор; быстрое перемещение стикеров ещё не означает согласия.
Не приписывайте модели больше, чем она показывает
Законченный вид доски не доказывает, что программа реализует этот процесс, что правило утверждено или что найдены все существенные исключения. Разделяйте наблюдаемое поведение и предлагаемые изменения. Если группа проектирует новую последовательность возврата денег, сохраните существующую рядом, чтобы различие было видно.
Для нашего продавца ближайший результат может быть вполне конкретным: переименовать неоднозначное событие, уточнить полномочия на согласование исключений и выяснить, как обрабатывается неизвестный результат платежа. У операционной команды и разработчиков появится общая отправная точка. Следующий разговор начнётся с нерешённого вопроса на розовом стикере, а не с повторного спора о том, что значит «одобрено».
