Молчащие эксперты и «невидимые блокеры»
Молчащие эксперты — это эффект, когда внешне сессия кажется продуктивной, но критически важные детали и проблемы остаются невыявленными, потому что именно знающие люди предпочли ничего не озвучить. Именно молчащие, не молчаливые. Потому что молчаливые по природе отличается от молчащих по иным причиным.
▪️Примеры:
– При обсуждении бизнес-процессов важные вопросы остаются отмеченными «?» на доске, но никто из экспертов их не комментирует
– Один человек упоминается множество раз подряд в различных процессах. Это может свидетельствовать о том, что остальные участники предпочли молчать, позволив одному эксперту доминировать в обсуждении
– Один-два специалиста ведут разговор, остальные ограничиваются молчаливым согласием — решения принимаются с опорой на ограниченный опыт
– Детали («как именно это работает?») намеренно или неосознанно обходятся стороной: «Тут все ясно, идём дальше»
– На критически важных блоках появляется множество стикеров с вопросами, но ни один не разбирается детально
▪️Обобщая, можно выделить такие паттерны:
– Накопление на доске вопросов без последующей детализации
– Быстрое закрытие тем при появлении сложных вопросов
– Молчание после постановки неудобного/неочевидного вопроса
– Визуальное доминирование одного эксперта: в модели встречается только одна фамилия в ряде карточек
– Использование расплывчатых формулировок («обычно делаем так», «интуитивно понятно»)
– Преобладание стандартных сценариев без ветвлений и альтернатив
▪️Почему знающие люди молчат?
– Страх показаться некомпетентным или не своим, своего рода синдром самозванца (если замечаете за собой, почитайте как справится с этим синдромом, это будет полезно в целом)
– Молчание, чтобы не идти против «лидера»
– Усталость и формальное участие («скорее бы закончить»)
– Ощущение, что тема нерелевантна лично эксперту (но при этом она критична для других)
– Культура избегания обсуждения сложных или конфликтных вопросов, – «кто-то другой разберется». Эдакая культура перекладывания ответственности.
– Групповое мышление и подсознательный эффект наблюдателя: если никто не спрашивает — значит все ясно
▪️Как проявляется во время сессии?
– Длинные паузы после важных/неприятных вопросов
– На доске появляются скопления неотвеченных вопросов
– Один человек постоянно на виду, остальные малоактивны
– Группа быстро соглашается на поверхностные объяснения, без обсуждения альтернатив
– Часто встречаются фразы «давайте пойдём дальше», «вернёмся потом», «и так понятно же»
▪️Что делать?
Когда начал составлять перечень антидотов, заметил, что часть из них - те же, что и озвученные ранее, видимо и дальше они будут повторяться.
– Ввести правило «нет глупых вопросов» и подкреплять действиями, – поощрять уточнения («Отличный вопрос, спасибо»)
– Использовать анонимный сбор вопросов
– Просить записывать вопросы сразу и выделять время для их совместного разбора
– Специально обращаться к менее активным участникам
– Разделять участников по малым группам для обсуждения, после чего выводить результаты в общее пространство
– Ввести роль «адвоката дьявола», который провоцирует команду на неудобные размышления; обычно это заказчик сессии и я его параллельо в чате могу попросить что-нибудь спросить
– По окончании давать обратную связь, запрашивать анонимные дополнения, документировать неразрешенные вопросы и договариваться о последующей проработке
– В некоторых статьях рекомендуется провести вначале калибровку ожиданий/страхов (что мешает говорить здесь откровенно?) - в моем случае ни разу не помогло, потому что если во время сессии проявляется все описанное здесь, то оно проявится и во время такой калибровки, просто потраченное время
Молчащие эксперты — это эффект, когда внешне сессия кажется продуктивной, но критически важные детали и проблемы остаются невыявленными, потому что именно знающие люди предпочли ничего не озвучить. Именно молчащие, не молчаливые. Потому что молчаливые по природе отличается от молчащих по иным причиным.
▪️Примеры:
– При обсуждении бизнес-процессов важные вопросы остаются отмеченными «?» на доске, но никто из экспертов их не комментирует
– Один человек упоминается множество раз подряд в различных процессах. Это может свидетельствовать о том, что остальные участники предпочли молчать, позволив одному эксперту доминировать в обсуждении
– Один-два специалиста ведут разговор, остальные ограничиваются молчаливым согласием — решения принимаются с опорой на ограниченный опыт
– Детали («как именно это работает?») намеренно или неосознанно обходятся стороной: «Тут все ясно, идём дальше»
– На критически важных блоках появляется множество стикеров с вопросами, но ни один не разбирается детально
▪️Обобщая, можно выделить такие паттерны:
– Накопление на доске вопросов без последующей детализации
– Быстрое закрытие тем при появлении сложных вопросов
– Молчание после постановки неудобного/неочевидного вопроса
– Визуальное доминирование одного эксперта: в модели встречается только одна фамилия в ряде карточек
– Использование расплывчатых формулировок («обычно делаем так», «интуитивно понятно»)
– Преобладание стандартных сценариев без ветвлений и альтернатив
▪️Почему знающие люди молчат?
– Страх показаться некомпетентным или не своим, своего рода синдром самозванца (если замечаете за собой, почитайте как справится с этим синдромом, это будет полезно в целом)
– Молчание, чтобы не идти против «лидера»
– Усталость и формальное участие («скорее бы закончить»)
– Ощущение, что тема нерелевантна лично эксперту (но при этом она критична для других)
– Культура избегания обсуждения сложных или конфликтных вопросов, – «кто-то другой разберется». Эдакая культура перекладывания ответственности.
– Групповое мышление и подсознательный эффект наблюдателя: если никто не спрашивает — значит все ясно
▪️Как проявляется во время сессии?
– Длинные паузы после важных/неприятных вопросов
– На доске появляются скопления неотвеченных вопросов
– Один человек постоянно на виду, остальные малоактивны
– Группа быстро соглашается на поверхностные объяснения, без обсуждения альтернатив
– Часто встречаются фразы «давайте пойдём дальше», «вернёмся потом», «и так понятно же»
▪️Что делать?
Когда начал составлять перечень антидотов, заметил, что часть из них - те же, что и озвученные ранее, видимо и дальше они будут повторяться.
– Ввести правило «нет глупых вопросов» и подкреплять действиями, – поощрять уточнения («Отличный вопрос, спасибо»)
– Использовать анонимный сбор вопросов
– Просить записывать вопросы сразу и выделять время для их совместного разбора
– Специально обращаться к менее активным участникам
– Разделять участников по малым группам для обсуждения, после чего выводить результаты в общее пространство
– Ввести роль «адвоката дьявола», который провоцирует команду на неудобные размышления; обычно это заказчик сессии и я его параллельо в чате могу попросить что-нибудь спросить
– По окончании давать обратную связь, запрашивать анонимные дополнения, документировать неразрешенные вопросы и договариваться о последующей проработке
– В некоторых статьях рекомендуется провести вначале калибровку ожиданий/страхов (что мешает говорить здесь откровенно?) - в моем случае ни разу не помогло, потому что если во время сессии проявляется все описанное здесь, то оно проявится и во время такой калибровки, просто потраченное время
🔥13❤2
Потеря фокуса
Потеря фокуса — это дисфункция процесса, при которой участники отклоняются от структурированного моделирования доменных событий и погружаются в неконтролируемые дискуссии, не связанные с непосредственной целью сессии. Проблема характеризуется переходом от визуального мышления с использованием стикеров к вербальным спорам без фиксации результатов. Сопровождается нарушением важного правила – «все, что обсуждается, должно быть отражено на доске».
Проявлятеся в трех измерениях:
– когнитивном, когда участники перестают понимать цель
– процессном, когда нарушается структура сессии
– коммуникативном, когда падает качество взаимодействия между участниками
▪️Основные причины потери фокуса
– Cессия без ясного понимания того, что именно должно быть достигнуто. Это приводит к тому, что участники не знают, на что направить свои усилия. Имейте в виду, что зачастую цель находится на более высоком уровне и Event Storming - лишь один из инструментов, который вносит свой вклад в достижение цели и вот этот вклад и должен быть целью проведения Event Storming. Я бы этот пункт даже назвал не причиной потери, а причиной отсутствия фокуса
– Преобладание технических специалистов при недостатке доменных экспертов. Как показывает опыт, это приводит к техническим дискуссиям вместо моделирования бизнес-процессов
– В удаленных сессиях особенно сильно проявляется психологический эффект, когда мнение одного или нескольких участников начинает доминировать и влиять на мышление всей группы, что опять же уводит от основной цели
– Статистически люди могут поддерживать полную концентрацию на задаче в течение 15-30 минут, реже 45. Без правильного управления перерывами и ритмом работы участники теряют фокус и начинают отвлекаться, соответственно - терять фокус
– Увы, но в удаленных сессиях технические проблемы (плохой звук, тормоза) могут привести к потере контекста обсуждения
▪️Как проявляется во время сессии?
– Участники перестают активно участвовать
– Появляются разговоры, не связанные с основной темой
– Один человек говорит значительную часть времени, остальные молчат
– Обсуждение смещается к техническим деталям вместо бизнес-событий
– Накапливаются вопросы без ответов
– Обсуждение застревает на деталях одного процесса
▪️Что делать?
Снова есть повторения 🙂
Профилактика:
– Четко сформулировать цель сессии и донести ее до всех участников
– Провести предварительные интервью с ключевыми доменными экспертами для понимания основных концепций
– Определить четкие границы моделирования (scope) и зафиксировать их
– Обеспечить баланс между бизнес-экспертами и техническими специалистами
– Для удаленных сессий провести техническую проверку за несколько дней
– Подготовить четкий план сессии с временными рамками для каждой фазы
– Заготовить инструменты для сбора обратной связи об уровне энергии участников (для онайна, так как людей не видно)
– Подготовить набор техник для перенаправления обсуждения при необходимости
Во время самой сессии:
– Активно направлять обсуждение обратно к доменным событиям
– Сложные вопросы записывать на отдельные стикеры (hotspots) для последующего разбора
– Переформулировать абстрактные высказывания в конкретные события
– Для онлайна использовать технику «поднятия руки» для управления очередностью
– Повторять сказанное участником более конкретно (зеркалирование, техника из арсенала активного слушания)
– При доминировании одного участника активно привлекать к обсуждению других
– Одно из моих любимых: требовать конкретных примеров для каждого общего утверждения
– Использовать технику Альберто Брандолини «поворота стикеров» — плохо написанные события поворачивать на 45 градусов до их переписывания; если платформа не позволяет - другой визуальный маркер
Потеря фокуса — это дисфункция процесса, при которой участники отклоняются от структурированного моделирования доменных событий и погружаются в неконтролируемые дискуссии, не связанные с непосредственной целью сессии. Проблема характеризуется переходом от визуального мышления с использованием стикеров к вербальным спорам без фиксации результатов. Сопровождается нарушением важного правила – «все, что обсуждается, должно быть отражено на доске».
Проявлятеся в трех измерениях:
– когнитивном, когда участники перестают понимать цель
– процессном, когда нарушается структура сессии
– коммуникативном, когда падает качество взаимодействия между участниками
▪️Основные причины потери фокуса
– Cессия без ясного понимания того, что именно должно быть достигнуто. Это приводит к тому, что участники не знают, на что направить свои усилия. Имейте в виду, что зачастую цель находится на более высоком уровне и Event Storming - лишь один из инструментов, который вносит свой вклад в достижение цели и вот этот вклад и должен быть целью проведения Event Storming. Я бы этот пункт даже назвал не причиной потери, а причиной отсутствия фокуса
– Преобладание технических специалистов при недостатке доменных экспертов. Как показывает опыт, это приводит к техническим дискуссиям вместо моделирования бизнес-процессов
– В удаленных сессиях особенно сильно проявляется психологический эффект, когда мнение одного или нескольких участников начинает доминировать и влиять на мышление всей группы, что опять же уводит от основной цели
– Статистически люди могут поддерживать полную концентрацию на задаче в течение 15-30 минут, реже 45. Без правильного управления перерывами и ритмом работы участники теряют фокус и начинают отвлекаться, соответственно - терять фокус
– Увы, но в удаленных сессиях технические проблемы (плохой звук, тормоза) могут привести к потере контекста обсуждения
▪️Как проявляется во время сессии?
– Участники перестают активно участвовать
– Появляются разговоры, не связанные с основной темой
– Один человек говорит значительную часть времени, остальные молчат
– Обсуждение смещается к техническим деталям вместо бизнес-событий
– Накапливаются вопросы без ответов
– Обсуждение застревает на деталях одного процесса
▪️Что делать?
Снова есть повторения 🙂
Профилактика:
– Четко сформулировать цель сессии и донести ее до всех участников
– Провести предварительные интервью с ключевыми доменными экспертами для понимания основных концепций
– Определить четкие границы моделирования (scope) и зафиксировать их
– Обеспечить баланс между бизнес-экспертами и техническими специалистами
– Для удаленных сессий провести техническую проверку за несколько дней
– Подготовить четкий план сессии с временными рамками для каждой фазы
– Заготовить инструменты для сбора обратной связи об уровне энергии участников (для онайна, так как людей не видно)
– Подготовить набор техник для перенаправления обсуждения при необходимости
Во время самой сессии:
– Активно направлять обсуждение обратно к доменным событиям
– Сложные вопросы записывать на отдельные стикеры (hotspots) для последующего разбора
– Переформулировать абстрактные высказывания в конкретные события
– Для онлайна использовать технику «поднятия руки» для управления очередностью
– Повторять сказанное участником более конкретно (зеркалирование, техника из арсенала активного слушания)
– При доминировании одного участника активно привлекать к обсуждению других
– Одно из моих любимых: требовать конкретных примеров для каждого общего утверждения
– Использовать технику Альберто Брандолини «поворота стикеров» — плохо написанные события поворачивать на 45 градусов до их переписывания; если платформа не позволяет - другой визуальный маркер
🔥7❤2👍2
Пример того, как собирать метаинформацию в онлайн-сессиях. То же самое можно спросить про уровень вовлеченности, понимание целей, в принципе по любым категориям и если где-то все точки в красной зоне - это проблема, нужна проработка.
Это к пункту «Заготовить инструменты для сбора обратной связи об уровне энергии участников (для онлайна, так как людей не видно)»
Это к пункту «Заготовить инструменты для сбора обратной связи об уровне энергии участников (для онлайна, так как людей не видно)»
🔥4❤1
Event Storming
Пример того, как собирать метаинформацию в онлайн-сессиях. То же самое можно спросить про уровень вовлеченности, понимание целей, в принципе по любым категориям и если где-то все точки в красной зоне - это проблема, нужна проработка. Это к пункту «Заготовить…
Еще более простая конструкция сбора метаинформации.
🔥5👍2
Примеры аспектов обсуждения в зависимости от целей проведения самих сессий (не бизнес-целей компании). Это к тому, вокруг чего строить фокусную структуру самой сессии. Это не значит, что в рамках конкретной цели не важные иные аспекты, это означает, что должно быть в центре внимания, а остальное – дополнение к основным аспектам исследования.
🔥7❤2
Напишите в комментариях о чем было бы интересно почитать, о каких проблемах или что непонятно и стоит разобрать, а то судя по реакциям, последние сообщения не вызывают особого интереса 🙂
🔥2
Forwarded from ScrumTrek
Ведущий: Сергей Баранов
Модульность без фанатизма: о чем на самом деле книга Balancing Coupling
Встречаемся с Владом Хононовым — архитектором и автором книг «Learning Domain-Driven Design» и «Balancing Coupling in Software Design». Именно об идеях из второй книги мы и поговорим.
Этот вебинар пройдет в формате живой беседы-интервью. Обсудим, как находить баланс между связанностью и модульностью, избегать крайностей в архитектурных решениях и почему связанность не всегда зло — иногда она делает систему прочнее.
Разберем модель Strength–Distance–Volatility и покажем, как применять эти принципы при проектировании устойчивых распределенных систем. 🚀
Приглашаем архитекторов, тимлидов и разработчиков, которые хотят глубже понять тему модульности.
Посмотрим на практические подходы к архитектуре и убедимся, что структурная связанность может стать основой надежности и эволюционного развития системы.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7
Forwarded from Intelligent Systems Architecture
По просьбам подписчиков попробую пересказать предыдущий пост простыми словами.
Онтология отражает язык вашей предметной области, на котором вы разговариваете каждый день в своей работе.
Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать.
Когда вы создаёте онтологию, вы формализуете этот язык, чтобы его одинаково понимали и вы, и ваши коллеги, и машины.
В процессе создания онтологии вы и другие эксперты договариваетесь о терминах и делаете неявные знания явными.
Одновременно вы создаёте и «скелет» знаний для LLM — основу, на которую модель сможет опираться при решении ваших задач.
LLM прекрасно натренированы на синтаксисе формальных онтологий (например, Turtle) и хорошо его понимают.
Передавая онтологию в контекст LLM через промпт (in-context learning), вы выполняете «заземление» рассуждений модели (grounding) и резко снижаете вероятность галлюцинаций.
Модель буквально начинает говорить на вашем языке.
Структура формальных онтологий (тройки субъект-предикат-объект) естественным образом отображается на структуру графовых баз данных.
Разрабатывая онтологию, вы фактически проектируете схему вашей будущей графовой базы данных.
А дальше — всего один шаг, чтобы начать разговаривать с вашими данными в графовой БД на вашем языке.
Отдельный вызов — научиться фреймить контексты, чтобы не перегружать LLM и управлять её вниманием. То есть не просто передавать в модель всю онтологию, а динамически собирать из неё релевантные подграфы — «подъязыки», соответствующие конкретным задачам.
О многом из сказанного в этом тексте я уже писал в своих предыдущих постах — и пытливый ум при желании мог воссоздать эту «картину» ещё несколько месяцев назад.
Онтология отражает язык вашей предметной области, на котором вы разговариваете каждый день в своей работе.
Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать.
Когда вы создаёте онтологию, вы формализуете этот язык, чтобы его одинаково понимали и вы, и ваши коллеги, и машины.
В процессе создания онтологии вы и другие эксперты договариваетесь о терминах и делаете неявные знания явными.
Одновременно вы создаёте и «скелет» знаний для LLM — основу, на которую модель сможет опираться при решении ваших задач.
LLM прекрасно натренированы на синтаксисе формальных онтологий (например, Turtle) и хорошо его понимают.
Передавая онтологию в контекст LLM через промпт (in-context learning), вы выполняете «заземление» рассуждений модели (grounding) и резко снижаете вероятность галлюцинаций.
Модель буквально начинает говорить на вашем языке.
Структура формальных онтологий (тройки субъект-предикат-объект) естественным образом отображается на структуру графовых баз данных.
Разрабатывая онтологию, вы фактически проектируете схему вашей будущей графовой базы данных.
А дальше — всего один шаг, чтобы начать разговаривать с вашими данными в графовой БД на вашем языке.
Отдельный вызов — научиться фреймить контексты, чтобы не перегружать LLM и управлять её вниманием. То есть не просто передавать в модель всю онтологию, а динамически собирать из неё релевантные подграфы — «подъязыки», соответствующие конкретным задачам.
О многом из сказанного в этом тексте я уже писал в своих предыдущих постах — и пытливый ум при желании мог воссоздать эту «картину» ещё несколько месяцев назад.
👍5❤2
Intelligent Systems Architecture
Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать.
Вот тут Event Storming и DDD практически вне конкуренции в части эффективности, причем это индустриально подтвержденные подходы.
👍4❤1
Это из видео про цунами, кому интересно, отсюда - https://www.youtube.com/watch?v=lTxfNHx93hI&t=2203s
:)
:)
🔥2
Forwarded from Блог Сергея Баранова (Сергей Баранов)
Продолжение про «похожие процессы» и про важность DDD.
(кажется, получился очень глубокий и важный пост про важность DDD)
Конкретным профессиям и их внутренней кухне (туризму, логистике, финансам, медицине) в профильных вузах учат годами. Для тех, кто прошел такой путь, типовые процессы внутри их отрасли выглядят очень похожими: одни и те же шаги, одни и те же риски, одни и те же точки принятия решений. Но есть один нюанс…
Взять сферу туризма – это отдельная профессия, ей учатся по пять лет, чтобы нормально разбираться в маршрутах, сезонах, рисках, партнерах и ожиданиях клиентов. И взять разработчика – тоже лет пять только чтобы уверенно писать код, понимать архитектуру, паттерны, инфраструктуру.
И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает.
В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать».
Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без….
У него нет такого же целостного и глубокого представления о процессе, как у эксперта в туризме. Прилетает задача: «сделай бронь места в гостинице, вот тут предоплата, вот тут подтверждение». Он честно реализует эту отдельную фичу.
Потом еще одну.
Потом «быструю доработку к сезону».
Потом срочный костыль «потому что партнер меняет правила».
Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой
И вот в системе сотня мест, где бизнес-жвачка намотана на технический долг и любая попытка рефакторинга превращается в операцию на сердце.
С должным усилием, упорством и желанием этот разработчик вырастает до архитектора.
Он наконец смотрит на весь процесс целиком и понимает, что 90% кода можно выбросить и заменить несколькими коробочными продуктами, одним внешним сервисом и небольшим слоем кастома. Потому что реально уникальное – вот эти самые 5%, где и прячется конкурентное преимущество бизнеса, а все остальное – типовой, стандартный Generic.
Вот эту проблему во многом и решает DDD вместе с практиками вроде Event Storming.
Они как раз про то, как вытащить знание экспертов (в нашем примере – гуру в туризме), перевести его в общий язык и донести до разработчиков и архитекторов так, чтобы все видели одну и ту же цельную картину.
Пока этого понимания нет, «в прод идут лишь предположения разработчиков о предметной области» (c) Альберто Брандолини
Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.
(кажется, получился очень глубокий и важный пост про важность DDD)
Конкретным профессиям и их внутренней кухне (туризму, логистике, финансам, медицине) в профильных вузах учат годами. Для тех, кто прошел такой путь, типовые процессы внутри их отрасли выглядят очень похожими: одни и те же шаги, одни и те же риски, одни и те же точки принятия решений. Но есть один нюанс…
Взять сферу туризма – это отдельная профессия, ей учатся по пять лет, чтобы нормально разбираться в маршрутах, сезонах, рисках, партнерах и ожиданиях клиентов. И взять разработчика – тоже лет пять только чтобы уверенно писать код, понимать архитектуру, паттерны, инфраструктуру.
И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает.
В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать».
Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без….
У него нет такого же целостного и глубокого представления о процессе, как у эксперта в туризме. Прилетает задача: «сделай бронь места в гостинице, вот тут предоплата, вот тут подтверждение». Он честно реализует эту отдельную фичу.
Потом еще одну.
Потом «быструю доработку к сезону».
Потом срочный костыль «потому что партнер меняет правила».
Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой
И вот в системе сотня мест, где бизнес-жвачка намотана на технический долг и любая попытка рефакторинга превращается в операцию на сердце.
С должным усилием, упорством и желанием этот разработчик вырастает до архитектора.
Он наконец смотрит на весь процесс целиком и понимает, что 90% кода можно выбросить и заменить несколькими коробочными продуктами, одним внешним сервисом и небольшим слоем кастома. Потому что реально уникальное – вот эти самые 5%, где и прячется конкурентное преимущество бизнеса, а все остальное – типовой, стандартный Generic.
Вот эту проблему во многом и решает DDD вместе с практиками вроде Event Storming.
Они как раз про то, как вытащить знание экспертов (в нашем примере – гуру в туризме), перевести его в общий язык и донести до разработчиков и архитекторов так, чтобы все видели одну и ту же цельную картину.
Пока этого понимания нет, «в прод идут лишь предположения разработчиков о предметной области» (c) Альберто Брандолини
Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.
🔥8❤2👎1
Фокус проведения Event Storming
В четвертом квартале у меня сильно сместился фокус проведения сессий Event Storming. Причем, не постепенно, а достаточно резко. Проведено много сессий в рамках стратегический сессий, на которых Event Storming выступал как метод формирования общего представления о текущей реальности для того, чтобы сонаправить участников стратегических сессий.
Интересно и то, что я не вижу подобного использования Event Storming в международных статьях и выступлениях. Как-будто мы снова проигрываем в международном PR, но при этом развиваем подходы достаточно активно и динамично.
Ключевым вопросом, вокруг которого строится весь дизайн, становится: список уязвимых мест компании, которые сильнее всего зависят от внешних и внутренних потрясений и связь инициатив с этими уязвимыми местами.
Часто на сессии приходят с уже проработанными уязвимыми местами и инициативами, стратегическая сессия выступает финализацией, способом сонаправить инициативы и заложить механизмы надежности, а Event Storming выступает в качестве карты, на которой отражены все ключевые и значимые для компании события.
Представители различных блоков, обычно, хорошо понимают всю систему, однако понимание иногда расходится в детялях, либо упускает один два фактора, например, все учитывают:
- Изменения в мировой финансовой системе
- Технологические сдвиги
- Поведение глобальных конкурентов
- Поведение локальных конкурентов
Но только часть серьезно учитывает климатическую повестку, и это как раз помогает в установлении сонаправленности.
Приведу пример (из прошлого):
Ратифицировано Парижское соглашение по климату (внешнее)
Федеральный закон «Об ограничении выбросов парниковых газов» вступил в силу (внешнее)
Принято обязательство о достижении углеродной нейтральности операционной деятельности (внутреннее)
Паттерн:
Международное обязательство страны -> Национальное законодательство -> Корпоративная стратегия
В четвертом квартале у меня сильно сместился фокус проведения сессий Event Storming. Причем, не постепенно, а достаточно резко. Проведено много сессий в рамках стратегический сессий, на которых Event Storming выступал как метод формирования общего представления о текущей реальности для того, чтобы сонаправить участников стратегических сессий.
Интересно и то, что я не вижу подобного использования Event Storming в международных статьях и выступлениях. Как-будто мы снова проигрываем в международном PR, но при этом развиваем подходы достаточно активно и динамично.
Ключевым вопросом, вокруг которого строится весь дизайн, становится: список уязвимых мест компании, которые сильнее всего зависят от внешних и внутренних потрясений и связь инициатив с этими уязвимыми местами.
Часто на сессии приходят с уже проработанными уязвимыми местами и инициативами, стратегическая сессия выступает финализацией, способом сонаправить инициативы и заложить механизмы надежности, а Event Storming выступает в качестве карты, на которой отражены все ключевые и значимые для компании события.
Представители различных блоков, обычно, хорошо понимают всю систему, однако понимание иногда расходится в детялях, либо упускает один два фактора, например, все учитывают:
- Изменения в мировой финансовой системе
- Технологические сдвиги
- Поведение глобальных конкурентов
- Поведение локальных конкурентов
Но только часть серьезно учитывает климатическую повестку, и это как раз помогает в установлении сонаправленности.
Приведу пример (из прошлого):
Ратифицировано Парижское соглашение по климату (внешнее)
Федеральный закон «Об ограничении выбросов парниковых газов» вступил в силу (внешнее)
Принято обязательство о достижении углеродной нейтральности операционной деятельности (внутреннее)
Паттерн:
Международное обязательство страны -> Национальное законодательство -> Корпоративная стратегия
❤1👍1🔥1
Forwarded from Блог Сергея Баранова (Сергей Баранов)
tarasenko01.pdf
213.1 KB
Наступает время личных и корпоративных стратегических выборов
Стратегический выбор стоит начинать не с выбора решений, а с тщательного исследования Problem Space – что именно является проблемой, для кого и почему это вообще проблема. В связи с этим – полезный материал по изучению проблемы и выбора типов решений (полагаю, Тарасенко для большинства подписчиков моего канала – вовсе не новая фамилия, а для кого новая – рекомендую его работы).
Отдельно добавлю про технологическую стратегию.
Для нее это означает, что «правильность» выбора направления развития нельзя обсуждать в вакууме. Необходимо явно перечислить стейкхолдеров, их интересы и критерии (качество, риски, скорость, стоимость, комплаенс, …), потому что именно в Problem Space формируются ограничения и критерии будущих решений. Сама идея «улучшающего вмешательства» (никому не хуже, кому-то лучше) полезна как граница для технологических инициатив, то есть хорошая стратегия должна улучшать положение целевых групп и не создавать новых проблем для остальных (безопасность/эксплуатация/финансы/…).
Это очень полезные 16 страниц 🚀
Стратегический выбор стоит начинать не с выбора решений, а с тщательного исследования Problem Space – что именно является проблемой, для кого и почему это вообще проблема. В связи с этим – полезный материал по изучению проблемы и выбора типов решений (полагаю, Тарасенко для большинства подписчиков моего канала – вовсе не новая фамилия, а для кого новая – рекомендую его работы).
Отдельно добавлю про технологическую стратегию.
Для нее это означает, что «правильность» выбора направления развития нельзя обсуждать в вакууме. Необходимо явно перечислить стейкхолдеров, их интересы и критерии (качество, риски, скорость, стоимость, комплаенс, …), потому что именно в Problem Space формируются ограничения и критерии будущих решений. Сама идея «улучшающего вмешательства» (никому не хуже, кому-то лучше) полезна как граница для технологических инициатив, то есть хорошая стратегия должна улучшать положение целевых групп и не создавать новых проблем для остальных (безопасность/эксплуатация/финансы/…).
Это очень полезные 16 страниц 🚀
stakeholders.pdf
169.9 KB
О полноте стейкхолдеров
При принятии решения, особенно при выработке «улучшающего вмешательства» критически важно учесть интересы стейкхолдеров. И не важно – это стратегическое решение или небольшое решение в рамках продукта. Любое решение на кого-то влияет (иначе зачем вы вообще его принимаете?).
В этой части книги информация о том, как выявить максимально полное множество стейкхолдеров.
От себя добавлю. Это «упражнение» тем проще, чем чаще его проводить. Чем уже скоуп, тем более стабильной будет структура стейкхолдеров. Для конкретного продукта она может меняться буквально на несколько стейкхолдеров от задачи к задаче, для ИТ-стратегии, за счет широты влияния, может меняться значительно сильнее, но и периодичность принятия решений отличается, что дает временнОе пространство для маневра.
При принятии решения, особенно при выработке «улучшающего вмешательства» критически важно учесть интересы стейкхолдеров. И не важно – это стратегическое решение или небольшое решение в рамках продукта. Любое решение на кого-то влияет (иначе зачем вы вообще его принимаете?).
В этой части книги информация о том, как выявить максимально полное множество стейкхолдеров.
От себя добавлю. Это «упражнение» тем проще, чем чаще его проводить. Чем уже скоуп, тем более стабильной будет структура стейкхолдеров. Для конкретного продукта она может меняться буквально на несколько стейкхолдеров от задачи к задаче, для ИТ-стратегии, за счет широты влияния, может меняться значительно сильнее, но и периодичность принятия решений отличается, что дает временнОе пространство для маневра.
👍5❤1
Разомнемся на выходных? :)
Ситуация с которой вы столкнетесь не раз и не два.
Итак, представьте. Вы проводите Event Storming в службе поддержки клиентов.
Служба поддержки использует 7 каналов взаимодействия с клиентами (телефон, чат, почта, …), клиенты бывают 3 разных типов (vip, обычный+, обычный), количество продуктов на поддержке - 50+.
Структуру можно организовать разными способами (слева направо, см пример на картирнке):
- Свимлейны с каналами, и для каждого канала свимлейны с продуктами
- Свимлейны с продуктами, и для каждого канала внутри свимлейны с каналами
- Глобальные свимлейны для типов клиентов, внутри свимлейны для продуктов, внутри продуктов - свимлейны для каналов
- …
- и еще 11 способов (в том числе с только одним или вообще без свимлейнов)
Отмечу, что все структуры будут корректными, они ведь все описывают одну и ту же предметную область, но форма будет отличаться и для конкретного этого примера есть одна наиболее подходящая форма представления.
Вопрос: как бы вы визуализировали такую структуру и почему?
UPD_1: Денис задал хороший вопрос: «смотря для чего проводим». Это очень правильный вопрос, так как Event Storming – лишь инструмент. Проводим для того, чтобы исследовать предметную область и из текущей реализации вынести специфичную для продуктов логику, тем самым защитив реализацию платформы поддержки от попадания элементов предметной области конкретных продуктов. То есть, чтобы сопоставить модель предметной области и модель текущей реалзации и выявить расхождения.
Ситуация с которой вы столкнетесь не раз и не два.
Итак, представьте. Вы проводите Event Storming в службе поддержки клиентов.
Служба поддержки использует 7 каналов взаимодействия с клиентами (телефон, чат, почта, …), клиенты бывают 3 разных типов (vip, обычный+, обычный), количество продуктов на поддержке - 50+.
Структуру можно организовать разными способами (слева направо, см пример на картирнке):
- Свимлейны с каналами, и для каждого канала свимлейны с продуктами
- Свимлейны с продуктами, и для каждого канала внутри свимлейны с каналами
- Глобальные свимлейны для типов клиентов, внутри свимлейны для продуктов, внутри продуктов - свимлейны для каналов
- …
- и еще 11 способов (в том числе с только одним или вообще без свимлейнов)
Отмечу, что все структуры будут корректными, они ведь все описывают одну и ту же предметную область, но форма будет отличаться и для конкретного этого примера есть одна наиболее подходящая форма представления.
Вопрос: как бы вы визуализировали такую структуру и почему?
UPD_1: Денис задал хороший вопрос: «смотря для чего проводим». Это очень правильный вопрос, так как Event Storming – лишь инструмент. Проводим для того, чтобы исследовать предметную область и из текущей реализации вынести специфичную для продуктов логику, тем самым защитив реализацию платформы поддержки от попадания элементов предметной области конкретных продуктов. То есть, чтобы сопоставить модель предметной области и модель текущей реалзации и выявить расхождения.
Event Storming
Разомнемся на выходных? :) Ситуация с которой вы столкнетесь не раз и не два. Итак, представьте. Вы проводите Event Storming в службе поддержки клиентов. Служба поддержки использует 7 каналов взаимодействия с клиентами (телефон, чат, почта, …), клиенты…
Ответ к заданию
1. Не нужно выбирать единый свимлейн на всю модель
2. Вход в модель по каналам (свои события входа, своя модель подтверждения личности, свой UX)
3. После того, как определено намерение клиента (это может быть проблема, информация) - канал перестает иметь значение.
4. После того, как определено, что нужно сделать, в игру вступают продукты – они обозначаются как системы, так как по отношению к предметной области поддержки клиентов они и являются внешними системами.
Почему нет свимлейнов по типам клиентов (vip, …)?
Тип клиента - это атрибут, а не процесс. Если выделить в отдельный свимлейн, то 90% событий будут дублироваться. Здесь как раз нужны политики (Policy) маршрутизации по типу клиента.
Почему нет свимлейнов по продукту?
Клиент живет в проблеме, а не продукте, а продукты – вообще внешние по отношению к рассматриваемой предметной области. Проблема «не прошла оплата» может относиться к множеству продуктов.
1. Не нужно выбирать единый свимлейн на всю модель
2. Вход в модель по каналам (свои события входа, своя модель подтверждения личности, свой UX)
3. После того, как определено намерение клиента (это может быть проблема, информация) - канал перестает иметь значение.
4. После того, как определено, что нужно сделать, в игру вступают продукты – они обозначаются как системы, так как по отношению к предметной области поддержки клиентов они и являются внешними системами.
Почему нет свимлейнов по типам клиентов (vip, …)?
Тип клиента - это атрибут, а не процесс. Если выделить в отдельный свимлейн, то 90% событий будут дублироваться. Здесь как раз нужны политики (Policy) маршрутизации по типу клиента.
Почему нет свимлейнов по продукту?
Клиент живет в проблеме, а не продукте, а продукты – вообще внешние по отношению к рассматриваемой предметной области. Проблема «не прошла оплата» может относиться к множеству продуктов.
👍3❤2🔥1
Формирование рабочей группы по разработке методологии «Стратегического Event Storming»
На выходных меня не отпускала мысль, что что-то есть в предложении Юрия Куприянова интегрировать форсайт и Event Storming. Ведь фактически форсайт – это и есть варианты продолжения цепочек событий, но в будущее, а стратегическая сессия – это ограниченитель, фильтр для отбора вариантов.
Когда кроссфункциональная команда создает событийную модель, на которой размещаются не только внутренние бизнес-события, но и внешние факторы – изменения в законодательстве, технологические сдвиги, действия конкурентов, макроэкономические тренды, – проявляются паттерны зависимостей между событиями разного масштаба и природы.
Визуализация на единой временной шкале событий от глобального до корпоративного уровня создает естественную основу для интеграции с форсайтом – продления событийной модели в будущее, построения альтернативных сценариев и формирования адаптивных стратегий.
Интересно, что подобного использования Event Storming практически нет в публичных материалах в международной практике – метод остается преимущественно в пространстве технического проектирования.
Мы можем стать первыми, кто систематизирует этот подход и сделает его воспроизводимым инструментом!
Что будем делать
- Систематизируем опыт
- Создадим методологическую базу
- Подготовим к публикации
- Протестируем
Временные затраты
5-15 часов в неделю в течение 3 месяцев (февраль - апрель)
Что получите
- Соавторство
- Опыт создания воспроизводимого метода с нуля
- Новые связи среди единомышленников
- Возможность применять результаты в своей практике
- Что-то свое :)
Сам я это воспринимаю как создание чего-то значимого, что будет использоваться другими в том или ином виде. Если вы готовы к серьезной работе с амбициозной целью – буду рад видеть вас в команде.
📝 Ссылка на анкету для подачи заявки на участие (будет отбор):
https://forms.gle/WFSX6akDVA6NLqgY7
Дедлайн подачи заявок: 16 января 2026
Отбор и формирование рабочей группы: 16 января - 23 января
Kick-off встреча: на неделе с 26 по 30 января
PS: если знаете кого-то, кому может быть интересно, перешлите это сообщение :)
На выходных меня не отпускала мысль, что что-то есть в предложении Юрия Куприянова интегрировать форсайт и Event Storming. Ведь фактически форсайт – это и есть варианты продолжения цепочек событий, но в будущее, а стратегическая сессия – это ограниченитель, фильтр для отбора вариантов.
Когда кроссфункциональная команда создает событийную модель, на которой размещаются не только внутренние бизнес-события, но и внешние факторы – изменения в законодательстве, технологические сдвиги, действия конкурентов, макроэкономические тренды, – проявляются паттерны зависимостей между событиями разного масштаба и природы.
Визуализация на единой временной шкале событий от глобального до корпоративного уровня создает естественную основу для интеграции с форсайтом – продления событийной модели в будущее, построения альтернативных сценариев и формирования адаптивных стратегий.
Интересно, что подобного использования Event Storming практически нет в публичных материалах в международной практике – метод остается преимущественно в пространстве технического проектирования.
Мы можем стать первыми, кто систематизирует этот подход и сделает его воспроизводимым инструментом!
Что будем делать
- Систематизируем опыт
- Создадим методологическую базу
- Подготовим к публикации
- Протестируем
Временные затраты
5-15 часов в неделю в течение 3 месяцев (февраль - апрель)
Что получите
- Соавторство
- Опыт создания воспроизводимого метода с нуля
- Новые связи среди единомышленников
- Возможность применять результаты в своей практике
- Что-то свое :)
Сам я это воспринимаю как создание чего-то значимого, что будет использоваться другими в том или ином виде. Если вы готовы к серьезной работе с амбициозной целью – буду рад видеть вас в команде.
📝 Ссылка на анкету для подачи заявки на участие (будет отбор):
https://forms.gle/WFSX6akDVA6NLqgY7
Дедлайн подачи заявок: 16 января 2026
Отбор и формирование рабочей группы: 16 января - 23 января
Kick-off встреча: на неделе с 26 по 30 января
PS: если знаете кого-то, кому может быть интересно, перешлите это сообщение :)
🔥9❤1