Event Storming примиряющий

У меня была возможность понаблюдать как Event Storming работает на реальном проекте. Не напрямую. Всего лишь по-рассказам. Но этого приближения хватило для того, чтобы сделать несколько интересных выводов. Сейчас я с вами этим поделюсь.

Предыстория

Разрабатывают внутренний продукт, который должен автоматизировать сложные и запутанные процессы. Роли бизнес-аналитиков и системных отделены. Это разные специалисты. И тех, и других — несколько. При этом системные аналитики входят в команду разработки и подчиняются руководителю проекта, а бизнес-аналитики работают на несколько проектов и подчиняются только своему функциональному руководителю. Расскажу о них чуть подробнее. 

Прекрасные дамы помнят то время, когда никаких сотовых телефонов не было и, между прочим, нормально жили. Имеют огромный, в первую очередь жизненный, опыт и твердый характер. Нормально общаются с бизнесовой частью компании и хорошо знают их потребности, а вот технические вещи — не очень. Требования собирают и оформляют — как умеют. Проблема заключалась в том, что команда проекта никак не могла понять по этим артефактам что нужно делать. Им не хватало данных. Но попытки их получить встречали сопротивление. Бизнес-аналитики были уверены, что от них требуют чего-то нереального. Они давно работают и ничего подобного от них раньше никто не хотел. А техническая часть команды впадала в отчаяние так как не могла продолжать работу с теми данными, которые у них были. Получить необходимое в обход бизнес-аналитиков не представлялось возможным. 

Отношения раскалились до предела. Вопросы на встречах метались как молнии. Атмосфера искрила. Бизнес-аналитики сидели за забралом глухой защиты. 

К очередному этапу проекта, в попытках хоть как-то отладить рабочие процессы под руководством своего линейного руководителя бизнес-аналитики оформили требования в формате user-case и даже приложили схемы в нотации BPMN. На выявление и оформление требований у них ушел год. Системным аналитикам дали несколько дней для того, чтобы это прочитать и сказать каких данных не хватает. Системные старались. Но понять процесс и составить о нем хоть какое-то представление по обрывкам сценариев в кейсах так и не смогли. К BPMN-ке требовалась пояснительная бригада. Вопросов было слишком много. Здесь на сцену выходит наш герой — Event Storming.

Перевод целей в события

Почти в каждом кейсе была графа “цель”. Некоторые были без этого атрибута. Тогда спасал заголовок. Системный аналитик, силясь понять что же все таки происходит в описанных процессах, собрал все цели \ заголовки кейсов и перевел их в события, оформив, как положено – с глаголами в форме прошедшего времени. К примеру, цель: “Сделать процесс, чтобы процесс был сделан” конвертировалась в “Процесс сделан”. Затем аналитик выстроил получившиеся тезисы в линию от более ранних, к более поздним. С этой простой схемкой, где не было ничего кроме черных букв на белом фоне, и линий, отделяющих параллельные потоки процессов, он пошел на ту самую встречу, где от него ждали список уточняющих вопросов. 

Какая-то магия

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

Старший бизнес-аналитик действительно все рассказала. Проблема заключалась в том, что рассказ был не о тех процессах, которые требовалось реализовать в системе, а о процессах сбора требований. Она подробно рассказала что конкретно они делали и почему именно так, что и как оформляли. Все было понятно кроме главного — что делать. 

Какой именно функционал ждет заказчик? Что в нем должно быть и как оно должно работать? Вновь заметались молнии отрывочных вопросов. Дождавшись короткой паузы системный аналитик в пятый раз озвучил свое предложение всем вместе посмотреть на схему, которую он подготовил специально к этой встрече. Накал страстей к тому моменту достиг предела. Требовалась пауза. Просьбу услышали и удовлетворили. Дальше случился примерно такой диалог:

— Насколько я понял из кейсов, процесс начинается с того, что… — сказал системный аналитик демонстрируя виртуальную доску с выстроенными в линеечку тезисами.

— Да — на секунду задумавшись ответила старший бизнес-аналитик. 

— Потом происходит вот это — продолжил системный аналитик.

