Scrum Mastery Club

💡 Мероприятие запланировано. Сайт готов. Программа опубликована. Реклама запущена. А почему участник должен прийти именно к вам?

Продолжаем готовить «Литейный интенсив 2027» через Карту гипотез. И хочу рассказать, почему мы выбрали такой подход.

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

Но даже подробный план не отвечает на главный вопрос: за счет чего именно наша конференция станет ценной для тех, кого мы хотим привлечь?

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

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

И уже на этой основе строим гипотезы.

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

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

то он решит участвовать в конференции и инициирует согласование поездки,

потому что увидит возможность получить применимое решение задачи, за которую отвечает,

тогда это повлияет на количество проданных билетов.

Это пока предположение. Нам еще предстоит проверить, действительно ли задача важна, достаточно ли такого предложения и что мешает человеку принять решение.

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

❗️У каждой задачи появляется основание: какую гипотезу она проверяет или реализует, чье поведение должна изменить и на какую метрику повлиять.

То же самое с рекламой. «Запустить рекламу во VK» - действие. Чтобы оно имело смысл, нужно понять, к кому мы обращаемся, что для этого человека важно и почему наше предложение побудит его сделать следующий шаг.

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

Поэтому мы двигаемся от смысла к действиям: цель и метрики → субъекты и их мотивация → гипотезы → задачи. А затем проверяем результат и пересматриваем свои предположения.

На следующей неделе будем разбирать саму технологию на курсе «Карта гипотез. Практик 1».

🗓 Старт - 12 октября, онлайн. Практическая работа — в Sociotech: будем учиться строить такие связи на своих проектах.

Программа и регистрация

🗺 Через неделю начинаем новый поток по Карте гипотез. И немного меняем само обучение

12 октября стартует «Карта гипотез. Практик 1».

Сейчас готовим новый поток. И одно из важных изменений - вся практическая работа теперь проходит непосредственно в Sociotech.

Почему для нас это важно?

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

Нужно научиться думать через карту.

Формулировать. Связывать. Проверять логику. Возвращаться назад. Перестраивать. Видеть, где карта не складывается и почему.

Поэтому мне хочется, чтобы на тренинге участники работали не с учебной картинкой, а сразу с полноценным инструментом.

И здесь нам очень помогает
Sociotech.

В платформе можно собирать Карту гипотез, последовательно работать с ее элементами, возвращаться к формулировкам, перестраивать связи и постепенно доводить карту до рабочего состояния.
И это уже гораздо ближе к тому, как Карта гипотез используется в реальной работе.

📅 Практик 1 стартует 12 октября.

Три онлайн-занятия: понедельник / среда / пятница.

Программа и регистрация

ИИ построил нам стратегию трансформации. Красивую. Логичную. И неправильную.

На прошлой встрече клуба Scrum-Mastery мы решили провести довольно интересный эксперимент.

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

Материала накопилось много.

- Конфликт между бизнесом и ИТ.
- Двоевластие Product Owner и технического лидера.
- Проектное управление, конкурирующее с продуктовым.
- Низкая автономность команд.
- Разные KPI бизнеса и ИТ.
- Огромное количество зависимостей.
- Проблемы со сквозным Time-to-Market.

И мы решили сделать то, что сейчас очень хочется сделать практически каждому консультанту: а что, если все это просто отдать искусственному интеллекту и попросить его построить стратегию трансформации?

Загрузили результаты аудита в Sociotech. ИИ разобрал материалы, выделил факты, обработал SWOT и построил Карту гипотез.
На первый взгляд - отлично: есть цель, есть метрики, есть гипотезы, есть конкретные задачи. Можно брать и начинать трансформацию.

А потом мы стали разбирать карту руками. И обнаружили довольно серьезную проблему.

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

Самое интересное - ИИ про них знал. В загруженных материалах были руководители, команды, PO, технические лидеры, Scrum Masters, PMO. Были описаны конфликты полномочий, проблемы автономности, разные KPI и даже конкретные управленческие противоречия.
То есть проблема оказалась не в недостатке данных.

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

Если мы говорим о стратегии через Карту гипотез, недостаточно написать: «Хотим сократить Time-to-Market». Нужно задать следующий вопрос: чье поведение должно измениться, чтобы эта метрика изменилась?

