Team Topologies

От бизнес-стратегии к архитектуре через команды

19 апреля 2026

Справочник

Team Topologies помогает обсуждать устройство инженерной организации: какие задачи решают команды, за что отвечают и как взаимодействуют. В основе подхода четыре типа команд и три режима взаимодействия. В статье рассматриваю связь целей бизнеса, доменных границ, команд и архитектуры, а затем разбираю пример изменений в B2B SaaS с примерно 150 инженерами.

Закон Конвея работает в обе стороны Почему команды первичнее архитектуры и процессов Цепочка выравнивания: Бизнес → DDD → Команды → Архитектура Четыре фундаментальных типа команд Три паттерна взаимодействия Когнитивная нагрузка как ограничение Границы и Team API Триггеры реорганизации Применимость по стадиям роста и AI Кейс: перестройка инженерной организации B2B SaaS Частые ошибки внедрения Источники и смежные статьи

Закон Конвея работает в обе стороны

Закон Конвея связывает структуру коммуникации организации с устройством проектируемой системы. Он не задает соответствие «одна команда - один компонент» и не гарантирует, что изменение оргструктуры автоматически изменит архитектуру.

Reverse Conway Maneuver использует связь коммуникации и архитектуры при проектировании организации. Если мы хотим изменить границы системы, стоит проверить, какие команды будут отвечать за новые части и как они будут работать вместе. Изменение оргструктуры может поддержать архитектурные изменения, но само по себе их не выполняет.

При изменении архитектуры нужно пересмотреть ответственность за ее части. Иногда достаточно уточнить договоренности между существующими командами, иногда требуется изменить их состав или границы.

Почему команды первичнее архитектуры и процессов

Частый сценарий: инженерные лидеры видят архитектурные проблемы (дублирование, связанность, медленный deploy) и начинают чинить их на уровне кода. Пишут ADR, добавляют boundaries, запускают рефакторинг. Через полгода картина не меняется: границы размываются обратно, ADR игнорируются, дублирование возрождается в новых местах.

Причина может быть в распределении ответственности между командами. Если бизнес воспринимает разработку как общий ресурс для выполнения любых задач, границы ответственности перестают соблюдаться. Команды разбивают поступающие задачи и добавляют их в бэклог, но взаимного выравнивания «эта задача в эту команду, потому что эта команда отвечает за этот бизнес-сценарий и этот участок архитектуры» не происходит. Становится неясно, кто отвечает за пользовательский сценарий целиком и кто поддерживает соответствующий модуль.

Совместный проект проверяет, насколько новые границы пригодны для работы. Если команда регулярно меняет чужие модули, стоит выяснить причину: неудачные границы, нехватка полномочий или временная потребность в совместной работе.

Рабочая эвристика - идти в обратную сторону: сначала выравнивать структуру команд с бизнес-доменами и зоной ответственности, а процессы внутри команд и архитектуру между ними оптимизировать уже потом. На практике topology и архитектура обычно меняются итеративно, а не строго последовательно: границы уточняются по мере того, как проясняются домены. Последовательность «сначала команды» - целевой ориентир, а не жесткое правило; но без выравнивания команд оптимизация процессов и архитектуры в нашем случае превращается в постоянную борьбу с последствиями.

Цепочка выравнивания: Бизнес → DDD → Команды → Архитектура

Выравнивание инженерной организации под бизнес - последовательность из четырех шагов.

Шаг 1. Бизнес-стратегия. Определяются направления бизнеса: где компания зарабатывает, какие сценарии используют клиенты, где происходит рост. Для этого описывают потоки создания ценности: как запрос клиента превращается в результат для него и доход компании.

Шаг 2. Domain-Driven Design. Каждый value-stream разбивается на bounded contexts - ограниченные контексты с явными моделями, термины которых имеют смысл только внутри своего контекста. Биллинг, лидогенерация, аналитика - разные контексты. Они могут использовать слово «клиент», но это разные клиенты с разными атрибутами и жизненными циклами. DDD дает словарь и границы.