— Да, — уже быстрее подтвердила бизнес-аналитик. 

— А вот это у вас стоит пятым кейсом, но так как дальше идет это и это, я полагаю, что этот кейс можно поставить раньше, так как без того, что в нем реализуется, мы не сможет реализовать то, что написано в кейсе 3 и 4. 

— Да, можно. Можно-можно — уверенно и вовлеченно ответила бизнес-аналитик.

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

Одной встречи мало

На первой встрече удалось разобрать только треть процесса. При подготовке ко второй встрече бизнес-аналитики изменили нумерацию кейсов согласно оговоренной последовательности, довыявили некоторые процессы и дописали документацию. Системный аналитик достроил схему событий и к каждому из тезисов подписал номер кейса. Ранее враждующие стороны работали как команда. 

В следующий раз разобрали оставшиеся две трети процесса. На доске к тому моменту появились красные стикеры, которые прилагались как поясняющий комментарий к каким-то событиями, и стикеры бирюзового цвета, фиксирующие термины. Ушли опять довыявлять какие-то моменты и достраивать схемы. 

Пока разбирали процесс по событиям, то периодически заходили в тупик, как и раньше. Но бизнес-аналитики не воспринимали это в штыки. Было очевидно всем собравшимся чего именно не хватает и почему без этого никак не получится двигаться дальше. Поэтому расходились миром. Если бизнес-аналитики чего-то не могли (например там, где требовалась работа с базой данных) то пытались найти альтернативные варианты. Все вместе, спокойно, без нападения и защиты. 

На третьей встрече все события превратились в оранжевые стикеры. Все процессы выстроены как положено. Обозначены бизнес-правила, согласно которым происходит ветвление или распараллеливание процессов. Прошлись по схеме сначала методом прямого чтения – подредактировали, а потом стали читать в обратном порядке. 

В этом моменте ожидались сопротивления. Ведь все это уже столько раз мусолили, что, казалось бы, – сколько можно. Но предложение пройтись еще разочек, только задом наперед, было воспринято как должное. Закрались мысли о том, что бизнес-аналитики где-то слышали про Event Storming и понимали что сейчас происходит. 

Время потратили не зря. Метод обратного чтения сработал. Даже в хорошо проработанном процессе обнаружились неточности и его снова пришлось достраивать.

Что произошло и почему это сработало?

Возможность для каждого “сохранить лицо” даже в тех моментах, где он чего-то не может или не понимает – вот что произошло и послужило применяющим фактором. Я думаю, что дело в этом. 

Как бы хорошо не работали бизнес-аналитики, многие вещи остаются для них непонятными и это нормально. В выявляемых процессах они не работают. Они их только выявляют. Полного погружения не происходит. Техническая сторона вопроса тоже остается для них загадкой. У них с обеих сторон два чёрных ящика. Из одного, что смогли — взяли. В другой, как получилось — положили. Что уж там творится по обе стороны дальше… Они не знают. На этом их полномочия – всё. Какое недопонимание процесса допустимо для бизнес-аналитика, а какое – является проблемой и негативно влияет на результаты проекта? Это очень дискуссионный вопрос. 

Обратная сторона медали: команде разработке и системным аналитикам нужно спроектировать систему прежде чем они смогут начать писать код. Невозможно построить модель по обрывкам информации. Нужна целостная картина. Что тут можно сделать? Указать бизнес-аналитикам на пробелы в информации. Те, в свою очередь, искренне полагают что заполнение этих пробелов – задача системных аналитиков, а не их. Классический волейбол ответственности на стыке команд и бездонная яма, в которую эта ответственность в результате падает. 

Не могу ручаться, что дело было именно так, но когда (если) системный аналитик сказал: “из кейсов я понял…”, то как минимум, подтвердил, что бизнес-аналитики свою работу целый год делали не зря. Если кто-то что-то понял, то требования они пишут понятно. У бизнес-аналитиков пропала необходимость оправдываться. От них требовалось только соглашаться или не соглашаться (с тезисами ивентов и их расположением на временной оси). А это они умеют. Это ок. 

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

Мои выводы:

1. Онлайн можно.
   Не обязательно собирать всех в одном помещении. Как выяснилось, в некоторых случаях даже не обязательно работать со стейкхолдерами и доменными экспертами. Достаточно тех, кто с ними уже поработал. 
2. Эстетика – плюс 100 к пониманию.
   Я несколько раз слышала о том, что преимуществом Event Storming является его разноцветность, которая придает веселости. Не могла понять при чем тут это. Возможно для зуммеров это важно. Но разноцветность для цветового кодирования, а не для веселья.
   В этот раз я прямо отследила как оформленная в более эстетичной, приятной глазу, форме информация становится более понятной словно по-волшебству. Тут нужно отдать должное дизайнерам виртуальных досок Excalidraw. Не знаю кто потрудился над их UI/UX, но он гений. 
3. Никаких крестов.
   Я выделила этот пункт отдельно, но на самом деле он – продолжение предыдущего. Это все еще про эстетику и ее влияние на восприятие. Я заметила, что при обсуждении процесса на основании схем BPMN есть некоторая зажатость, которая отсутствует, если смотреть на тот же процесс, оформленный в шторминге. Много думала об этом.
   Когда смотришь на BPMN-ку взгляд сам собой притягивается к шлюзам. И первое, что пытаешься идентифицировать – разворот креста. От этого зависит исключает ли одна ветка другую или дополняет. А с чем у нас обычно ассоциируются кресты? Аптека, больница, красный крест… Что-то такое алармическое, что требует собранности и инвестиции всех ресурсов. Поэтому, как бы сама собой, возникает внутренняя зажатость, которой нет когда мы работаем с рыжими стикерами. Да хоть бы и просто с тезисами, написанными черными буквами на светлой доске. 
4. Event Storming — это просто стикеры и это киллер-фича.
   Еще одна вещь, которую часто приходится слышать, когда начинаешь говорить про метод Брандолини: “… это стикеры какие-то, да?” Мне каждый раз хотелось сказать что там все намного сложнее и глубже. Надеюсь, что больше у меня такого желания не возникнет. Да, это просто стикеры. Поэтому:
   — их одинаково хорошо понимают все без какой-либо предварительной подготовки;
   — их никто не боиться, никто не думает что от него потребуется навык рисования или ещё какой-то хитрый скил;
   — люди быстро схватывают принцип и включаются в процесс. 
5. Excalidraw не бесконечна.
   Как бы я не радовалась этому инструменту, оказалось, что у него есть ограничения, которые неясно как преодолевать. В какой-то момент доска начала писать предупреждение, что не удалось сохранить информацию в базу данных поэтому все имеющееся на доске следует срочно скачать. При этом она начинала тормозить и лагать. Системному аналитику, который мне все это рассказывал, приходилось удалять все вспомогательные схемы и оставлять на доске только самое нужное и самое актуальное чтобы Excalidraw прекращает мигать красным треугольником с восклицательным знаком. Если кто-то знает что с этим можно сделать, напишите нам, пожалуйста. 

Эта история еще не закончена. За три встречи успели сделать только самую первую стадию — собрать и верифицировать события. Системному аналитику снова пришлось заниматься конвертацией форматов. На этот раз он перенес события в табличку оформив их в виде функциональности, по просьбе руководителя проекта. Табличка отправилась к команде проекта для предоценки. Так не делают. 

Чтобы все было по-уму, нужно добавить на схему акторов, модели чтения, команды и системы. Уже вместе с кем-то из разработчиков дополнить схему агрегатами. На основании этого подобрать технические решения. Вот тут можно сделать предоценку. Но нужно было вчера (после первой встречи). А системный аналитик уходил в отпуск, который некуда было переносить. Бизнес-аналитики узнав, что системного неделю не будет, пожелали ему хорошего отдыха. Они оказались милыми людьми. Вот как, оказывается, бывает. 

Результат неполный. Но тот факт, что атмосфера на проекте стала немного спокойнее, и у всех появилось общее, одинаковое понимание процесса, подкрепленное визуальным артефактом, я считаю пусть и небольшой, но победой методологии Event Storming.