Руководитель должен начать принимать решения иначе. Product Owner - получить другие полномочия. Команда - иначе работать с приоритетами и зависимостями.

И только потом появляются гипотезы: Если мы изменим X, субъект Y начнет вести себя Z, потому что…, и это должно повлиять на конкретную метрику.

И, пожалуй, это один из самых полезных выводов нашего эксперимента:
AI не отменяет необходимость понимать инструмент, которым вы пользуетесь. Скорее наоборот. Чем лучше становится AI и чем убедительнее выглядят его ответы, тем важнее человеку понимать технологию достаточно хорошо, чтобы заметить ошибку.

Потому что плохой ответ ИИ заметить легко. Гораздо опаснее хорошо оформленный, логично звучащий и профессионально выглядящий ответ, в котором пропущена одна принципиальная часть системы.

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

И как раз в октябре стартует новый поток обучения «Карта гипотез. Практик — Ступень 1».
Там мы учимся не просто рисовать карту, а строить эту причинную логику: цель → метрики → субъекты → их боли и потребности → изменение поведения → гипотезы → действия.

И, конечно, будем учиться использовать AI как помощника — но не отдавать ему стратегическое мышление целиком.

👉 https://scrum-mastery.ru/hypothesis_mapping

🚀 От аудита к стратегии изменений: соберём план трансформации с помощью ИИ

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

Но что делать дальше?

Как превратить десятки наблюдений и рекомендаций в понятную стратегию трансформации? Завтра будем делать это вживую на очередной встрече ннашего клуба. Мы соединим сразу
несколько инструментов:

🔹 Проектирование To-Be - как из текущего хаоса собрать образ целевой организационной системы.

🔹 Карта Гипотез трансформации - как определить, что именно менять, какие гипотезы проверять и в какой последовательности действовать.

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

И самое интересное - не будем работать на абстрактном примере, а возьмём результаты реального аудита и прямо на встрече пройдем путь:

Аудит → системные проблемы → To-Be → гипотезы → приоритеты → план изменений.

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

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

А теперь к этому добавляется еще один инструмент - ИИ как партнер в работе над стратегией.

Завтра будем пробовать это руками. Мастер-класс для тех, кто занимается организационными изменениями, трансформациями, Agile и развитием бизнеса.

После встречи начнем собирать программу второго осеннего потока Scrum-Mastery на октябрь.

🌐 Scrum-Mastery

Учителя бывают разные

Есть те, кто хорошо знает методологию и умеет о ней рассказывать.

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

Мне кажется, для прикладного обучения это принципиальная разница.

Неделю назад начала работу группа, которая готовит конференцию «Литейный интенсив». И мы сразу пошли не в презентации, не в список мероприятий и не в распределение задач.

Мы начали строить стратегию конференции с помощью Карты гипотез.

Причем в этот раз в работу вовлечен весь программный комитет - все организаторы.

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

И для меня это, пожалуй, один из лучших способов проверить любой инструмент: работает ли он там, где нет учебного примера и заранее известного правильного ответа?

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

Мы показываем, как с ней работать.

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

Ближайшие тренинги в октябре

✔️Карта гипотез — Уровень Практик, Ступень 1
12 октября · онлайн
➡️https://scrum-mastery.ru/hypothesis_mapping

✔️Карта гипотез — Уровень Практик, Ступень 2
19 октября · онлайн
➡️ https://scrum-mastery.ru/hypothesis_mapping_2

Все тренинги проходят на платформе Sociotech.

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

🎲 23 сентября - «Диагностика доверия в команде»

Можно ли диагностировать доверие в команде не с помощью длинной анкеты, а прямо в процессе взаимодействия?

23 сентября проведём специальную игру «Мастер Доверия» - «Диагностика доверия в команде».

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

Что будет на встрече:

🧩 Погружаемся в методологию Разберем, как устроена диагностика доверия через игру: что именно мы наблюдаем и как работают игровые механики.

🎲 Играем в онлайн-версию «Мастера Доверия» Пройдем игровой сценарий, в котором участники сталкиваются с командными ситуациями, принимают решения, дают друг другу обратную связь и наблюдают, как меняется уровень доверия.

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

