Суть. Продукт неизбежно повторяет структуру организации, которая его строит. Значит, структуру команд нужно проектировать, а не наследовать. Подход предлагает четыре типа команд и три чётко описанных способа взаимодействия между ними — вместо «все общаются со всеми».
Четыре типа команд
| Тип | Задача | Пример |
|---|---|---|
| Поток создания ценности | Отвечает за кусок продукта целиком, от идеи до эксплуатации | Команда, ведущая направление для одного сегмента клиентов |
| Платформа | Даёт другим командам готовые возможности как самообслуживание | Внутренняя платформа развёртывания |
| Помогающая | Временно приходит и повышает уровень другой команды | Инженеры по надёжности на два месяца |
| Сложная подсистема | Держит участок, требующий редкой экспертизы | Расчётное ядро, обработка платежей |
Ключевое понятие — когнитивная нагрузка
Команда способна держать в голове ограниченный объём. Если ей выдали пять сервисов, три языка и две предметные области, она будет медленной независимо от квалификации. Границы команд проводятся так, чтобы нагрузка помещалась, — а не по функциональному признаку.
Когда применять
При росте инженерной организации примерно за три-четыре команды, когда согласования между ними начинают занимать больше времени, чем сама работа. Модель отвечает на вопрос не «кто кому подчиняется», а «кто с кем и как именно взаимодействует».
Четыре типа команд
| Тип | Задача | Признак, что тип выбран неверно |
|---|---|---|
| Поток создания ценности | Доводит изменения до пользователя самостоятельно | Не может выпустить релиз без трёх других команд |
| Платформа | Даёт внутренние сервисы, которыми пользуются добровольно | Пользование обязательно по приказу, а не по удобству |
| Сложная подсистема | Держит участок, требующий редкой экспертизы | Создана под обычную задачу и стала узким местом |
| Помогающая | Временно усиливает другую команду и уходит | Существует годами, значит это скрытая зависимость |
Три способа взаимодействия
- Совместная работа. Две команды временно работают как одна. Быстро, но дорого и не масштабируется — только на время выяснения неизвестного.
- Сервис как продукт. Одна команда пользуется результатом другой без разговоров, по документации. Основной режим зрелой организации.
- Помощь. Одна команда учит другую и выходит. Всегда с датой окончания.
Ключевое правило: режим взаимодействия выбирается сознательно и на срок. Неназванный режим по умолчанию превращается в постоянные согласования.
Нагрузка на голову
Команда способна удерживать ограниченное число областей ответственности. Организация, которая раздаёт по пять систем на команду из четырёх человек, получает не экономию, а поверхностное владение всем и глубокое — ничем. Разделение по этому принципу даёт больше, чем любая реорганизация по функциям.
Где ломается
Переименовали отделы. Названия сменили, зависимости остались — ничего не изменилось.
Платформа без пользователей. Платформенная команда строит то, что удобно ей, а не то, чем пользуются. Признак — командам проще сделать в обход.
Помогающая команда становится постоянной. Тогда это не помощь, а вынос ответственности наружу.
- Переименование без изменения. Отдел эксплуатации, названный платформой, но работающий по заявкам, платформой не становится.
- Платформа без внутренних клиентов. Если её сервисами пользуются по принуждению, значит, они хуже альтернатив.
- Помогающая команда навсегда. Признак, что знание не передаётся, а удерживается.
- Границы команд не совпадают с границами систем. Тогда любое изменение требует трёх команд, и никакая методология это не исправит.