Шаг 3. Team Topologies. У каждого bounded context появляется команда-владелец. Соответствие часто не строго один-к-одному: одна команда может владеть несколькими близкими контекстами (если их суммарная cognitive load это позволяет), а большой контекст иногда требует нескольких команд. Для каждого контекста нужно определить владельца с правом принимать решения внутри его границ и ответственностью за результат. Team Topologies формализует какие бывают типы команд и как они взаимодействуют, чтобы структура была устойчива.

Шаг 4. Архитектура. Архитектура становится отражением предыдущих трех шагов. Границы в коде повторяют границы доменов. Сервисы или модули монолита - способ реализации; важнее, что команда владеет своим участком end-to-end, включая код, тесты, deploy, мониторинг и SLA.

Порядок принципиален. Если начать с архитектуры (шаг 4) без первых трех, получится красивая диаграмма, которая не совпадает с реальной структурой команд и не выживет под продуктовым давлением. Если пропустить шаг 2 и пытаться разбить команды по «фичам» без доменного мышления, команды начнут конкурировать за одни и те же сущности.

Четыре фундаментальных типа команд

Team Topologies выделяет четыре типа. Это рабочая эвристика, а не закон: в нашем случае она помогает назвать доминирующую роль команды, но реальные команды часто гибридны и на переходных этапах совмещают функции. Целевой ориентир - чтобы у каждой команды был один основной тип; устойчивое смешение всех ролей - антипаттерн (подробнее ниже).

Stream-aligned team - команда, выровненная по потоку ценности. Владеет одним bounded context целиком: продуктовая зона, пользовательский сценарий, бизнес-функция. Это «основная» команда организации; остальные три типа существуют чтобы Stream-aligned могли работать эффективно. Состав: все компетенции для end-to-end доставки (фронт, бэк, QA, часто и DevOps). Размер и состав выбирают по задаче и нагрузке.

Platform team - команда, предоставляющая внутренний продукт (платформу) для Stream-aligned команд. Помогает снизить нагрузку, связанную с инфраструктурой, наблюдаемостью, CI/CD и общими сервисами. Platform team развивает платформу как внутренний продукт. Есть внутренние клиенты (Stream-aligned), документация, SLA, roadmap. Если продуктовые команды не хотят пользоваться платформой, нужно разобраться, какие потребности она не закрывает и что мешает ее использовать.

Enabling team - команда, временно подключающаяся к Stream-aligned чтобы передать экспертизу и уйти. Примеры: внедрение нового стека (например, ML-компонентов в продукт), освоение новой практики (performance-инженерия, security-testing). Enabling team не становится постоянной частью delivery: ее успех - когда Stream-aligned стала самодостаточной в этой области. Срок и условия завершения участия согласуют с командой.

Complicated-subsystem team - команда, владеющая технически сложной подсистемой, требующей специализированных знаний (сложные алгоритмы, кодеки, научные модели, криптография). Существует потому что включение этой подсистемы в Stream-aligned команду превышает ее cognitive load. Это редкий тип; применяется когда действительно нужна глубокая экспертиза.

Практический антипаттерн - команда, которая «и Platform, и Enabling, и еще немного Stream-aligned». Такая команда не может выполнить ни одну из ролей хорошо: Stream-aligned требует владения бизнес-контекстом, Platform требует продуктового мышления для внутренних клиентов, Enabling требует готовности уйти. Одновременно все три - когнитивный перегруз.

Три паттерна взаимодействия

Команды взаимодействуют между собой. Team Topologies описывает три паттерна.

Collaboration - тесная совместная работа на общий результат. Две команды работают как одна: общие встречи, общий код, общая ответственность. Оправдан в периодах неопределенности (новый продукт, непонятная архитектура) и на стыках. Недостаток - высокая cognitive load на обе команды, медленная доставка, размытие границ. Для Collaboration нужно определить цель, период и условия пересмотра режима.