💡 Смотрим примеры использования
Обсудим, где такой формат можно применять в работе: командная диагностика, ретроспективы, фасилитационные сессии, развитие команд и работа со сложными ситуациями.

Особенно приглашаю фасилитаторов, Agile Coach, Scrum Master, бизнес-тренеров, HR и всех, кто работает с командами.

Можно прийти просто как участник. А можно посмотреть на игру ещё и глазами фасилитатора - как устроен сценарий и что из него
можно забрать в собственную практику.

📅 23 сентября, 19:00 МСК 💻 Онлайн

👉 Подробности и регистрация: trustmastergame.ru/events

🔎 Продолжаем исследовать организацию

Сегодня на встрече закрытого клуба Scrum-Mastery продолжаем разбираться с тем, как диагностировать и проектировать организацию как систему.

Будем говорить про аксиоматическое проектирование и разберем его на реальном кейсе.

Не просто посмотрим на готовый анализ, а вместе:
- определим функциональные требования; - разложим элементы организационной конструкции; - построим матрицу функциональной связанности; - попробуем найти в ней системные проблемы; - и посмотрим, какие изменения можно спроектировать для будущего состояния.

То есть пройдем весь путь: собрать → проанализировать → спроектировать.

Если хотите присоединиться — напишите мне в личку, еще есть возможность попасть на сегодняшнюю встречу в 19:00.

Даже если давно собирались прийти — сегодня как раз хороший повод 🙂

Ну или записывайтесь в наш клуб: https://scrum-mastery.ru/

Организационный дизайн - это не оргструктура

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

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

Главный переворот: не структура → роли → процессы, а функции → требования → конструкция системы.

👉 Читать статью: «Аксиоматическое проектирование: почему оргструктура — это не весь организационный дизайн»

🚀 Стартовал осенний сезон клуба: разбираем Модель Гелбрайта

Вчера мы провели первую встречу нового сезона «Архитекторы Потока». Без общих воды - сразу перешли к сути диагностики операционной модели на реальном кейсе.

Что обсудили на первой встрече:

1️⃣ Прошли по Модели Гелбрайта. Разобрали, как 5 элементов (Стратегия, Структура, Процессы, Награды, Люди) должны быть сбалансированы, и почему изменение одного без остальных неизбежно ведет систему в хаос.

2️⃣ Нашли главный системный разрыв. На примере кейса увидели, как бизнес мыслит категориями P&L, клиентов и скорости, а ИТ-блок — стабильностью, утилизацией ресурсов и проектными вехами. Это две разные вселенные, которые не стыкуются на уровне операционки.

3️⃣ Сменили фокус диагностики. Зафиксировали главное правило: мы ищем не «виноватых» или плохих людей, а ошибки в дизайне системы и паразитные связи между ролями.

Что было: попробовали сразу применили модель к реальным симптомам из аудита, чтобы самостоятельно найти корень проблемы в конкретном элементе модели.

Что дальше:
На следующей неделе (вторник, 8 сентября, 19:00 МСК) переходим ко второму модулю: Диагностика организационной связанности. Будем строить матрицу функциональной связанности и анализировать результы.

👇
Кто хочет присоединиться к следующему занятию - пишите в личные сообщения или приходите: https://scrum-mastery.ru

#ScrumMastery #АрхитекторыПотока #МодельГелбрайта #AgileДиагностика #OrganizationalDesign

🧩 Сбой в системе: почему ИТ-процессы воюют с бизнес-стратегией

Завтра - 1 сентября, и мы официально запускаем новый практический сезон в закрытом бизнес-клубе Scrum-Mastery. Давайте разберем один из главных ментальных инструментов, с которого мы начнем наш сентябрь.

Когда T2M ключевых продуктов банка или компании составляет месяцы, а планы спринтов регулярно рушатся, менеджмент обычно ищет виновных: «программисты медленные», «бизнес не умеет писать ТЗ», «Скрам-мастера плохо фасилитируют».

