Как формировать структуру команд под запросы бизнеса

Отправной тезис: структура следует стратегии бизнеса и задаёт скорость поставки. Плохая структура превращается в набор узких мест, хорошая даёт автономию. Первая рамка — три горизонта зрелости: Run как стабильная эксплуатация, Change как улучшение текущего бизнеса и Disrupt как создание новых продуктов. Каждому горизонту нужны свои типы команд и свои процессы, а сервисная компания расставляет акценты иначе, чем продуктовая.

Вторая рамка — закон Конвея: система копирует коммуникационную структуру организации. Отсюда обратный манёвр, когда оргструктуру проектируют под желаемую архитектуру. Микросервисы требуют автономных команд, монолит обычно отражает централизацию, а менять архитектуру, не трогая структуру, бессмысленно. Дальше идёт Team Topologies Скелтона и Пейса: stream-aligned, платформенные, enabling и команды сложных подсистем, плюс три режима взаимодействия — collaboration, x-as-a-service и facilitating.

Ограничитель зоны ответственности — когнитивная нагрузка команды: её память конечна. Автор раскладывает нагрузку на три вида: intrinsic, то есть сложность самой задачи, extraneous — сложность инструментов и окружения, и germane — обучение и осмысление. Слишком широкий охват дробит фокус и увеличивает число дефектов, поэтому хорошая платформа существует прежде всего ради снижения extraneous-нагрузки на продуктовые команды.

Состав stream-aligned команды: продуктовый менеджер с приоритетами и дорожной картой, разработчики бэкенда, фронтенда и мобильных приложений, QA или SDET, аналитик с требованиями и метриками, а в продуктовых командах ещё и дизайнер. Размер обычно 5–9 человек, близко к правилу двух пицц Amazon. Платформа описана как внутренний продукт: у неё есть свой менеджер продукта, дорожная карта, SLA на сервисы, самообслуживание через документацию, шаблоны и CLI, а метрики — внедрение и удовлетворённость.

Кейс крупного финтеха показан как последовательность шагов: старт из ресурсного пула и потока feature-задач, затем feature-команды, затем платформенные команды, затем деление по бизнес-доменам. Результат — больше автономии и кратный рост скорости поставки за счёт устойчивых продуктовых потоков и платформенной поддержки. Проверяют структуру двумя наборами метрик: объективными — DORA с временем поставки и MTTR — и субъективными: SPACE и DevEx, где смотрят на поток, обратную связь и когнитивную нагрузку; eNPS используют как опережающий индикатор оттока.

Отдельный список — вредные структуры: матрица с несколькими линиями подчинения, ресурсный пул вместо стабильных команд, общие сервисы без SLA, деление по технологиям вместо доменов и слишком крупные команды, больше 12 человек, где коммуникации дорожают, а ответственность размывается. Модели автор аккуратно отделяет от практики: Team Topologies, закон Конвея, теория когнитивной нагрузки и исследования DORA, SPACE и DevEx — внешние источники, а примеры структур — опыт конкретной компании.