Пример начала покера

Если кто-то пропустил, в комментариях еще был пример 12 палочек.

Инсайт участников с одной из крайних сессий Event Storming.

В начале модели кто-то разместил событие «воронка продаж сформирована». Другой участник задал вопрос «как формируется воронка продаж?» и открыл ящик пандоры.

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

Например:
1. Продажи 2 месяца формируют воронку на 10.000 потенциальных клиентов, но в после старта привлечения только 10% проходят проверку на риски, и это 10% от 20% заинтересовавшихся от тех 10.000.
2. Существует специфика процессов под определенную ЦА. Конда доля этой ЦА низкая, – специфика не существенна. Если доля доходит до существенного уровня, - требуется перестройка.
3. Часть клиентов экономически более выгодны для продаж и разумный фокус - продавать там, где больше платят. Но продажи - это не всё и на обслуживании и реализации контракта, затраты и убытки могут превысить выручку, как из-за неготовности процессов, так и исходя из специфики ЦА/контракта.

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

Циклы в Event Storming

В event storming нет циклов и нет control flow. В event storming события.

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

Если модели согласованы и хочется цикл, то на самом деле это уже не цикл, просто тот же самый процесс.

Если хочется показать, что где-то есть цикл, просто напишите рядом комментарий.

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

When using an event-driven architecture, a model that is based on events must replace a model that is based on data. In the event-driven paradigm, the events are more important than the data, which still has value 👌

Стоит ли предоставлять доступ к модели предметной области через внешние API?

Tempting though it may be, it is not advisable to directly expose a domain model via RESTful HTTP.

This approach often leads to system interfaces that are more brittle than they need to be, as each change in the domain model is directly reflected in the system interface. There are two alternative approaches for combining DDD and RESTful HTTP.
…
The first approach is to create a separate Bounded Context for the system’s interface layer (..). This can be deemed a classic approach, as it views the system’s interface as a cohesive whole that is simply exposed using resource abstractions instead of services or remote interfaces.
…
Another approach is appropriate when more emphasis is placed on standard media types. (...) a domain model can be created to represent each standard media type. Such a domain model might even be reused across clients and servers, although some REST and SOA proponents view this as an anti-pattern.

Note: Such an approach is essentially a Shared Kernel (3) or Published Language (3) in DDD terms.

(c) Vaughn Vernon, Implementing Domain-Driven Design

А имеет вообще смысл написать на русском небольшую книгу-инструкцию по Event Storming? Или поезд уже давно ушел)))

Остались вообще те, кто книгами интересуется?)))

А то материала масса)

Event Storming Street Art

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

У кого в этом месяце три очных сессии Big Picture Event Storming по два дня, тот я :)

Рад, что очный формат все активнее возвращается в жизнь.

UPD: чуть позже расскажу, почему этому рад :)

Все больше обсуждений идет вокруг «AI заменит то, AI заменит это». Однако я уверен, что исследовательские техники с вовлечением большого числа людей, вроде Big Picture Event Storming не заменить AI.

И вот почему:
- Event Storming вскрывает много информации, которой просто нигде не зафиксировано, кроме как в головах конкретных людей, - это следствие того, что есть регламенты, а есть то, как они исполняются и в этом часто высокий уровень вариативности и, если будет угодно, креативности, причем различной у различных людей
- В AI практически невозможно загрузить весь требуемый контекст, - он и не формализуем в общем случае и непонятно, какие именно аспекты контекста загружать, пока они не всплывут в рамках исследования
- Модель должна быть сфокусированной на некотором аспекте, без совместного диалога сводимости в однозначном понимании модели не произойдет

Однако полученную модель вполне можно «скормить» AI и «поиграться», задавая различные вопросы, иногда AI находит не очевидные закономерности, однако стоит быть осторожными и использовать их как гипотезы, потому что AI будет опираться на конкретные формулировки, а не глубокий смысл за ними.

Я отключил комментарии, пока не разберусь как настроить антиспам бота для чата, прикрепленного к каналу, – в такой чат могут писать все, кто в канале без вступления в сам чат и из-за этого антиспам бот не работает.

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

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

Вспоминая характеристики качественной информации по Веструму:
– Информация должна предоставлять ответы на заданные вопросы
– Быть своевременной и
– Должна быть представлена в таком виде, в котором она может быть эффективно использована получателем

Можно оценить, насколько циркуляция информации в компании/департаменте/команде удовлетворяет этим характеристикам и запланировать улучшения.

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

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

Системные паттерны, которые можно увидеть в построенной модели.

Трагедия общин
Обычно проявляется как высокая плотность стикеров в центре модели и простота на краях. Конкретный пример может звучать как «вместо решения проблемы в домене (например, проверка товара при размещении) все проблемы сваливаются в общий процесс согласования».

Механизм возникновения (развития паттерна) примерно такой:
Продажи: у нас проблема с ценами -> проверят на согласовании
Склад: у нас проблема с остатками -> проверят на согласовании
Финансы: у нас проблема с лимитами -> проверят на согласовании

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

Компенсирующие обратные связи
Добавление защитных/компенсационных механизмов дестимулирует качество на входе. Деминг это называл «контроль качества на выходе не создает качество внутри».
В модели проявляется в виде ассиметрии сложности – простые входные процессы, сложные выходные. Суть в том, что чем больше проверок справа (проверка, отгрузка), тем менее аккуратно работают слева (создание, подготовка).

Механизм возникновения может быть таким:
Добавили проверку качества заказов на складе
Менеджеры стали менее аккуратно заполнять заказы ("все равно ж проверят")
Проблем на складе стало больше -> добавили еще проверок
Качество входящих заказов упало еще больше