Но в 95% случаев люди вообще не при чем. Причина — в разрыве операционной модели. Чтобы доказать это Топ-менеджменту и СЕО на языке жестких системных аргументов, мы будем использовать фундаментальный инструмент организационного инжиниринга - Модель организационного соответствия Джея Гелбрайта (Звезда Гелбрайта).

В чем суть Звезды Гелбрайта?

Гелбрайт доказал: успешная компания - это сбалансированная пятиконечная звезда, где все лучи синхронизированы между собой:

- Стратегия (Strategy): куда мы идем и какое наше рыночное преимущество.
- Структура (Structure): как нарезаны команды.
- Процессы (Processes): как движется информация и ценность .
- Награды/Мотивация (Rewards): за что людям платят бонусы и KPI.
- Люди/Компетенции (People): какими способностями обладают сотрудники.

🔴 Классический клин операционной модели («Inside-Out»):

Посмотрите, в какой ловушке сейчас находится большинство компаний на рынке:

- Стратегия требует: рыночная скорость, T2M за 14 дней и маневренность.
- Но Структура заперта в жестких компонентных командах, где фичи 60% времени гниют в очередях.
- Награды (KPI) Тимлидов и Скрам-мастеров завязаны на локальную «скорость закрытия тикетов».

Итог: лучи операционной модели противоречат друг с другом.


⏳ Завтра — старт. Последний шанс войти в контур изменений

Именно с Аудита организационного соответствия по модели Гелбрайта мы начнем первый живой воркшоп клуба в сентябре. Мы не будем читать лекций. Мы возьмем реальный кейс и разберем, как по шагам сопоставить стратегию бизнеса с текущей структурой, чтобы C-Level директора сами увидели необходимость реформ.

👉 Оформить абонемент и войти в клуб Scrum-Mastery прямо сейчас: https://scrum-mastery.ru

#ScrumMastery #OrgDesign #SystemicThinking #FlowEfficiency #GalbraithStar #InsideOut #Management #AgileCoaching

💡 Эффект кобры в IT: как KPI на скорость заставляет Тимлидов и Скрам-мастеров вредить бизнесу

Британская история знает шедевральный пример управленческого абсурда. В колониальной Индии расплодилось слишком много ядовитых змей. Губернатор ввел денежную награду за каждую принесенную голову кобры, ожидая, что популяция сойдет на нет.
Что сделало население? Индийцы начали массово разводить кобр в домашних условиях, чтобы стабильно зарабатывать на сдаче голов. Когда премии отменили, фермеры просто выпустили ставших ненужными змей на волю. В итоге популяция кобр выросла в несколько раз.

Локальное денежное поощрение метрики полностью уничтожило глобальную цель.

🐍 Как «разводят кобр» в компании прямо сейчас

Каждый раз, когда ИТ-дирекция привязывает премии Тимлидов и Скрам-мастеров к локальному KPI «Сократить IT Lead Time на 15%», включается тот самый индийский сценарий. Люди перестают думать о продукте и начинают играть в систему ради защиты своего кармана:

1️⃣ Саботаж сложных задач: Зачем команде брать тяжелую, стратегическую фичу от Product Owner'а, которая «поплывет» по срокам и убьет средний Lead Time? Тимлиды под любым предлогом выталкивают сложные задачи из спринтов. Команда фокусируется на примитивном «мусоре» (покрасить кнопки, поменять тексты), который закрывается за час и гарантирует премию. Графики скорости летят вверх, но бизнес-результат равен нулю.

2️⃣ Скрытие багов: баг в спринте - это остановка удар по KPI. Ошибки начинают замазываться быстрыми «костылями» прямо на продакшне в обход трекеров, чтобы не портить статистику. Качество кодовой базы деградирует мгновенно.

3️⃣ Ликвидация прозрачности: Скрам-мастер из независимого аудитора превращается в соучастника. Чтобы дашборд выдал руководству красивую цифру, СМ начинает вручную чистить тикеты, дробить задачи и перекрашивать баги в «новые фичи». Прозрачность процессов умирает первой.

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

📅 Сентябрь в клубе Scrum-Mastery: перезапуск системы метрик

Весь сентябрь в нашем закрытом клубе мы посвятим суровому организационному инжинирингу. Хочется в том числе разобрать конкретные инженерные формулы: Flow Efficiency (эффективность потока) и Cost of Delay (стоимость задержки), которыми нужно заменить «скорость закрытия тикетов», чтобы вернуть командам продуктовый фокус.

