Scrum Mastery Club - развитие в Scrum

💡 Аксиоматика Нама Су: как развязать организационные узлы и спроектировать автономную команду полного цикла Бывало ли у вас так: вы собрали отличную команду, настроили процессы, РО горит идеей, но фичи все равно выходят раз в квартал? Вы заходите на ретроспективу, а разработчики разводят руками: «Мы все написали за два дня, но задача уже месяц висит на согласовании в безопасности, ждет ответа рисков и доработок от команды интеграционной шины». Поздравляю, вы уперлись в «паразитный замок» организационной связанности. Когда команда делает руками только 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