X-as-a-Service - одна команда потребляет сервис другой команды через четкий контракт. Stream-aligned использует сервисы Platform team как клиент использует SaaS: по документации, без звонков разработчикам. Это целевое состояние зрелой организации: минимум координации, максимум независимости. Требует развитого Platform team и хорошей документации.

Facilitating - одна команда помогает другой преодолеть препятствие. Enabling team - типичный facilitator: подключается, передает знания, уходит. В отличие от Collaboration здесь одна сторона явно ведет, другая учится; отношения временные.

Тип команды Типичные паттерны взаимодействия
Stream-aligned X-as-a-Service с Platform. Facilitating с Enabling (редко). Collaboration с соседними Stream-aligned на стыках.
Platform X-as-a-Service со всеми пользователями. Иногда Collaboration с ключевыми Stream-aligned при проектировании новых сервисов.
Enabling Facilitating по определению.
Complicated-subsystem X-as-a-Service с пользователями подсистемы.

Диагностический вопрос: если команды A и B находятся в Collaboration дольше квартала - это baseline, или мы не отстроили интерфейс между ними? X-as-a-Service - целевое состояние при таких условиях: когда граница стабильна, а контракт между командами можно формализовать. Эта эвристика не сработает, если граница по-настоящему сложная и подвижная - на стыке нового продукта или неустоявшейся архитектуры Collaboration может быть постоянным осознанным режимом, а не переходным.

Когнитивная нагрузка как ограничение

Когнитивная нагрузка зависит от сложности домена, инструментов, обязанностей и взаимодействия с соседями. Число людей или доменов само по себе не определяет, справится ли команда с работой. Следующие вопросы помогут оценить нагрузку:

Состав команды должен позволять выполнять работу и поддерживать понятные способы согласования решений. Числа Данбара не задают норматив размера инженерной команды.

Если бизнес требует больше доменов, чем есть команд - это не приглашение «перегрузить каждую команду еще одним доменом». Обычно это сигнал либо нанять команду, либо сократить скоп, либо вывести домен в Platform. Попытка обойти ограничение через «команда теперь владеет четырьмя зонами» чаще всего дает фейковую команду, которая формально везде, фактически нигде. Оговорка: матричное распределение одних и тех же людей по нескольким зонам иногда является сознательным компромиссом - например, при дефицитной экспертизе, когда единственный носитель знаний по домену физически не может сидеть только в одной команде. Такой компромисс работает, если он назван явно и ограничен по времени; он не сработает, если превращается в постоянную модель, маскирующую отсутствие ownership.

Границы и Team API

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

Team API - набор документов, фиксирующих границы команды:

Team API - публичный артефакт. Любая команда в организации может прочитать Team API соседней и понять, как с ней взаимодействовать. Это контракт по сути: нарушение Team API - повод для разговора между командами или tech-lead-ами.

Триггеры реорганизации

Топология команд не статична. Есть маркеры, когда пора менять структуру.

Любой из маркеров - повод провести аудит через Team API и оценить, нужна ли реструктуризация. Несколько симптомов требуют совместной диагностики, но не доказывают необходимость реорганизации.

Применимость по стадиям роста и AI

Стартап 5-15 инженеров. Полное разделение типов команд не имеет смысла - людей не хватит. Одна команда закрывает все роли: строит продукт, поддерживает инфраструктуру, общается с клиентами. Попытка создать Platform team из двух человек даст bottleneck, а не пользу.

Но это не значит, что Team Topologies не применим. Два действия работают даже на этой стадии:

Рост до 30-50 инженеров. Появляется первая реальная необходимость в формальной топологии. Обычно первые два Stream-aligned команды по ключевым value-streams, и начало Platform team (1-2 человека, которые сначала совмещают с Stream-aligned ролями, потом выделяются).

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