Результат, – чем больше контроля, тем хуже работают контролируемые процессы.

Следующий паттерн - addiction to complexity (зависимость от сложности)

Он прекрасен во всем 🙂
Это когда организация становится зависимой от сложности как способа демонстрации важности и контроля.

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

Тут проявляются механизмы психологии:
Для менеджмента: сложный процесс = важная работа = моя ценность
Для отделов: чем больше этапов мы контролируем, тем мы незаменимее, важнее
Для организации: сложная система = серьезный бизнес

Как результат, – простые решения отвергаются как несерьезные, создается культура усложнения вместо решения проблем

Этому паттерну поведения, к слову, мы все подвержены, вспомните, было ли у вас такое, что вы нашли какое-то очень простое решение, а предлагать его даже как-то неловко, это ж не серьезно и в итоге додумываете, как-бы его усложнить, чтобы выглядело солиднее 🙂 А потом появляются огромные модели предметной области 😉

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

Дело в том, что иногда складывается ощущение, что про event storming уже все написано и все ошибки давно разобраны, на самом же деле настоящая практика всегда чуть сложнее и чуть глубже, чем кажется из описаний сессий. Я немного порефлексировал и собрал самые сложные и неочевидные истории, встречающиеся регулярно. Некоторым из участников этого канала я их уже рассказывал лично, а кто-то, может быть, узнает свою сессию.

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

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

Сегодня выйдет первый пост на тему «Ложное согласование понятий»

Ложное согласование понятий

Ложное согласование понятий — это эффект, когда всем кажется, что разговор идет об одном и том же, но на деле за привычными словами у каждого прячется свой смысл. Одна из целей ES как раз в том, чтобы такие понятия прояснить. На практике это выглядит так: кто-то говорит слово/термин и уверен, что все понимают его точно так же, ведь «тут же все очевидно». Для него, в его контексте 🙂 На деле же, у коллег в голове свои определения — иногда близкие, иногда противоположные. В результате появляется иллюзия единства, которая на поверку оказывается недопониманием: думаем, что договорились, а на самом деле каждый остался при своем.

▪️ Примеры:
– «Премиальный клиент» для одних — участник программ лояльности, для других — просто клиент с высоким депозитом, для третьих — статус по определённой подписке
– В сессии про складскую логистику параллельно используются названия FBO и FBS — для одних это тип склада, для других способ доставки, для третьих вообще внутренний отчетный признак
– «Оплата» – одни считают оплатой момент выставления счета, другие — факт поступления денег, а третьи — завершенную банковскую транзакцию

Так же стоит обратить внимание на технические термины (коих в целом быть не должно).

▪️Обобщив, можно выделить такие паттерны:
– Технические акронимы (всякие API, CRM, MVP, …), особенно перегруженные определениями. «Где-то слышал, значит понимаю». Предполагает общее понимание, но чаще каждый вкладывает свой смысл
– Пограничные термины (CAPEX/OPEX, FBO/FBS) - трактуются по-разному в смежных областях
– Неявные классификации (премиум) – для таких терминов нужны не только определения, но и критерии принадлежности
– ВременнЫе характеристики – все эти SLA и прочие, для них должны быть определены конкретные границы
– Самое частое – универсальные термины (клиент, платеж), у которых могут быть сотни определенний даже в рамках одной компании

▪️Почему сессия проведена, а о терминах не договорились?
Тут тоже несколько причин:
– Разные подразделения используют собственную терминологию для одних и тех же концепций и у них не возникает даже мысли, что кто-то может использовать другое определение
– Опытные участники предполагают, что их глубокое понимание разделяют все остальные
– Участники избегают показаться некомпетентными, соглашаясь с неясными терминами
– Участники экстраполируют понимание, основываясь на узком круге коллег

▪️Как выявить проблему во время сессии?
Есть ряд маркеров для наблюдения:
– Использование слов «это», «то», «та штука» без конкретизации
– Фразы типа «ну, вы знаете, о чем я»
– Переключение на жаргон середины предложения
– Затянувшиеся паузы после вопросов о терминах
– Рисование схем вместо словесных объяснений
– Быстрое согласие без дополнительных вопросов
– Переход к следующей теме при появлении неясности
– Избегание детализации «очевидных» понятий
– Молчание при просьбе привести примеры

▪️В рамках сессии, чтобы максимально снизить проявление этой проблемы можно использовать несколько фасилитационных механик:
– Самая рабочая, но за которую участники могут вначале невзлюбить фасилитатора – глупые/наивные вопрос: «Что такое платеж в вашем контексте?» даже если термин кажется очевидным.
– При появлении любого термина просить письменное определение на стикере на видном месте
– Для каждого понятия просить конкретные примеры из практики
– Техника альтернатив – может ли этот термин означать что-то еще в нашей компании?
– Связывание абстрактных терминов с конкретными процессами
– Каждый термин поочередно объясняют разные участники, сравнивают свои версии, вырабатывают единое определение и фиксируют согласованную трактовку

▪️Можно заложить ряд правил и провести ряд действий еще до сессии:
– Собрать терминологию от каждой команды и составить список спорных заранее (редко удается)
– Добавить junior’ов, которые будут задавать очевидные вопросы 🙂
– Ввести правило «нет глупых вопросов» (кто был у меня на любых курсах, помнит это правило 🙂 )
– Объявить обязательность определений для всех терминов
– Установить временные слоты для разбора терминологии
– Правило «если термин непонятный - красный стикер» и запрет на продолжение сессии до согласования определений

Надеюсь, что этот материал будет вам полезен и наведет на мысли как улучшить ваши сессии event storming 🙂 Если есть еще мысли/идеи, можете добавить в комментарии, я добавлю в этот материал.