Занимайте свое место в контуре изменений, пока открыто сентябрьское окно регистрации. Начинаем уже 1 сентября! Завтра опубликуем конечную программу встреч.

👉 Оформить абонемент и войти в клуб Scrum-Mastery: https://scrum-mastery.ru

#ScrumMastery #SystemicThinking #OrgDesign #FlowEfficiency #Management #AgileCoaching

💡 VSM «снаружи-внутрь»: как найти простои там, где Jira показывает 100% скорость?

Большинство ИТ-руководителей свято верят своим дашбордам в Jira. На графиках всё идеально: velocity растет, спринты закрываются вовремя, внутренняя скорость разработки (иногда вы найдете термин - IT Lead Time) стремительно падает. ИТ-блок уверен, что работает со стопроцентной эффективностью.

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

Почему возникает эта иллюзия? Потому что классические таск-трекеры измеряют процессы «изнутри наружу» (Inside-Out) - от статуса «В работе » до статуса «Готово» внутри производственного силоса. Система полностью слепа к тому, что происходит с задачей до и после написания кода.

Чтобы вскрыть этот обман и увидеть реальную картину, профессиональному агенту изменений нужен взгляд «снаружи внутрь» (Outside-In) и инструмент Value Stream Mapping (VSM) - картирование сквозного потока ценности глазами клиента. Картирование позволяет переключить фокус менеджмента с локальной оптимизации (заставить программистов быстрее нажимать на кнопки) на оптимизацию сквозного потока (убрать простои на стыках между отделами).

🤖 Кейс: Как ИИ-анализ взламывает слепые зоны процессов

В одном из последних проектов мы решили пойти дальше классического рисования стрелочек на флипчарте. Мы провели картирование не просто потока, а смоделировали сквозной путь ценности в Lucidchart и подключили встроенных ИИ-агентов для глубокого организационного анализа.

Вот какие жесткие цифры и аномалии вскрыл ИИ-анализ на карте потока:

- Парадокс Touch Time: чистая, полезная работа инженеров над кодом (Touch Time) занимает всего от 4 до 8 рабочих дней.

- Общий календарный срок (Lead Time) прохождения сквозного изменения составляет от 82 до 104 рабочих дней.

- Эффективности потока (Flow Efficiency): Эффективность конвейера составила всего 12–15%. Это значит, что более 85% времени задача просто «протухает» в очередях - в ожиданиях ответов от смежных колодцев и в циклах согласований.

Даже если разработчики ускорятся в два раза и начнут писать код за 2 дня вместо 4, сквозной Time-to-Market для клиента не изменится ни на час. Проблема лежит в ошибочном дизайне организационной связанности (Coupled Design).

🚀 Отработаем эту технологию на практике в клубе Scrum-Mastery

Теория без практики мертва. На ближайшем живом воркшопе нашего закрытого клуба мы разберем эту инженерную технологию до винтиков. Вы сможете прийти со своими кейсами и картами процессов.

Что мы сделаем вместе на занятии клуба:

1. Пошагово спроектируем сквозной VSM в Lucidchart

2. Разберем, как правильно настраивать промпты для ИИ-агентов

3. Упакуем результаты анализа в понятный b2b-язык для C-level

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

👇 Ссылка на оформление абонемента и вход в клуб Scrum-Mastery

👉 https://scrum-mastery.ru

#ScrumMastery #OrgDesign #ValueStreamMapping #FlowEfficiency #Lucidchart #AIinManagement #InsideOut #SystemicThinking #Management

📝 Анатомия очередей: как с помощью HeatMap бэклога доказать, что команды утилизируют сами себя

Знакомая картина? ИТ-директор на комитетах требует расширения штата, заявляя о 100% выгорании и перегрузке своих сотрудников. Разработчики действительно в мыле, Jira трещит от тысяч закрытых тикетов, аналитики пишут тонны ТЗ. Но нужные рынку фичи не выходят месяцами.

Чтобы вскрыть этот парадокс, профессиональному агенту изменений нужен жесткий инструмент - HeatMap (тепловая карта) бэклога.

