---
title: "Team Topologies — четыре типа команд"
url: "https://kzsaleshub.com/framework/team-topologies/"
type: "framework"
category: "Операции"
language: "ru"
source: "KZSalesHub"
published: "2026-08-11"
last_updated: "2026-09-03"
---

# Team Topologies — четыре типа команд

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

## Четыре типа команд

| Тип | Задача | Пример |
| --- | --- | --- |
| Поток создания ценности | Отвечает за кусок продукта целиком, от идеи до эксплуатации | Команда, ведущая направление для одного сегмента клиентов |
| Платформа | Даёт другим командам готовые возможности как самообслуживание | Внутренняя платформа развёртывания |
| Помогающая | Временно приходит и повышает уровень другой команды | Инженеры по надёжности на два месяца |
| Сложная подсистема | Держит участок, требующий редкой экспертизы | Расчётное ядро, обработка платежей |

## Ключевое понятие — когнитивная нагрузка

Команда способна держать в голове ограниченный объём. Если ей выдали пять сервисов, три языка и две предметные области, она будет медленной независимо от квалификации. Границы команд проводятся так, чтобы нагрузка помещалась, — а не по функциональному признаку.

## Когда применять

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

## Типы команд и признаки неверного выбора

| Тип | Задача | Признак, что тип выбран неверно |
| --- | --- | --- |
| Поток создания ценности | Доводит изменения до пользователя самостоятельно | Не может выпустить релиз без трёх других команд |
| Платформа | Даёт внутренние сервисы, которыми пользуются добровольно | Пользование обязательно по приказу, а не по удобству |
| Сложная подсистема | Держит участок, требующий редкой экспертизы | Создана под обычную задачу и стала узким местом |
| Помогающая | Временно усиливает другую команду и уходит | Существует годами, значит это скрытая зависимость |

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

- **Совместная работа.** Две команды временно работают как одна. Быстро, но дорого и не масштабируется — только на время выяснения неизвестного.
- **Сервис как продукт.** Одна команда пользуется результатом другой без разговоров, по документации. Основной режим зрелой организации.
- **Помощь.** Одна команда учит другую и выходит. Всегда с датой окончания.

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

## Нагрузка на голову

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

## Где ломается

**Переименовали отделы.** Названия сменили, зависимости остались — ничего не изменилось.

**Платформа без пользователей.** Платформенная команда строит то, что удобно ей, а не то, чем пользуются. Признак — командам проще сделать в обход.

**Помогающая команда становится постоянной.** Тогда это не помощь, а вынос ответственности наружу.

- **Переименование без изменения.** Отдел эксплуатации, названный платформой, но работающий по заявкам, платформой не становится.
- **Платформа без внутренних клиентов.** Если её сервисами пользуются по принуждению, значит, они хуже альтернатив.
- **Помогающая команда навсегда.** Признак, что знание не передаётся, а удерживается.
- **Границы команд не совпадают с границами систем.** Тогда любое изменение требует трёх команд, и никакая методология это не исправит.

## Частые вопросы

**С какого размера имеет смысл**

Примерно с трёх-четырёх команд. До этого структура проще, и формализация только мешает.

**Как понять, что нужна платформенная команда**

Когда одно и то же решают самостоятельно три разные команды и делают это по-разному. Это и есть кандидат на внутренний сервис.

**Как связано с архитектурой**

Прямо: структура команд со временем воспроизводится в структуре систем. Проектировать их стоит вместе, а не по отдельности.

## Связанное

- [Внутренний клиент](https://kzsaleshub.com/framework/internal-customer/)
- [Бизнес-архитектура](https://kzsaleshub.com/framework/business-architecture/)

Если структура команд не совпадает с устройством продукта, любая перестройка процессов останется косметикой. Начинать нужно со связей между командами.

---
Источник: https://kzsaleshub.com/framework/team-topologies/