А имеет вообще смысл написать на русском небольшую книгу-инструкцию по 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 🙂 Если есть еще мысли/идеи, можете добавить в комментарии, я добавлю в этот материал.

Молчащие эксперты и «невидимые блокеры»

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

▪️Примеры:
– При обсуждении бизнес-процессов важные вопросы остаются отмеченными «?» на доске, но никто из экспертов их не комментирует
– Один человек упоминается множество раз подряд в различных процессах. Это может свидетельствовать о том, что остальные участники предпочли молчать, позволив одному эксперту доминировать в обсуждении
– Один-два специалиста ведут разговор, остальные ограничиваются молчаливым согласием — решения принимаются с опорой на ограниченный опыт
– Детали («как именно это работает?») намеренно или неосознанно обходятся стороной: «Тут все ясно, идём дальше»
– На критически важных блоках появляется множество стикеров с вопросами, но ни один не разбирается детально

▪️Обобщая, можно выделить такие паттерны:
– Накопление на доске вопросов без последующей детализации
– Быстрое закрытие тем при появлении сложных вопросов
– Молчание после постановки неудобного/неочевидного вопроса
– Визуальное доминирование одного эксперта: в модели встречается только одна фамилия в ряде карточек
– Использование расплывчатых формулировок («обычно делаем так», «интуитивно понятно»)
– Преобладание стандартных сценариев без ветвлений и альтернатив

▪️Почему знающие люди молчат?
– Страх показаться некомпетентным или не своим, своего рода синдром самозванца (если замечаете за собой, почитайте как справится с этим синдромом, это будет полезно в целом)
– Молчание, чтобы не идти против «лидера»
– Усталость и формальное участие («скорее бы закончить»)
– Ощущение, что тема нерелевантна лично эксперту (но при этом она критична для других)
– Культура избегания обсуждения сложных или конфликтных вопросов, – «кто-то другой разберется». Эдакая культура перекладывания ответственности.
– Групповое мышление и подсознательный эффект наблюдателя: если никто не спрашивает — значит все ясно

▪️Как проявляется во время сессии?
– Длинные паузы после важных/неприятных вопросов
– На доске появляются скопления неотвеченных вопросов
– Один человек постоянно на виду, остальные малоактивны
– Группа быстро соглашается на поверхностные объяснения, без обсуждения альтернатив
– Часто встречаются фразы «давайте пойдём дальше», «вернёмся потом», «и так понятно же»

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

Потеря фокуса

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

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

▪️Основные причины потери фокуса
– Cессия без ясного понимания того, что именно должно быть достигнуто. Это приводит к тому, что участники не знают, на что направить свои усилия. Имейте в виду, что зачастую цель находится на более высоком уровне и Event Storming - лишь один из инструментов, который вносит свой вклад в достижение цели и вот этот вклад и должен быть целью проведения Event Storming. Я бы этот пункт даже назвал не причиной потери, а причиной отсутствия фокуса
– Преобладание технических специалистов при недостатке доменных экспертов. Как показывает опыт, это приводит к техническим дискуссиям вместо моделирования бизнес-процессов
– В удаленных сессиях особенно сильно проявляется психологический эффект, когда мнение одного или нескольких участников начинает доминировать и влиять на мышление всей группы, что опять же уводит от основной цели
– Статистически люди могут поддерживать полную концентрацию на задаче в течение 15-30 минут, реже 45. Без правильного управления перерывами и ритмом работы участники теряют фокус и начинают отвлекаться, соответственно - терять фокус
– Увы, но в удаленных сессиях технические проблемы (плохой звук, тормоза) могут привести к потере контекста обсуждения

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

▪️Что делать?
Снова есть повторения 🙂
Профилактика:
– Четко сформулировать цель сессии и донести ее до всех участников
– Провести предварительные интервью с ключевыми доменными экспертами для понимания основных концепций
– Определить четкие границы моделирования (scope) и зафиксировать их
– Обеспечить баланс между бизнес-экспертами и техническими специалистами
– Для удаленных сессий провести техническую проверку за несколько дней
– Подготовить четкий план сессии с временными рамками для каждой фазы
– Заготовить инструменты для сбора обратной связи об уровне энергии участников (для онайна, так как людей не видно)
– Подготовить набор техник для перенаправления обсуждения при необходимости
Во время самой сессии:
– Активно направлять обсуждение обратно к доменным событиям
– Сложные вопросы записывать на отдельные стикеры (hotspots) для последующего разбора
– Переформулировать абстрактные высказывания в конкретные события
– Для онлайна использовать технику «поднятия руки» для управления очередностью
– Повторять сказанное участником более конкретно (зеркалирование, техника из арсенала активного слушания)
– При доминировании одного участника активно привлекать к обсуждению других
– Одно из моих любимых: требовать конкретных примеров для каждого общего утверждения
– Использовать технику Альберто Брандолини «поворота стикеров» — плохо написанные события поворачивать на 45 градусов до их переписывания; если платформа не позволяет - другой визуальный маркер

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

Это к пункту «Заготовить инструменты для сбора обратной связи об уровне энергии участников (для онлайна, так как людей не видно)»

Еще более простая конструкция сбора метаинформации.

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

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

По просьбам подписчиков попробую пересказать предыдущий пост простыми словами.

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

Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать.

Когда вы создаёте онтологию, вы формализуете этот язык, чтобы его одинаково понимали и вы, и ваши коллеги, и машины.

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

Одновременно вы создаёте и «скелет» знаний для LLM — основу, на которую модель сможет опираться при решении ваших задач.

LLM прекрасно натренированы на синтаксисе формальных онтологий (например, Turtle) и хорошо его понимают.

Передавая онтологию в контекст LLM через промпт (in-context learning), вы выполняете «заземление» рассуждений модели (grounding) и резко снижаете вероятность галлюцинаций.

Модель буквально начинает говорить на вашем языке.

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

А дальше — всего один шаг, чтобы начать разговаривать с вашими данными в графовой БД на вашем языке.

Отдельный вызов — научиться фреймить контексты, чтобы не перегружать LLM и управлять её вниманием. То есть не просто передавать в модель всю онтологию, а динамически собирать из неё релевантные подграфы — «подъязыки», соответствующие конкретным задачам.

О многом из сказанного в этом тексте я уже писал в своих предыдущих постах — и пытливый ум при желании мог воссоздать эту «картину» ещё несколько месяцев назад.