Но это не отменяет Team Topologies, только сдвигает сроки. Ключевой антипаттерн новой эпохи - вера, что AI делает ownership ненужным. Логика «AI помогает каждой команде понимать все, значит можно не разделять зоны ответственности» опасна. AI эффективно работает с формализованным контекстом (код, документация, артефакты), но не компенсирует недостаток понимания реального мира: что хочет клиент, почему этот сценарий важнее того, когда компромисс допустим, а когда нет. Эти решения опираются на человеческий контекст, который не переносится в токены.

Размытие ответственности под лозунгом «AI за нас разберется» дает тот же эффект, что и бизнес, воспринимающий разработку как универсальный контейнер: команды декомпозируют прилетающее, но никто не владеет сценарием. AI снижает минимальный порог применимости Team Topologies и удешевляет каждую команду, но не отменяет структурный закон Конвея и не заменяет владение бизнес-контекстом.

Кейс: перестройка инженерной организации B2B SaaS

Организация: около 150 инженеров, B2B SaaS. Рост выручки требует новых сценариев и быстрой разработки, параллельно накапливается архитектурный и платформенный долг.

Диагноз. Бизнес воспринимает разработку как общий ресурс для выполнения любых задач. Границы между командами не соблюдаются: задачи распределяются по доступности людей, а не по зонам ответственности. Команды разбивают поступающие задачи и добавляют их в бэклог, но бизнес и инженерия не согласовывают ответственность команд. Неясно, кто отвечает за пользовательский сценарий целиком и кто поддерживает соответствующий модуль. Из-за этого любые архитектурные инициативы идут волнами: стартуют с энтузиазмом, стопорятся на границе чужой команды, тихо умирают.

Решение. Выравнивание топологии по цепочке из раздела «Цепочка выравнивания».

Stream-aligned teams по продуктовым кластерам. Каждая команда - владелец одной бизнес-зоны (кластер сценариев). Формально зафиксировано, кто отвечает за какие пользовательские потоки, метрики этих потоков, технические артефакты (код, сервисы, данные). Команды получили право отказаться от задач вне своей зоны и обязанность отвечать за свою end-to-end.

Platform team с явной ответственностью за платформенный слой: CI/CD, наблюдаемость, developer experience, SLA-доступность, безопасность. До перестройки платформенные вопросы размывались между Stream-aligned командами, никто целенаправленно их не вел. Теперь Platform - внутренний продукт с внутренними клиентами.

Governance-механизм в этом примере для формализованного процесса Technical Design Review. Цель - убрать стихийные архитектурные решения, создающие взаимные конфликты между Stream-aligned командами. TDR фиксирует: изменения, затрагивающие API, данные, производительность, безопасность или границы между кластерами, проходят через публично описанный процесс с критериями, ролями (author, challenger, owner), форматом документа и SLA. Решения публикуются и становятся стандартом.

Enabling team для временных инициатив с передачей знаний. Запуск ML-компонентов в продукт прошел через Enabling-формат: небольшая команда с ML-экспертизой подключалась к Stream-aligned, встраивала ML в их работу и завершала участие, когда Stream-aligned могла развивать эту часть самостоятельно. Без Enabling-формата пришлось бы держать постоянную ML-команду, которая быстро стала бы bottleneck для всех ML-запросов.

Результаты. Платформа получила владельца и зафиксированные SLA. Архитектурные границы начали отражать деление на бизнес-домены - без остановки продуктового трека. Работу с архитектурным долгом включили в план. Стабильность и инцидентность улучшились.

На этом этапе можно описать изменения в работе; для оценки их эффекта по метрикам нужен период наблюдения. Ownership перестал быть размытым понятием, которое каждый трактует по-своему. Архитектурные решения перестали возникать стихийно. Появилась команда, отвечающая за платформенные задачи. Бизнес получил предсказуемую скорость доставки в обмен на согласование скоупа с командами-владельцами, а не на прямую отправку задач в backlog.

Частые ошибки внедрения

Источники и смежные статьи

Первоисточники

Связанные темы

Смежные статьи блога