Как устроена «фабрика» ложной занятости?

Когда организация нарезает ИТ-структуру «изнутри наружу», например, плодит десятки изолированных компонентных команд (команда базы данных, команда интеграционной шины, команда АБС), она попадает в утилизационную ловушку.

Чтобы выпустить одну сквозную фичу для клиента, продуктовая команда вынуждена встать на поклон в 7–10 таких технологических колодцев. Каждая задача застревает во встречных очередях Change Requests (CR). И вот тут начинается самое интересное. Если выгрузить бэклог и раскрасить задачи в цвета тех компонентных команд, которые должны делать интеграции, мы увидим страшный HeatMap.

Что показывает HeatMap бэклога в реальности:

1️⃣ ИТ-отдел утилизирует сам себя: инженеры платформы загружены «с горкой», но 80% их энергии уходит на перекладывание задач из одного ИТ-силоса в другой, согласование внутренних интерфейсов и бесконечные созвоны по стыковке компонентов. Это ложная, паразитная утилизация.

2️⃣ Время «протухания» задач превышает время работы: чистая разработка фичи занимает 3 дня, но более 60% календарного времени жизненного цикла задачи — это чистый простой в очередях ожидания ответов от смежников.

3️⃣ Паралич квартального планирования: попытка расписать «головы» компонентных команд на 3 месяца вперед в динамичном бизнесе создает лишь иллюзию порядка. Как только одна команда сдвигает сроки на неделю, по принципу «эффекта домино» рушатся планы остальных колодцев, превращая бэклог в хаос.

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

🚀 Что мы будем делать на практикуме в клубе Scrum-Mastery?

Построение и защита HeatMap бэклога - это высший пилотаж организационного консалтинга, который мгновенно переводит агентов изменений из роли «модератора встреч» в статус стратегического партнера для C-Level.

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

🎟 Доступ к практикуму, шаблонам и видеозаписи открыт для всех резидентов клуба. Занимайте свое место в контуре изменений по ссылке:https://scrum-mastery.ru

👉 Оформить абонемент и войти в клуб Scrum-Mastery

#ScrumMastery #AgileCoaching #SystemicThinking #OrgDesign #FlowEfficiency #HeatMap #InsideOut

💡 Аксиоматика Нама Су: как развязать организационные узлы и спроектировать автономную команду полного цикла

Бывало ли у вас так: вы собрали отличную команду, настроили процессы, РО горит идеей, но фичи все равно выходят раз в квартал? Вы заходите на ретроспективу, а разработчики разводят руками: «Мы все написали за два дня, но задача уже месяц висит на согласовании в безопасности, ждет ответа рисков и доработок от команды интеграционной шины».

Поздравляю, вы уперлись в «паразитный замок» организационной связанности. Когда команда делает руками только 30% задачи, а остальные 70% времени фича простаивает в очередях к смежникам — это не проблема плохих людей или плохой фасилитации. Это ошибка проектирования структуры. И лечится она не тренингами, а методологией аксиоматического проектирования MIT (теория Нама Су).

Три типа организационного дизайна: В каком лабиринте вы застряли?

Нама Су разделил архитектуру любых систем (включая оргструктуры) на три типа по уровню связанности элементов (Coupling):

1️⃣ Связанный дизайн (Coupled Design):

Это то, где сейчас живет 90% корпоративного рынка. Ситуация, когда для выполнения одной бизнес-задачи требуется одновременное, синхронное участие множества смежных компонентных команд, ИТ-комитетов и согласующих органов. Система блокирует сама себя. Шаг изменений тут равен не спринту, а кварталу - пока все колодцы не согласуют ресурсные планы.

2️⃣ Последовательный дизайн (Decoupled Design):

Зависимости между командами существуют, но они асинхронны и стандартизированы. Команда автономна, потому что все ключевые эксперты (бизнес, ИТ, Риски, ИБ) физически выведены из своих «функциональных колодцев» и на 100% времени выделены внутрь продуктовой группы. Смежники больше не пишут друг другу Change Requests - они собирают фичи на лету.

3️⃣ Независимый дизайн (Uncoupled Design):

