С чего начинать сессию Event Storming, чтобы не запутаться?

В моих первых попытках применения методологии Event Storming была проблема, которую иногда называют «Страх чистого листа». Не знала как начать. Какой стикер разместить на доске первым? Какой вопрос задать? 

Вроде нет тут особой тайны. Просто спроси у своих доменных экспертов о том, что происходит в процессе, а потом переведи это в нужную форму и упорядочи. Но есть вероятность, что мы начнет обсуждать нечто, несвязанное с процессом.  Я ведь не знаю процесс, не знаю систему. Значит – не смогу уловить отклонение от маршрута. Рискую запутать себя и экспертов, потерять время.

Вдохновлялась постом Евгения Лукьянова про предварительный анализ, где он рекомендует фиксировать «…что мы делаем и какую задачу решаем», придумала давать название исследуемому процессу. Так первыми стикерами на моей доске для EventStorming стали ответы на вопросы «Что мы делаем» и «Для чего мы это делаем». 

Что мне это дало:

1. Я всегда знаю с чего начать и это точно будет по-делу. Прям сразу с места в карьер. 
2. Работает как договор. Пока мы с доменным экспертом формулируем в одну короткую фразу-ответ на вопрос: «Что мы делаем» – мы договариваемся. Сразу начинают заполняться бирюзовые стикеры Term, ведь нам важно зафиксировать одинаковое понимание ключевых фактов. Есть ньюанс. Попытка найти ответ на вопрос: «Для чего мы это делаем» – может «подвесить» эксперта и закончится тем, что человек уйдет на подумать. Но другой встречи может и не случиться, поэтому для меня важно использовать все выделенное время и двигаться дальше оставляя эти вопросы в открытом состоянии. 
3. Работает как целеполагание и связь с надсистемой. Чаще всего процесс, который исслезуем, не является «вещью в себе». Он – часть другого процесса более высокого уровня. А это значит, что цель исследуемого процесса – это задача в надсистеме, один из элементов декомпозиции. Поясню.
   
   Что происходит когда нам нужно сделать продукт? Мы делим создание продукта на задачи. Потом каждую задачу на подзадачи. Потом снова декомпозируем и так до неделимой единицы, которой, обычно, является постановка для программиста. Отсюда атомарность требований как признак их качества. 

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

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

Ответы на вопросы «Что мы делаем и для чего мы это делаем» – цель процесса. Чтобы мы не проектировали, мы должны прийти к этой самой цели. Если сформулировать ответ в форме события, в прошедшем времени, то это будет последний стикер в нашей модели процесса. Так я придумала начинать EventStorming с конца. С конца модели. 

Примеры:

Маркетплейс запущен для того, чтобы через три года на наших счетах был триллиард денег. 

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

Задачи нарезаны для того, чтобы программист их закодил; для того, чтобы было что добавить к остальному коду; для того, чтобы это могло работать <так-то> и тестер смог это проверить; для того, чтобы за <так-то> работу нам <кто-то> отдал денег; для того, чтобы мы могли раздать их тестеру, программисту, нарезателю задач в доме который построил Джек.

Если в конце построения модели процесса мы придём к вот этому самому первому стикеру с ответами на «фундаментальные» вопросы, то мы привели процесс куда надо. Если нет, то мы сделали не то, что планировали. Это не всегда плохо. Просто это не то, что планировали. 

4. Финальный стикер с целью процесса, добавленный в самом начале разговора, работает как Impact Mapping не давая уйти в сторону от цели. Ведь одну задачу можно решать разными способами. Можно делать как лениво и быстро. Можно делать как любопытно, как никогда не делали. Всякое можно делать в процессе. Проблема в том, что эффекты будут тоже всякие. А нам нужен конкретный для того, чтобы мы могли это вписать в надпроцесс. И для того, чтобы мы не растратили ресурсы на любопытство. 
5. Стикер с целью как гаситель споров. Часто у нас несколько стейкхолдеров. Также часто их интересы противоречат друг другу. Когда у нас есть стикер с финальной точкой, которая всех устраивает, качать процесс в свою сторону становится бесполезно так как сразу видно насколько это отдаляет от цели. 

Итак

Теперь я всегда знаю с чего начать EventStorming – с конца. Я договариваюсь с доменными экспертами о том, что мы делаем и для чего мы это делаем. Записываю результат в форме свершившегося события на оранжевом стикере. Попутно собираю бирюзовые стикеры с терминами. Если не удается сформулировать ответ, пишу на красном стикере в свободной форме то, что удалось добыть поводу цели процесса. 

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