Веб-версияОткрыть в Telegram
EEvent Storming

Event Storming

@event_storming · канал · Технологии · в индексе с 2026-05-25
1 705подписчиков+4 за неделю
139постов в индексе
Сергей Баранов
Решил попробовать формат серий постов, чтобы тематики были не такими разрозненными, привнести больше целенаправленности. Первая серия, которую хочу сделать – «Темные стороны Event Storming» Дело в том, что иногда складывается ощущение, что про event storming уже все написано и все ошибки давно разобраны, на самом же деле настоящая практика всегда чуть сложнее и чуть глубже, чем кажется из описаний сессий. Я немного порефлексировал и собрал самые сложные и неочевидные истории, встречающиеся регулярно. Некоторым из участников этого канала я их уже рассказывал лично, а кто-то, может быть, узнает свою сессию. Расскажу и про тишину экспертов и про иллюзию консенсуса и про колоритные примеры, которые уводят обсуждения в сторону. Пока набралось семь тем, а там посмотрим. Цель простая – дать честный срез как бывает, зачем это видеть и что с этим делать. Смысл в том, что ошибки, которые повторяет каждая группа, очень похожи, а опыт приходится нарабатывать каждый раз свой. Как этим пользоваться – выбор каждого, кто-то прокачает свой скилл, кто-то обратиться за проведением сессии, понимая, что может не потянуть, тут каждый решает сам, но уж совершенно точно наиболее рациональным будет поделиться, а не замыкать в себе. Сегодня выйдет первый пост на тему «Ложное согласование понятий»
10 · 3.8K ·
Ложное согласование понятий Ложное согласование понятий — это эффект, когда всем кажется, что разговор идет об одном и том же, но на деле за привычными словами у каждого прячется свой смысл. Одна из целей ES как раз в том, чтобы такие понятия прояснить. На практике это выглядит так: кто-то говорит слово/термин и уверен, что все понимают его точно так же, ведь «тут же все очевидно». Для него, в его контексте 🙂 На деле же, у коллег в голове свои определения — иногда близкие, иногда противоположные. В результате появляется иллюзия единства, которая на поверку оказывается недопониманием: думаем, что договорились, а на самом деле каждый остался при своем. ▪️ Примеры: – «Премиальный клиент» для одних — участник программ лояльности, для других — просто клиент с высоким депозитом, для третьих — статус по определённой подписке – В сессии про складскую логистику параллельно используются названия FBO и FBS — для одних это тип склада, для других способ доставки, для третьих вообще внутренний отчетный признак – «Оплата» – одни считают оплатой момент выставления счета, другие — факт поступления денег, а третьи — завершенную банковскую транзакцию Так же стоит обратить внимание на технические термины (коих в целом быть не должно). ▪️Обобщив, можно выделить такие паттерны: – Технические акронимы (всякие API, CRM, MVP, …), особенно перегруженные определениями. «Где-то слышал, значит понимаю». Предполагает общее понимание, но чаще каждый вкладывает свой смысл – Пограничные термины (CAPEX/OPEX, FBO/FBS) - трактуются по-разному в смежных областях – Неявные классификации (премиум) – для таких терминов нужны не только определения, но и критерии принадлежности – ВременнЫе характеристики – все эти SLA и прочие, для них должны быть определены конкретные границы – Самое частое – универсальные термины (клиент, платеж), у которых могут быть сотни определенний даже в рамках одной компании ▪️Почему сессия проведена, а о терминах не договорились? Тут тоже несколько причин: – Разные подраздел
16 · 1.2K ·
С
▪️Можно заложить ряд правил и провести ряд действий еще до сессии: – Собрать терминологию от каждой команды и составить список спорных заранее (редко удается) – Добавить junior’ов, которые будут задавать очевидные вопросы 🙂 – Ввести правило «нет глупых вопросов» (кто был у меня на любых курсах, помнит это правило 🙂 ) – Объявить обязательность определений для всех терминов – Установить временные слоты для разбора терминологии – Правило «если термин непонятный - красный стикер» и запрет на продолжение сессии до согласования определений Надеюсь, что этот материал будет вам полезен и наведет на мысли как улучшить ваши сессии event storming 🙂 Если есть еще мысли/идеи, можете добавить в комментарии, я добавлю в этот материал.
10 · 1.2K ·
С
Сергей Баранов
Молчащие эксперты и «невидимые блокеры» Молчащие эксперты — это эффект, когда внешне сессия кажется продуктивной, но критически важные детали и проблемы остаются невыявленными, потому что именно знающие люди предпочли ничего не озвучить. Именно молчащие, не молчаливые. Потому что молчаливые по природе отличается от молчащих по иным причиным. ▪️Примеры: – При обсуждении бизнес-процессов важные вопросы остаются отмеченными «?» на доске, но никто из экспертов их не комментирует – Один человек упоминается множество раз подряд в различных процессах. Это может свидетельствовать о том, что остальные участники предпочли молчать, позволив одному эксперту доминировать в обсуждении – Один-два специалиста ведут разговор, остальные ограничиваются молчаливым согласием — решения принимаются с опорой на ограниченный опыт – Детали («как именно это работает?») намеренно или неосознанно обходятся стороной: «Тут все ясно, идём дальше» – На критически важных блоках появляется множество стикеров с вопросами, но ни один не разбирается детально ▪️Обобщая, можно выделить такие паттерны: – Накопление на доске вопросов без последующей детализации – Быстрое закрытие тем при появлении сложных вопросов – Молчание после постановки неудобного/неочевидного вопроса – Визуальное доминирование одного эксперта: в модели встречается только одна фамилия в ряде карточек – Использование расплывчатых формулировок («обычно делаем так», «интуитивно понятно») – Преобладание стандартных сценариев без ветвлений и альтернатив ▪️Почему знающие люди молчат? – Страх показаться некомпетентным или не своим, своего рода синдром самозванца (если замечаете за собой, почитайте как справится с этим синдромом, это будет полезно в целом) – Молчание, чтобы не идти против «лидера» – Усталость и формальное участие («скорее бы закончить») – Ощущение, что тема нерелевантна лично эксперту (но при этом она критична для других) – Культура избегания обсуждения сложных или конфликтных вопросов, – «кто-то другой разберется». Эдакая
7 · 1.2K ·
Сергей Баранов
Потеря фокуса Потеря фокуса — это дисфункция процесса, при которой участники отклоняются от структурированного моделирования доменных событий и погружаются в неконтролируемые дискуссии, не связанные с непосредственной целью сессии. Проблема характеризуется переходом от визуального мышления с использованием стикеров к вербальным спорам без фиксации результатов. Сопровождается нарушением важного правила – «все, что обсуждается, должно быть отражено на доске». Проявлятеся в трех измерениях: – когнитивном, когда участники перестают понимать цель – процессном, когда нарушается структура сессии – коммуникативном, когда падает качество взаимодействия между участниками ▪️Основные причины потери фокуса – Cессия без ясного понимания того, что именно должно быть достигнуто. Это приводит к тому, что участники не знают, на что направить свои усилия. Имейте в виду, что зачастую цель находится на более высоком уровне и Event Storming - лишь один из инструментов, который вносит свой вклад в достижение цели и вот этот вклад и должен быть целью проведения Event Storming. Я бы этот пункт даже назвал не причиной потери, а причиной отсутствия фокуса – Преобладание технических специалистов при недостатке доменных экспертов. Как показывает опыт, это приводит к техническим дискуссиям вместо моделирования бизнес-процессов – В удаленных сессиях особенно сильно проявляется психологический эффект, когда мнение одного или нескольких участников начинает доминировать и влиять на мышление всей группы, что опять же уводит от основной цели – Статистически люди могут поддерживать полную концентрацию на задаче в течение 15-30 минут, реже 45. Без правильного управления перерывами и ритмом работы участники теряют фокус и начинают отвлекаться, соответственно - терять фокус – Увы, но в удаленных сессиях технические проблемы (плохой звук, тормоза) могут привести к потере контекста обсуждения ▪️Как проявляется во время сессии? – Участники перестают активно участвовать – Появляются разговоры, не связанны
8 · 950 ·
Фотография
нажмите — покажем
Пример того, как собирать метаинформацию в онлайн-сессиях. То же самое можно спросить про уровень вовлеченности, понимание целей, в принципе по любым категориям и если где-то все точки в красной зоне - это проблема, нужна проработка. Это к пункту «Заготовить инструменты для сбора обратной связи об уровне энергии участников (для онлайна, так как людей не видно)»
2 · 992 ·
С
Фотография
нажмите — покажем
Примеры аспектов обсуждения в зависимости от целей проведения самих сессий (не бизнес-целей компании). Это к тому, вокруг чего строить фокусную структуру самой сессии. Это не значит, что в рамках конкретной цели не важные иные аспекты, это означает, что должно быть в центре внимания, а остальное – дополнение к основным аспектам исследования.
5 · 1.4K ·
С
Сергей Баранов
Напишите в комментариях о чем было бы интересно почитать, о каких проблемах или что непонятно и стоит разобрать, а то судя по реакциям, последние сообщения не вызывают особого интереса 🙂
1.3K ·
E
Event Storming
Фотография
нажмите — покажем
🗓️ Вебинар 30 октября в 19:00 Ведущий: Сергей Баранов Модульность без фанатизма: о чем на самом деле книга Balancing Coupling Встречаемся с Владом Хононовым — архитектором и автором книг «Learning Domain-Driven Design» и «Balancing Coupling in Software Design». Именно об идеях из второй книги мы и поговорим. Этот вебинар пройдет в формате живой беседы-интервью. Обсудим, как находить баланс между связанностью и модульностью, избегать крайностей в архитектурных решениях и почему связанность не всегда зло — иногда она делает систему прочнее. Разберем модель Strength–Distance–Volatility и покажем, как применять эти принципы при проектировании устойчивых распределенных систем. 🚀 Приглашаем архитекторов, тимлидов и разработчиков, которые хотят глубже понять тему модульности. Посмотрим на практические подходы к архитектуре и убедимся, что структурная связанность может стать основой надежности и эволюционного развития системы. 👉 Регистрация по ссылке
13 · 1.1K ·
Event Storming
По просьбам подписчиков попробую пересказать предыдущий пост простыми словами. Онтология отражает язык вашей предметной области, на котором вы разговариваете каждый день в своей работе. Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать. Когда вы создаёте онтологию, вы формализуете этот язык, чтобы его одинаково понимали и вы, и ваши коллеги, и машины. В процессе создания онтологии вы и другие эксперты договариваетесь о терминах и делаете неявные знания явными. Одновременно вы создаёте и «скелет» знаний для LLM — основу, на которую модель сможет опираться при решении ваших задач. LLM прекрасно натренированы на синтаксисе формальных онтологий (например, Turtle) и хорошо его понимают. Передавая онтологию в контекст LLM через промпт (in-context learning), вы выполняете «заземление» рассуждений модели (grounding) и резко снижаете вероятность галлюцинаций. Модель буквально начинает говорить на вашем языке. Структура формальных онтологий (тройки субъект-предикат-объект) естественным образом отображается на структуру графовых баз данных. Разрабатывая онтологию, вы фактически проектируете схему вашей будущей графовой базы данных. А дальше — всего один шаг, чтобы начать разговаривать с вашими данными в графовой БД на вашем языке. Отдельный вызов — научиться фреймить контексты, чтобы не перегружать LLM и управлять её вниманием. То есть не просто передавать в модель всю онтологию, а динамически собирать из неё релевантные подграфы — «подъязыки», соответствующие конкретным задачам. О многом из сказанного в этом тексте я уже писал в своих предыдущих постах — и пытливый ум при желании мог воссоздать эту «картину» ещё несколько месяцев назад.
8 · 1.9K ·
E
E
Event Storming
Продолжение про «похожие процессы» и про важность DDD. (кажется, получился очень глубокий и важный пост про важность DDD) Конкретным профессиям и их внутренней кухне (туризму, логистике, финансам, медицине) в профильных вузах учат годами. Для тех, кто прошел такой путь, типовые процессы внутри их отрасли выглядят очень похожими: одни и те же шаги, одни и те же риски, одни и те же точки принятия решений. Но есть один нюанс… Взять сферу туризма – это отдельная профессия, ей учатся по пять лет, чтобы нормально разбираться в маршрутах, сезонах, рисках, партнерах и ожиданиях клиентов. И взять разработчика – тоже лет пять только чтобы уверенно писать код, понимать архитектуру, паттерны, инфраструктуру. И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает. В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать». Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без…. У него нет такого же целостного и глубокого представления о процессе, как у эксперта в туризме. Прилетает задача: «сделай бронь места в гостинице, вот тут предоплата, вот тут подтверждение». Он честно реализует эту отдельную фичу. Потом еще одну. Потом «быструю доработку к сезону». Потом срочный костыль «потому что партнер меняет правила». Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой И вот в системе сотня мест, где бизнес-жвачка намотана на технический долг и любая попытка рефакторинга превращается в операцию на сердце. С должным усилием, упорством и желанием этот разработчик вырастает до архитектора. Он наконец смотрит на весь процесс целиком и понимает, что 90% кода мож
6 · 1.2K ·
E
Event Storming
Фокус проведения Event Storming В четвертом квартале у меня сильно сместился фокус проведения сессий Event Storming. Причем, не постепенно, а достаточно резко. Проведено много сессий в рамках стратегический сессий, на которых Event Storming выступал как метод формирования общего представления о текущей реальности для того, чтобы сонаправить участников стратегических сессий. Интересно и то, что я не вижу подобного использования Event Storming в международных статьях и выступлениях. Как-будто мы снова проигрываем в международном PR, но при этом развиваем подходы достаточно активно и динамично. Ключевым вопросом, вокруг которого строится весь дизайн, становится: список уязвимых мест компании, которые сильнее всего зависят от внешних и внутренних потрясений и связь инициатив с этими уязвимыми местами. Часто на сессии приходят с уже проработанными уязвимыми местами и инициативами, стратегическая сессия выступает финализацией, способом сонаправить инициативы и заложить механизмы надежности, а Event Storming выступает в качестве карты, на которой отражены все ключевые и значимые для компании события. Представители различных блоков, обычно, хорошо понимают всю систему, однако понимание иногда расходится в детялях, либо упускает один два фактора, например, все учитывают: - Изменения в мировой финансовой системе - Технологические сдвиги - Поведение глобальных конкурентов - Поведение локальных конкурентов Но только часть серьезно учитывает климатическую повестку, и это как раз помогает в установлении сонаправленности. Приведу пример (из прошлого): Ратифицировано Парижское соглашение по климату (внешнее) Федеральный закон «Об ограничении выбросов парниковых газов» вступил в силу (внешнее) Принято обязательство о достижении углеродной нейтральности операционной деятельности (внутреннее) Паттерн: Международное обязательство страны -> Национальное законодательство -> Корпоративная стратегия
6 · 1.2K ·
Event Storming
Файл
tarasenko01.pdf · 213 КБ · нажмите — покажем
Файл
stakeholders.pdf · 170 КБ · нажмите — покажем
Наступает время личных и корпоративных стратегических выборов Стратегический выбор стоит начинать не с выбора решений, а с тщательного исследования Problem Space – что именно является проблемой, для кого и почему это вообще проблема. В связи с этим – полезный материал по изучению проблемы и выбора типов решений (полагаю, Тарасенко для большинства подписчиков моего канала – вовсе не новая фамилия, а для кого новая – рекомендую его работы). Отдельно добавлю про технологическую стратегию. Для нее это означает, что «правильность» выбора направления развития нельзя обсуждать в вакууме. Необходимо явно перечислить стейкхолдеров, их интересы и критерии (качество, риски, скорость, стоимость, комплаенс, …), потому что именно в Problem Space формируются ограничения и критерии будущих решений. Сама идея «улучшающего вмешательства» (никому не хуже, кому-то лучше) полезна как граница для технологических инициатив, то есть хорошая стратегия должна улучшать положение целевых групп и не создавать новых проблем для остальных (безопасность/эксплуатация/финансы/…). Это очень полезные 16 страниц 🚀
23 · 1.1K ·
E
👆максимально полезно для Event Storming
1.3K ·
Event Storming
Фотография
нажмите — покажем
Разомнемся на выходных? :) Ситуация с которой вы столкнетесь не раз и не два. Итак, представьте. Вы проводите Event Storming в службе поддержки клиентов. Служба поддержки использует 7 каналов взаимодействия с клиентами (телефон, чат, почта, …), клиенты бывают 3 разных типов (vip, обычный+, обычный), количество продуктов на поддержке - 50+. Структуру можно организовать разными способами (слева направо, см пример на картирнке): - Свимлейны с каналами, и для каждого канала свимлейны с продуктами - Свимлейны с продуктами, и для каждого канала внутри свимлейны с каналами - Глобальные свимлейны для типов клиентов, внутри свимлейны для продуктов, внутри продуктов - свимлейны для каналов - … - и еще 11 способов (в том числе с только одним или вообще без свимлейнов) Отмечу, что все структуры будут корректными, они ведь все описывают одну и ту же предметную область, но форма будет отличаться и для конкретного этого примера есть одна наиболее подходящая форма представления. Вопрос: как бы вы визуализировали такую структуру и почему? UPD_1: Денис задал хороший вопрос: «смотря для чего проводим». Это очень правильный вопрос, так как Event Storming – лишь инструмент. Проводим для того, чтобы исследовать предметную область и из текущей реализации вынести специфичную для продуктов логику, тем самым защитив реализацию платформы поддержки от попадания элементов предметной области конкретных продуктов. То есть, чтобы сопоставить модель предметной области и модель текущей реалзации и выявить расхождения.
4 · 1.3K ·
E
текст ещё не в индексе
E
Event Storming
ОтветРазомнемся на выходных? :) Ситуация с которой вы столкнетесь не раз и не два. Итак, представьте. Вы проводите Event Storming в службе поддержки клиентов. Служба поддержки использует 7 каналов взаимодействия с клиентами (телефон, чат, почта, …), клиенты бывают 3 разных типов (vip, обычный+, обычны
Ответ к заданию 1. Не нужно выбирать единый свимлейн на всю модель 2. Вход в модель по каналам (свои события входа, своя модель подтверждения личности, свой UX) 3. После того, как определено намерение клиента (это может быть проблема, информация) - канал перестает иметь значение. 4. После того, как определено, что нужно сделать, в игру вступают продукты – они обозначаются как системы, так как по отношению к предметной области поддержки клиентов они и являются внешними системами. Почему нет свимлейнов по типам клиентов (vip, …)? Тип клиента - это атрибут, а не процесс. Если выделить в отдельный свимлейн, то 90% событий будут дублироваться. Здесь как раз нужны политики (Policy) маршрутизации по типу клиента. Почему нет свимлейнов по продукту? Клиент живет в проблеме, а не продукте, а продукты – вообще внешние по отношению к рассматриваемой предметной области. Проблема «не прошла оплата» может относиться к множеству продуктов.
2 · 1.4K ·
E
Event Storming
Формирование рабочей группы по разработке методологии «Стратегического Event Storming» На выходных меня не отпускала мысль, что что-то есть в предложении Юрия Куприянова интегрировать форсайт и Event Storming. Ведь фактически форсайт – это и есть варианты продолжения цепочек событий, но в будущее, а стратегическая сессия – это ограниченитель, фильтр для отбора вариантов. Когда кроссфункциональная команда создает событийную модель, на которой размещаются не только внутренние бизнес-события, но и внешние факторы – изменения в законодательстве, технологические сдвиги, действия конкурентов, макроэкономические тренды, – проявляются паттерны зависимостей между событиями разного масштаба и природы. Визуализация на единой временной шкале событий от глобального до корпоративного уровня создает естественную основу для интеграции с форсайтом – продления событийной модели в будущее, построения альтернативных сценариев и формирования адаптивных стратегий. Интересно, что подобного использования Event Storming практически нет в публичных материалах в международной практике – метод остается преимущественно в пространстве технического проектирования. Мы можем стать первыми, кто систематизирует этот подход и сделает его воспроизводимым инструментом! Что будем делать - Систематизируем опыт - Создадим методологическую базу - Подготовим к публикации - Протестируем Временные затраты 5-15 часов в неделю в течение 3 месяцев (февраль - апрель) Что получите - Соавторство - Опыт создания воспроизводимого метода с нуля - Новые связи среди единомышленников - Возможность применять результаты в своей практике - Что-то свое :) Сам я это воспринимаю как создание чего-то значимого, что будет использоваться другими в том или ином виде. Если вы готовы к серьезной работе с амбициозной целью – буду рад видеть вас в команде. 📝 Ссылка на анкету для подачи заявки на участие (будет отбор): https://forms.gle/WFSX6akDVA6NLqgY7 Дедлайн подачи заявок: 16 января 2026 Отбор и формирование рабочей груп
28 · 5.1K ·
E
Event Storming
Фотография
нажмите — покажем
Темпоральность в Event Storming Вчера обсуждали с Геной Кругловым темпоральность в Event Storning, а сегодня выступал перед участниками IN HUB с темой «Картина производственной системы за часы» (домен промышленного производства и смежных отраслей) и был у меня в презентации такой слайд и вчерашнее обсуждение и сегодняшнее выступление привели к новым мыслям. Так вот, на этом слайде сразу четыре темпоральности (авторская интерпретация и она может измениться): ▪️Хаос (Chaotic Exploration) Здесь только темпоральность события как высказывания с точки зрения семантики (по модели Рейхенбаха). События концептуально относены ко времени. ▪️Хронология (timeline enforcement) Это интерсубъективно разделяемая хронология. Ключевой смысл в том, что здесь появляется темпоральность модели как структуры. В самой структуре появляется отношение порядка. Однако, пока только порядка (раньше/позже) и это важно. ▪️Контекст (обогащение модели, в первую очередь через Policy в рассматриваемом контексте) В хронологии появляется своего рода реактивная темпоральность. На самом деле это кусочки реактивной темпоральности. Политики позволяют отличить автоматизированную реактивность от человеческой и вводят критерий верификации модели: Почему эта команда выполняется? При каких условиях? Всегда ли? Отсутствие явных политик делает причинно-следственные связи неявными и модель теряет способность отвечать на вопросы «Почему?» и «В каком случае/когда?» ▪️История (Narrative / Reverse Narrative) А здесь самое интересное. Это нарративная темпоральность (Paul Ricoeur, Джером Брунер), история, общий нарратив, обеспечивает переход от «позже - не значит вследствие» к «это вследствие вот этого». Это усиление темпоральности модели причинно-следственными связями. А теперь прикладной вывод: если мы можем построить согласованную историю, построенную полностью на основе реактивной автоматизированной темпоральности (между каждым событием и командой поставить Policy), то мы можем с большей степенью уверенности г
8 · 1.6K ·
E
Event Storming
Видео
Основы_Event_Storming_на_основе_материлов_курса_NotbookLM.mp · 35.4 МБ · нажмите — покажем
Вот так Notebooklm сжал теорию первого дня корп курса по Event Storming, очень хорошо сжал, я бы сказал. Никакой лишней информации нет, так что можно выложить :)
179 · 6.2K ·

Открытая публичная лента из поискового индекса ChatCrawler — «Google по публичному Telegram»; обновляется по мере обхода площадки. Время — UTC.

Только публичный контент, официальный API Telegram. О проекте · Вопросы · Чего мы не делаем · Убрать страницу из выдачи · Каталог · Поиск · Как мы считаем