Каждый юнит закрывает свою бизнес-потребность полностью самостоятельно. Изменение приоритетов одного процесса никак не аффектит другие.

Большинство агентов изменений пытаются разогнать команду, находящуюся в жестком Coupled-дизайне, с помощью локальных действий: сокращают дейли, меняют форматы ретро. Но законы физики оргдизайна неумолимы: локальная оптимизация в связанной системе дает нулевой эффект на выходе.

Чтобы сдвинуть сократить t2m, Скрам-мастер обязан действовать как архитектор: взять матрицу взаимодействия, найти связанные узлы, убрать паразитное вето смежников и помочь топ-менеджменту пересобрать «наилучшую комбинацию команды полного цикла».

На ближайшем потоке нашего клуба мы переходим от теории к суровому орг.проектированию. Мы будем учиться перестраивать системы «снаружи внутрь» - от клиента и бизнес-целей. И одно из первых занятий будет посвящено как раз практике аксимоматического проектирования. Что хотим сделать:

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

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

👉 Оформить абонемент и стать участником клуба Scrum-Mastery

#ScrumMastery #AgileCoaching #SystemicThinking #OrgDesign #FlowEfficiency #AxiomaticDesign

❓Почему 9 из 10 agile-трансформаций не дают результата, или как перестать быть «секретарем Jira»

Коллеги, давайте честно. Большинство из нас - Скрам-мастеров, Agile-коучей и лидеров трансформаций совершают одну и ту же классическую ошибку.

Сценарий почти всегда одинаковый:

1. Приходим в команду / контур.
2. Видим симптомы: «дейли затянуты», «бэклог непрозрачен», «ретроспективы стали формальностью (если вообще есть)».
3. Начинаем «лечить» доступными инструментами: учим фасилитации, перенастраиваем воркфлоу в Jira, проводим очередные базовые тренинги.
4. Результат через 3 месяца: процессы буксуют в тех же точках.

Почему? Потому что корень проблемы лежал вообще не в ритуалах.

Главная ошибка: мы смотрим «изнутри наружу» (Inside-Out)

Мы привыкли оценивать систему по локальным маркерам: по аккуратности логирования задач, по скорости закрытия тикетов, по утилизации и 100% загрузке разработчиков. Это классическая ловушка локальной оптимизации. Команда может идеально проводить дейли и закрывать спринты, но ценность до клиента не долетает месяцами, потому что задача «гниет» в очередях между ИТ-колодцами.

Как перевернуть мышление: взгляд «снаружи внутрь» (Outside-In)

Профессиональный организационный дизайн требует смотреть на систему глазами клиента и сквозного потока ценности. Нас должно волновать только одно: сколько календарных дней проходит от зарождения бизнес-идеи до ее фактического появления на продакшне (сквозной Time-to-Market), и какой процент времени задача реально разрабатывалась, а не висела в ожиданиях (Flow Efficiency).

Но как только мы переводим фокус на сквозной поток, базовых Agile-гайдлайнов становится катастрофически не хватать. Чтобы поставить системе точный диагноз, «архитектору изменений» нужны фундаментальные инженерные инструменты:

- Аудит организационного соответствия (например, Звезда Гелбрайта): чтобы увидеть, как метрики и структура компании прямо противоречат ее же рыночной стратегии.
- Матрица функциональной связанности (Coupled/Decoupled Design по Наму Су): инструмент из методологии аксиоматического проектирования MIT, позволяющий математически точно вскрыть паразитные связи и блокирующие «права вето» между подразделениями.
- Экосистемный VSM (Value Stream Mapping) «снаружи-внутрь»: картирование пути клиента, которое обнажает реальные «черные дыры» и простои на стыках между отделами (бизнесом, ИТ, рисками, ИБ).
- Продуктовый HeatMap бэклога: тепловая карта, наглядно показывающая, какая доля задач команды намертво заблокирована внешними зависимостями, компонентными командами ядра или вендорами.

От фасилитатора встреч к архитектору потока

Будем откровенны: большинство агентов изменений на рынке не используют эти инструменты. Кто-то про них не знает, а кто-то сознательно избегает, потому что проектировать организационные интерфейсы гораздо сложнее, чем «провести ретро по-новому».

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

