Решил попробовать формат серий постов, чтобы тематики были не такими разрозненными, привнести больше целенаправленности.
Первая серия, которую хочу сделать – «Темные стороны Event Storming»
Дело в том, что иногда складывается ощущение, что про event storming уже все написано и все ошибки давно разобраны, на самом же деле настоящая практика всегда чуть сложнее и чуть глубже, чем кажется из описаний сессий. Я немного порефлексировал и собрал самые сложные и неочевидные истории, встречающиеся регулярно. Некоторым из участников этого канала я их уже рассказывал лично, а кто-то, может быть, узнает свою сессию.
Расскажу и про тишину экспертов и про иллюзию консенсуса и про колоритные примеры, которые уводят обсуждения в сторону. Пока набралось семь тем, а там посмотрим. Цель простая – дать честный срез как бывает, зачем это видеть и что с этим делать. Смысл в том, что ошибки, которые повторяет каждая группа, очень похожи, а опыт приходится нарабатывать каждый раз свой.
Как этим пользоваться – выбор каждого, кто-то прокачает свой скилл, кто-то обратиться за проведением сессии, понимая, что может не потянуть, тут каждый решает сам, но уж совершенно точно наиболее рациональным будет поделиться, а не замыкать в себе.
Сегодня выйдет первый пост на тему «Ложное согласование понятий»
Первая серия, которую хочу сделать – «Темные стороны Event Storming»
Дело в том, что иногда складывается ощущение, что про event storming уже все написано и все ошибки давно разобраны, на самом же деле настоящая практика всегда чуть сложнее и чуть глубже, чем кажется из описаний сессий. Я немного порефлексировал и собрал самые сложные и неочевидные истории, встречающиеся регулярно. Некоторым из участников этого канала я их уже рассказывал лично, а кто-то, может быть, узнает свою сессию.
Расскажу и про тишину экспертов и про иллюзию консенсуса и про колоритные примеры, которые уводят обсуждения в сторону. Пока набралось семь тем, а там посмотрим. Цель простая – дать честный срез как бывает, зачем это видеть и что с этим делать. Смысл в том, что ошибки, которые повторяет каждая группа, очень похожи, а опыт приходится нарабатывать каждый раз свой.
Как этим пользоваться – выбор каждого, кто-то прокачает свой скилл, кто-то обратиться за проведением сессии, понимая, что может не потянуть, тут каждый решает сам, но уж совершенно точно наиболее рациональным будет поделиться, а не замыкать в себе.
Сегодня выйдет первый пост на тему «Ложное согласование понятий»
👍15🔥6❤1😱1
Ложное согласование понятий
Ложное согласование понятий — это эффект, когда всем кажется, что разговор идет об одном и том же, но на деле за привычными словами у каждого прячется свой смысл. Одна из целей ES как раз в том, чтобы такие понятия прояснить. На практике это выглядит так: кто-то говорит слово/термин и уверен, что все понимают его точно так же, ведь «тут же все очевидно». Для него, в его контексте 🙂 На деле же, у коллег в голове свои определения — иногда близкие, иногда противоположные. В результате появляется иллюзия единства, которая на поверку оказывается недопониманием: думаем, что договорились, а на самом деле каждый остался при своем.
▪️ Примеры:
– «Премиальный клиент» для одних — участник программ лояльности, для других — просто клиент с высоким депозитом, для третьих — статус по определённой подписке
– В сессии про складскую логистику параллельно используются названия FBO и FBS — для одних это тип склада, для других способ доставки, для третьих вообще внутренний отчетный признак
– «Оплата» – одни считают оплатой момент выставления счета, другие — факт поступления денег, а третьи — завершенную банковскую транзакцию
Так же стоит обратить внимание на технические термины (коих в целом быть не должно).
▪️Обобщив, можно выделить такие паттерны:
– Технические акронимы (всякие API, CRM, MVP, …), особенно перегруженные определениями. «Где-то слышал, значит понимаю». Предполагает общее понимание, но чаще каждый вкладывает свой смысл
– Пограничные термины (CAPEX/OPEX, FBO/FBS) - трактуются по-разному в смежных областях
– Неявные классификации (премиум) – для таких терминов нужны не только определения, но и критерии принадлежности
– ВременнЫе характеристики – все эти SLA и прочие, для них должны быть определены конкретные границы
– Самое частое – универсальные термины (клиент, платеж), у которых могут быть сотни определенний даже в рамках одной компании
▪️Почему сессия проведена, а о терминах не договорились?
Тут тоже несколько причин:
– Разные подразделения используют собственную терминологию для одних и тех же концепций и у них не возникает даже мысли, что кто-то может использовать другое определение
– Опытные участники предполагают, что их глубокое понимание разделяют все остальные
– Участники избегают показаться некомпетентными, соглашаясь с неясными терминами
– Участники экстраполируют понимание, основываясь на узком круге коллег
▪️Как выявить проблему во время сессии?
Есть ряд маркеров для наблюдения:
– Использование слов «это», «то», «та штука» без конкретизации
– Фразы типа «ну, вы знаете, о чем я»
– Переключение на жаргон середины предложения
– Затянувшиеся паузы после вопросов о терминах
– Рисование схем вместо словесных объяснений
– Быстрое согласие без дополнительных вопросов
– Переход к следующей теме при появлении неясности
– Избегание детализации «очевидных» понятий
– Молчание при просьбе привести примеры
▪️В рамках сессии, чтобы максимально снизить проявление этой проблемы можно использовать несколько фасилитационных механик:
– Самая рабочая, но за которую участники могут вначале невзлюбить фасилитатора – глупые/наивные вопрос: «Что такое платеж в вашем контексте?» даже если термин кажется очевидным.
– При появлении любого термина просить письменное определение на стикере на видном месте
– Для каждого понятия просить конкретные примеры из практики
– Техника альтернатив – может ли этот термин означать что-то еще в нашей компании?
– Связывание абстрактных терминов с конкретными процессами
– Каждый термин поочередно объясняют разные участники, сравнивают свои версии, вырабатывают единое определение и фиксируют согласованную трактовку
Ложное согласование понятий — это эффект, когда всем кажется, что разговор идет об одном и том же, но на деле за привычными словами у каждого прячется свой смысл. Одна из целей ES как раз в том, чтобы такие понятия прояснить. На практике это выглядит так: кто-то говорит слово/термин и уверен, что все понимают его точно так же, ведь «тут же все очевидно». Для него, в его контексте 🙂 На деле же, у коллег в голове свои определения — иногда близкие, иногда противоположные. В результате появляется иллюзия единства, которая на поверку оказывается недопониманием: думаем, что договорились, а на самом деле каждый остался при своем.
▪️ Примеры:
– «Премиальный клиент» для одних — участник программ лояльности, для других — просто клиент с высоким депозитом, для третьих — статус по определённой подписке
– В сессии про складскую логистику параллельно используются названия FBO и FBS — для одних это тип склада, для других способ доставки, для третьих вообще внутренний отчетный признак
– «Оплата» – одни считают оплатой момент выставления счета, другие — факт поступления денег, а третьи — завершенную банковскую транзакцию
Так же стоит обратить внимание на технические термины (коих в целом быть не должно).
▪️Обобщив, можно выделить такие паттерны:
– Технические акронимы (всякие API, CRM, MVP, …), особенно перегруженные определениями. «Где-то слышал, значит понимаю». Предполагает общее понимание, но чаще каждый вкладывает свой смысл
– Пограничные термины (CAPEX/OPEX, FBO/FBS) - трактуются по-разному в смежных областях
– Неявные классификации (премиум) – для таких терминов нужны не только определения, но и критерии принадлежности
– ВременнЫе характеристики – все эти SLA и прочие, для них должны быть определены конкретные границы
– Самое частое – универсальные термины (клиент, платеж), у которых могут быть сотни определенний даже в рамках одной компании
▪️Почему сессия проведена, а о терминах не договорились?
Тут тоже несколько причин:
– Разные подразделения используют собственную терминологию для одних и тех же концепций и у них не возникает даже мысли, что кто-то может использовать другое определение
– Опытные участники предполагают, что их глубокое понимание разделяют все остальные
– Участники избегают показаться некомпетентными, соглашаясь с неясными терминами
– Участники экстраполируют понимание, основываясь на узком круге коллег
▪️Как выявить проблему во время сессии?
Есть ряд маркеров для наблюдения:
– Использование слов «это», «то», «та штука» без конкретизации
– Фразы типа «ну, вы знаете, о чем я»
– Переключение на жаргон середины предложения
– Затянувшиеся паузы после вопросов о терминах
– Рисование схем вместо словесных объяснений
– Быстрое согласие без дополнительных вопросов
– Переход к следующей теме при появлении неясности
– Избегание детализации «очевидных» понятий
– Молчание при просьбе привести примеры
▪️В рамках сессии, чтобы максимально снизить проявление этой проблемы можно использовать несколько фасилитационных механик:
– Самая рабочая, но за которую участники могут вначале невзлюбить фасилитатора – глупые/наивные вопрос: «Что такое платеж в вашем контексте?» даже если термин кажется очевидным.
– При появлении любого термина просить письменное определение на стикере на видном месте
– Для каждого понятия просить конкретные примеры из практики
– Техника альтернатив – может ли этот термин означать что-то еще в нашей компании?
– Связывание абстрактных терминов с конкретными процессами
– Каждый термин поочередно объясняют разные участники, сравнивают свои версии, вырабатывают единое определение и фиксируют согласованную трактовку
👍11🔥9❤2
▪️Можно заложить ряд правил и провести ряд действий еще до сессии:
– Собрать терминологию от каждой команды и составить список спорных заранее (редко удается)
– Добавить junior’ов, которые будут задавать очевидные вопросы 🙂
– Ввести правило «нет глупых вопросов» (кто был у меня на любых курсах, помнит это правило 🙂 )
– Объявить обязательность определений для всех терминов
– Установить временные слоты для разбора терминологии
– Правило «если термин непонятный - красный стикер» и запрет на продолжение сессии до согласования определений
Надеюсь, что этот материал будет вам полезен и наведет на мысли как улучшить ваши сессии event storming 🙂 Если есть еще мысли/идеи, можете добавить в комментарии, я добавлю в этот материал.
– Собрать терминологию от каждой команды и составить список спорных заранее (редко удается)
– Добавить junior’ов, которые будут задавать очевидные вопросы 🙂
– Ввести правило «нет глупых вопросов» (кто был у меня на любых курсах, помнит это правило 🙂 )
– Объявить обязательность определений для всех терминов
– Установить временные слоты для разбора терминологии
– Правило «если термин непонятный - красный стикер» и запрет на продолжение сессии до согласования определений
Надеюсь, что этот материал будет вам полезен и наведет на мысли как улучшить ваши сессии event storming 🙂 Если есть еще мысли/идеи, можете добавить в комментарии, я добавлю в этот материал.
👍11🔥8
Молчащие эксперты и «невидимые блокеры»
Молчащие эксперты — это эффект, когда внешне сессия кажется продуктивной, но критически важные детали и проблемы остаются невыявленными, потому что именно знающие люди предпочли ничего не озвучить. Именно молчащие, не молчаливые. Потому что молчаливые по природе отличается от молчащих по иным причиным.
▪️Примеры:
– При обсуждении бизнес-процессов важные вопросы остаются отмеченными «?» на доске, но никто из экспертов их не комментирует
– Один человек упоминается множество раз подряд в различных процессах. Это может свидетельствовать о том, что остальные участники предпочли молчать, позволив одному эксперту доминировать в обсуждении
– Один-два специалиста ведут разговор, остальные ограничиваются молчаливым согласием — решения принимаются с опорой на ограниченный опыт
– Детали («как именно это работает?») намеренно или неосознанно обходятся стороной: «Тут все ясно, идём дальше»
– На критически важных блоках появляется множество стикеров с вопросами, но ни один не разбирается детально
▪️Обобщая, можно выделить такие паттерны:
– Накопление на доске вопросов без последующей детализации
– Быстрое закрытие тем при появлении сложных вопросов
– Молчание после постановки неудобного/неочевидного вопроса
– Визуальное доминирование одного эксперта: в модели встречается только одна фамилия в ряде карточек
– Использование расплывчатых формулировок («обычно делаем так», «интуитивно понятно»)
– Преобладание стандартных сценариев без ветвлений и альтернатив
▪️Почему знающие люди молчат?
– Страх показаться некомпетентным или не своим, своего рода синдром самозванца (если замечаете за собой, почитайте как справится с этим синдромом, это будет полезно в целом)
– Молчание, чтобы не идти против «лидера»
– Усталость и формальное участие («скорее бы закончить»)
– Ощущение, что тема нерелевантна лично эксперту (но при этом она критична для других)
– Культура избегания обсуждения сложных или конфликтных вопросов, – «кто-то другой разберется». Эдакая культура перекладывания ответственности.
– Групповое мышление и подсознательный эффект наблюдателя: если никто не спрашивает — значит все ясно
▪️Как проявляется во время сессии?
– Длинные паузы после важных/неприятных вопросов
– На доске появляются скопления неотвеченных вопросов
– Один человек постоянно на виду, остальные малоактивны
– Группа быстро соглашается на поверхностные объяснения, без обсуждения альтернатив
– Часто встречаются фразы «давайте пойдём дальше», «вернёмся потом», «и так понятно же»
▪️Что делать?
Когда начал составлять перечень антидотов, заметил, что часть из них - те же, что и озвученные ранее, видимо и дальше они будут повторяться.
– Ввести правило «нет глупых вопросов» и подкреплять действиями, – поощрять уточнения («Отличный вопрос, спасибо»)
– Использовать анонимный сбор вопросов
– Просить записывать вопросы сразу и выделять время для их совместного разбора
– Специально обращаться к менее активным участникам
– Разделять участников по малым группам для обсуждения, после чего выводить результаты в общее пространство
– Ввести роль «адвоката дьявола», который провоцирует команду на неудобные размышления; обычно это заказчик сессии и я его параллельо в чате могу попросить что-нибудь спросить
– По окончании давать обратную связь, запрашивать анонимные дополнения, документировать неразрешенные вопросы и договариваться о последующей проработке
– В некоторых статьях рекомендуется провести вначале калибровку ожиданий/страхов (что мешает говорить здесь откровенно?) - в моем случае ни разу не помогло, потому что если во время сессии проявляется все описанное здесь, то оно проявится и во время такой калибровки, просто потраченное время
Молчащие эксперты — это эффект, когда внешне сессия кажется продуктивной, но критически важные детали и проблемы остаются невыявленными, потому что именно знающие люди предпочли ничего не озвучить. Именно молчащие, не молчаливые. Потому что молчаливые по природе отличается от молчащих по иным причиным.
▪️Примеры:
– При обсуждении бизнес-процессов важные вопросы остаются отмеченными «?» на доске, но никто из экспертов их не комментирует
– Один человек упоминается множество раз подряд в различных процессах. Это может свидетельствовать о том, что остальные участники предпочли молчать, позволив одному эксперту доминировать в обсуждении
– Один-два специалиста ведут разговор, остальные ограничиваются молчаливым согласием — решения принимаются с опорой на ограниченный опыт
– Детали («как именно это работает?») намеренно или неосознанно обходятся стороной: «Тут все ясно, идём дальше»
– На критически важных блоках появляется множество стикеров с вопросами, но ни один не разбирается детально
▪️Обобщая, можно выделить такие паттерны:
– Накопление на доске вопросов без последующей детализации
– Быстрое закрытие тем при появлении сложных вопросов
– Молчание после постановки неудобного/неочевидного вопроса
– Визуальное доминирование одного эксперта: в модели встречается только одна фамилия в ряде карточек
– Использование расплывчатых формулировок («обычно делаем так», «интуитивно понятно»)
– Преобладание стандартных сценариев без ветвлений и альтернатив
▪️Почему знающие люди молчат?
– Страх показаться некомпетентным или не своим, своего рода синдром самозванца (если замечаете за собой, почитайте как справится с этим синдромом, это будет полезно в целом)
– Молчание, чтобы не идти против «лидера»
– Усталость и формальное участие («скорее бы закончить»)
– Ощущение, что тема нерелевантна лично эксперту (но при этом она критична для других)
– Культура избегания обсуждения сложных или конфликтных вопросов, – «кто-то другой разберется». Эдакая культура перекладывания ответственности.
– Групповое мышление и подсознательный эффект наблюдателя: если никто не спрашивает — значит все ясно
▪️Как проявляется во время сессии?
– Длинные паузы после важных/неприятных вопросов
– На доске появляются скопления неотвеченных вопросов
– Один человек постоянно на виду, остальные малоактивны
– Группа быстро соглашается на поверхностные объяснения, без обсуждения альтернатив
– Часто встречаются фразы «давайте пойдём дальше», «вернёмся потом», «и так понятно же»
▪️Что делать?
Когда начал составлять перечень антидотов, заметил, что часть из них - те же, что и озвученные ранее, видимо и дальше они будут повторяться.
– Ввести правило «нет глупых вопросов» и подкреплять действиями, – поощрять уточнения («Отличный вопрос, спасибо»)
– Использовать анонимный сбор вопросов
– Просить записывать вопросы сразу и выделять время для их совместного разбора
– Специально обращаться к менее активным участникам
– Разделять участников по малым группам для обсуждения, после чего выводить результаты в общее пространство
– Ввести роль «адвоката дьявола», который провоцирует команду на неудобные размышления; обычно это заказчик сессии и я его параллельо в чате могу попросить что-нибудь спросить
– По окончании давать обратную связь, запрашивать анонимные дополнения, документировать неразрешенные вопросы и договариваться о последующей проработке
– В некоторых статьях рекомендуется провести вначале калибровку ожиданий/страхов (что мешает говорить здесь откровенно?) - в моем случае ни разу не помогло, потому что если во время сессии проявляется все описанное здесь, то оно проявится и во время такой калибровки, просто потраченное время
🔥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 – лишь инструмент. Проводим для того, чтобы исследовать предметную область и из текущей реализации вынести специфичную для продуктов логику, тем самым защитив реализацию платформы поддержки от попадания элементов предметной области конкретных продуктов. То есть, чтобы сопоставить модель предметной области и модель текущей реалзации и выявить расхождения.