Как проектировать автономную команду полного цикла

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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