В нашем клубе Scrum-Mastery мы будем полностью переворачивать понимание роли Скрам-мастера/агента изменений и переходить от фасилитации ритуалов к инженерии оргструктур.

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

Подключайтесь, чтобы не пропустить 👇
https://scrum-mastery.ru

#ScrumMastery #AgileCoaching #SystemicThinking #OrgDesign #FlowEfficiency

🚀 Осенний сезон в клубе Scrum Mastery

Архитекторы Потока: практикум по организационному дизайну
Время проведения всех встреч: 19:00 по МСК
Формат: Онлайн-воркшопы с разбором реальных кейсов, живым обсуждением и практическими домашними заданиями.

📅 РАСПИСАНИЕ СЕЗОНА (Сентябрь)

🏛 МОДУЛЬ 1. Стратегия и Диагностика: как найти разрывы между стратегией и операционкой

🗓 Дата: Вторник, 1 сентября, 19:00 МСК Что разберем: Модель Гелбрайта (Star Model). Как проводить глубинные интервью по структурированному опроснику (Strategy, Structure, Processes, Rewards, People).

🔗 МОДУЛЬ 2. Диагностика организационной связанности: почему система буксует
🗓 Дата: Вторник, 8 сентября, 19:00 МСК
Что разберем: Аксиоматическое проектирование. Три типа архитектур (Uncoupled, Decoupled, Coupled).

🗺 МОДУЛЬ 3. Value Stream Mapping: от «идеи» до «денег клиента»
🗓 Дата: Четверг, 10 сентября, 19:00 МСК
Что разберем: Как проводить VSM, находить скрытые очереди и правильно интерпретировать результат для топ-менеджмента

🔥 МОДУЛЬ 4. HeatMap бэклогов: что реально съедает емкость команд
🗓 Дата: Вторник, 15 сентября, 19:00 МСК
Что разберем: Как классифицировать входящий поток и как это влияет на целевую структуру

🏗 МОДУЛЬ 5. Проектирование целевой структуры (To-Be): от хаоса к развязанной системе
🗓 Дата: Четверг, 22 сентября, 19:00 МСК
Что разберем: Принципы Decoupled-архитектуры

🗺 МОДУЛЬ 6. Карта Гипотез трансформации: как продавать и внедрять изменения
🗓 Дата: Вторник, 29 сентября, 19:00 МСК (специально перенесено на конец месяца, чтобы избежать 24.09 и дать время на финальную сборку)
Что разберем: Как правильно формулировать цели, метрики успеха и балансирующие метрики для трансформации

Стать резидентом: https://scrum-mastery.ru

#ScrumMastery #AgileTransformation #OrganizationalDesign #ValueStreamMapping #FlowMetrics #АрхитекторыПотока

🤔 Ловушка платных метрик: как KPI на скорость парализует компанию

Когда операционная модель упирается в тупик, у топ-менеджмента часто срабатывает простой рефлекс: «Привяжем KPI к деньгам - люди начнут работать быстрее».

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

Например:

KPI на квартал: сократить время разработки на 20% относительно предыдущего квартала.
Вес в премии: 35% для тимлидов и Scrum-мастеров.

Что происходит дальше?

1. Сложные задачи становятся угрозой

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

2. Метрика начинает важнее реальности

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

3. Ошибки становятся невыгодными

Баг - это новая работа и дополнительное время. Если он ухудшает показатель скорости, появляется естественный соблазн не отражать его в системе или обходить формальный процесс. В итоге скорость на дашборде растет, а скорость доставки ценности - нет.

4. Разрушается единая картина реальности

Бизнес перестает доверять Jira и начинает вести собственные Excel-таблицы. ИТ защищает свои показатели. Руководство получает несколько версий происходящего:

- ИТ: «У нас растет скорость».
- Бизнес: «Мы не видим ускорения результата».
- Реальность: никто уже не может точно сказать, что происходит.

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

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

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

❗️Поэтому перед тем как привязывать KPI к премии, стоит задать простой вопрос:

«Что люди начнут делать, если от этого показателя будет зависеть их зарплата?»

Иногда ответ на этот вопрос гораздо важнее самого KPI.🤔