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

Отправная точка — приём working backwards, он же backcasting: начинать с конечной цели и двигаться от неё назад. Из него вырастает алгоритм из пяти шагов: определить долговременную цель подразделения, оценить, какая архитектура систем подходит наилучшим образом, применить обратный манёвр Конвея, чтобы вывести из архитектуры структуру команд, разложить её по паттернам Team Topologies и провести переход через управление изменениями.

Перед всем этим есть нулевой шаг — определить, где горит, и починить. Пока подразделение живёт в аварийном режиме, проектировать целевую структуру бессмысленно. Опора — статья Мелвина Конвея «How Do Committees Invent?» 1968 года и книга Team Topologies с четырьмя типами команд: stream-aligned, платформенные, вспомогательные и команды сложных подсистем. К ним прилагаются три режима взаимодействия: collaboration, facilitating и x-as-a-service.

Первый кейс — переезд веб-приложений на новый сайт в 2016 году. Разработка нового решения шла больше года, общая команда состояла из 50 с лишним человек, во фронтовой команде автора было три человека, а до переезда оставалось три месяца. Открытых проблем было четыре: не работал server-side rendering, не было веб-аналитики для SPA, механики форм не были доведены, а релизы занимали около трёх недель из-за ручного регресса.

Ответом стал проектный подход: короткие итерации, отдельная инфраструктура, своя ветка разработки и два релиза в неделю вместо трёхнедельного цикла. К сроку основные формы и страницы перевезли практически без потерь. В середине 2017 года задача сменилась с проектной на продуктовую — server-driven UI, собственная система A/B-тестирования, улучшение индексации. Ответственность фронтовой команды, команды content-сервисов и A/B-платформы развели через API, а работу организовали по Kanban с визуализацией потока.

С 2019 года тот же алгоритм применили к мобильному банку. На старте это была одна общая команда почти на 50 человек, работавшая сразу над всеми продуктами. Через закон Конвея, обратный манёвр и Team Topologies её развели на автономные команды по продуктовым вертикалям и платформенные команды с фокусом на модуляризацию, надёжность, производительность и CI/CD. Частоту релизов ускорили в несколько раз, но автор подчёркивает: это многолетнее управление изменениями, а не разовая перестановка.

В 2022 году ключевые продукты перевели с команд, собранных по стеку, на сквозные stream-aligned: цели — сократить время выхода на рынок, снизить когнитивную сложность и улучшить архитектуру. Для новых команд зафиксировали обязательные правила: атрибуты команды, процессы разработки и поставки, правила эксплуатации, а также автоматическую проверку здоровья. Метрики собирали по трём осям — производительность разработчиков, качество продукта и пропускная способность команд; ориентиром служила работа Meta «Continuous Deployment of Mobile Software at Facebook».