Team Topologies

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

19 апреля 2026

Закон Конвея работает в обе стороны: структура команд отражается в архитектуре, и наоборот. Если команды не выровнены с бизнес-доменами, дальнейшая оптимизация процессов и архитектуры бессмысленна - команды не могут отвечать за результат end-to-end, ответственность размывается, архитектурный долг накапливается. Team Topologies даёт язык для описания этого выравнивания через четыре типа команд и три паттерна взаимодействия. Статья разбирает цепочку «бизнес-стратегия → DDD → топология команд → архитектура» и показывает её на примере трансформации инженерной организации B2B SaaS на ~150 инженеров.

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

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

Мелвин Конвей в 1968 году сформулировал: любая организация, проектирующая систему, воспроизведёт в системе свою коммуникационную структуру. Если в компании три команды, система получится из трёх компонентов. Если команды общаются редко - между компонентами будут жёсткие интерфейсы с малым количеством обменов. Если команды слиты - компоненты получатся связанными.

Много лет Конвея цитировали как описание ограничения: мы не можем спроектировать систему, сильно отличную от структуры команд. Но в обе стороны это работает как инструмент. Если хотим получить модульную архитектуру - собираем модульно независимые команды. Если хотим распределённую систему - нужны команды с чёткими API между собой. Эта практика получила название Reverse Conway Maneuver: сначала меняем структуру команд, потом система перестраивается под неё.

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

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

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

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

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

Правильная последовательность - обратная. Сначала выравнивается структура команд с бизнес-доменами и зоной ответственности. Только потом имеет смысл оптимизировать процессы внутри команд и архитектуру между ними. Без первого шага второй и третий - постоянная борьба с последствиями.

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

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

Шаг 1. Бизнес-стратегия. Определяются зоны value: где компания зарабатывает, какие сценарии используют клиенты, где происходит рост. Это не про «что нам кажется важным», это про карту value-streams - потоков создания ценности от события в мире клиента до денег в P&L.

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

Шаг 3. Team Topologies. Каждый bounded context получает команду-владельца. Это не бумажная ответственность, а право принимать решения внутри границы и обязанность отвечать за метрики этого контекста. Team Topologies формализует какие бывают типы команд и как они взаимодействуют, чтобы структура была устойчива.

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

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

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

Team Topologies выделяет четыре типа. Каждая команда должна быть одним из них; смешение - антипаттерн.

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

Platform team - команда, предоставляющая внутренний продукт (платформу) для Stream-aligned команд. Снимает с них cognitive load по инфраструктуре, observability, CI/CD, общим сервисам. Ключевое отличие от классической infra-команды: Platform team относится к своему результату как к продукту. Есть внутренние клиенты (Stream-aligned), документация, SLA, roadmap. Если Stream-aligned не хотят пользоваться платформой - это сигнал, что платформа плохая, а не что пользователи неправы.

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

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.

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

Команда из 5-9 человек может удерживать определённый объём сложности. Превышение приводит к снижению качества, росту багов, потере скорости. Team Topologies вводит эвристики мепинга нагрузки:

Размер команды обычно 5-9 (число Данбара для плотных коммуникаций). Больше - информация не циркулирует, появляются под-группы. Меньше - не хватает компетенций для end-to-end.

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

Границы и 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 и микрокоманды - смещение точки перехода на ранний этап. AI-агенты меняют экономику команды: 2-3 инженера с хорошей инфраструктурой контекста и агентами покрывают объём работы, для которого раньше требовалось 5-7 человек. Это позволяет формировать специализированные команды раньше - Platform team из двух человек, усиленных агентами, может давать сервис, сопоставимый с классической командой из пяти. Момент перехода от «одна команда = весь продукт» к первому разделению на Stream-aligned и Platform сдвигается от ~30 инженеров к более ранней фазе: компания на 15-20 инженерах уже может содержать два специализированных микротима по логике Team Topologies.

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

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

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

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

Диагноз. Бизнес воспринимает разработку как универсальный контейнер, в который можно закинуть любую задачу. Границы между командами не соблюдаются: задачи распределяются по free capacity, а не по зонам ответственности. Команды честно декомпозируют прилетающее в backlog, но взаимного выравнивания бизнес ↔ инженерия не происходит. Ownership размыт и бизнесово (никто не отвечает за сценарий end-to-end), и архитектурно (никто не отвечает за модуль end-to-end). Из-за этого любые архитектурные инициативы идут волнами: стартуют с энтузиазмом, стопорятся на границе чужой команды, тихо умирают.

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

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

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

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

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

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

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

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

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

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

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

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