Team Topologies: что это и 4 типа команд

Автор

Мэттью Скелтон и Мануэль Паис, 2019

Уровень

301 · Продвинутый

Подходит

растущая компания, корпорация

Время на внедрение

полдня, чтобы описать текущие команды; затем квартал, чтобы изменить одно взаимодействие

Что понадобится

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

Team Topologies («Топологии команд») — подход к проектированию организации для технологической и интеллектуальной работы. Мэттью Скелтон (Matthew Skelton) и Мануэль Паис (Manuel Pais) издали его книгой в 2019 году в IT Revolution Press. Предисловие написала Рут Мэлан (Ruth Malan). Первое издание содержит восемь глав и заключение в трёх частях: команды как средство поставки, топологии для потока, взаимодействия для инноваций. Второе издание на 304 страницы вышло 23 сентября 2025 года. В него добавлены кейсы из нескольких отраслей.

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

Подход опирается на четыре типа команд, три способа взаимодействия и одно общее ограничение: объём сложности, который способна нести команда. Он рассчитан на компании, где много команд и общих сервисов. Поэтому на этой странице он отнесён к стадиям scale-up и enterprise.

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

Типов четыре. Определения приводит teamtopologies.com.

Последний столбец — наша иллюстрация. Книга написана для ИТ-команд и разработки ПО. Источников, которые проверяли бы эти типы в маркетинге, мы не нашли.

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

Команды взаимодействуют одним из трёх способов, как сказано на сайте авторов. При сотрудничестве (collaboration) две команды в течение оговорённого срока вместе ищут что-то новое. В режиме X-as-a-Service («как услуга») одна команда предоставляет результат, другая его потребляет, согласований почти нет. При фасилитации (facilitating) одна команда помогает другой и наставляет её.

Режим нужно выбирать намеренно. Выбору подходящих режимов посвящена седьмая глава книги. Сотрудничество дорого обходится обеим командам. Оно подходит для поиска нового и должно заканчиваться. Устойчивый сервис лучше потреблять, чем создавать вместе. Руководство IT Revolution из восьми шагов, опубликованное в мае 2021 года, советует сознательно ограничивать сотрудничество. Оно же советует пересматривать структуру по мере изменения работы.

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

Когнитивная нагрузка — объём сложности, который команда удерживает без ущерба для решений и скорости. По данным сайта Team Topologies, каждый новый инструмент, зона ответственности или предметная область её увеличивает. Перегруженная команда хуже принимает решения и работает медленнее.

Термин пришёл из педагогической психологии. Свеллер применил его в 1988 году к ограниченной рабочей памяти обучающегося. Свеллер, ван Мерриенбур (van Merriënboer) и Паас развили его в 1998 году. Пределы отдельного человека изучены хорошо, но оценки у исследователей различаются. Миллер в 1956 году оценил кратковременную память примерно в семь элементов. Коуэн в 2001 году обосновывал предел около четырёх смысловых блоков (chunks). Оглавление книги показывает, что авторы используют и число Данбара, рассуждая о масштабировании команд.

Нагрузку команды измерить сложнее, чем нагрузку человека. Проверенного инструмента для этого мы не нашли. Практический тест прост: спросите команду, где она чувствует перегрузку.

Закон Конвея и обратный манёвр Конвея

Закон Конвея гласит: системы копируют структуру коммуникаций организаций, которые их создают. Мелвин Конвей написал об этом в статье How Do Committees Invent? (Datamation, апрель 1968 года). По его словам, такие организации «вынуждены создавать проекты, являющиеся копиями структур коммуникаций» самой организации.

Вопрос о том, где делить систему, старше самого закона. Парнас в 1972 году сравнил два способа разбить одну программу на модули. Обратный манёвр Конвея (inverse Conway maneuver) разворачивает закон: команды проектируют так, чтобы система получилась нужной. Скелтон и Паис описывают его в статье ноября 2020 года, взятой из главы 2. По их описанию, манёвр меняет коммуникацию между командами до завершения ПО.

Что говорят исследования

Свидетельства в пользу идеи зеркалирования, на которой стоит закон Конвея, есть, но они неоднозначны. Маккормак, Болдуин и Руснак (MacCormack, Baldwin, Rusnak) сравнили парные продукты. Продукты слабо связанных организаций оказались более модульными. По одной из мер связности разница достигала восьми раз. Обзор 142 исследований, выполненный Колфером и Болдуином (Colfer, Baldwin), показал, что зеркалирование встречается часто, но не всегда. Открытые совместные проекты, в основном программные, его не подтвердили.

Другие работы связывают структуру с результатами.

• Нагаппан, Мёрфи и Базили (Nagappan, Murphy, Basili) построили набор метрик организационной сложности, включая число инженеров и глубину владения. Эти метрики предсказывали проблемные бинарные файлы Windows Vista точнее и полнее, чем метрики изменчивости кода, сложности и зависимостей.
• Гербслеб и Мокус (Herbsleb, Mockus) сообщили, что рабочие задачи, разнесённые по нескольким площадкам, занимали примерно в два с половиной раза больше времени, чем задачи на одной площадке.
• Катальдо и Гербслеб (Cataldo, Herbsleb) изучили два крупных проекта в двух компаниях. Разрыв между нужной и фактической координацией они связали с большим числом отказов. Более точное соответствие они связали с более высокой производительностью.
• Берд и коллеги (Bird и др.) обнаружили в Vista и Windows 7 связь между кодом, который меняют многие малоопытные участники, и числом дефектов. Это относится к тому, насколько ясно команда владеет своей частью.
• Гербслеб и Гринтер (Herbsleb, Grinter) выяснили на проекте с несколькими площадками, что после нарушения неформальной коммуникации больше всего проблем создавала интеграция, а не написание компонентов.

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

Применение в маркетинге и росте

Считайте этот раздел нашим расширением. Книга посвящена разработке ПО, и в маркетинге здесь ничего не проверялось.

Логика переносится туда, где в маркетинге есть передачи работы. Кампании нужны дизайн, текст, данные, юрист и разработчик по очереди. Это та же схема, что у изменения в ПО, которое ждёт три команды. Переход к потоковым командам здесь выглядит так. Выделяют потоки, например запуск в стране или lifecycle-программу. Каждый поток закрепляют за командой, которая отвечает за него целиком. Общая аналитика, трекинг и отчётность соответствуют платформенному типу.

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

Team Topologies определяет, кто владеет работой и как связаны команды. Как планировать работу, подход не говорит. Scrum и канбан работают внутри команды, когда её границы уже заданы. План Growth Lab начинается с карты потоков и их владельцев.

Как применять: Team Topologies: что это и 4 типа команд по шагам

1. Назовите потоки работы. Перечислите цепочки от внешней потребности до результата, который видит клиент, например подключение мерчанта или запись пациента. Выберите две-три самые важные. Результат: короткий список потоков.
2. Отнесите сегодняшние команды к четырём типам. Пометьте каждую команду как потоковую, обеспечивающую, команду сложной подсистемы или платформенную. Команды, которые не подходят ни под один тип, обычно образуют слой передач. Результат: карта недостающих типов.
3. Измерьте нагрузку на каждую команду. Посчитайте предметные области, инструменты и повторяющиеся запросы, которые несёт команда, и спросите, где она чувствует перегрузку. Результат: ранжированный список перегруженных команд.
4. Нарисуйте существующие взаимодействия. Для каждой пары зависимых команд укажите режим связи: сотрудничество, X-as-a-Service или фасилитация. Отметьте сотрудничество без срока окончания. Результат: карта взаимодействий «как есть».
5. Выберите целевую схему и сдвиньте одну границу. Решите, какие связи перейдут в режим X-as-a-Service и какие команды уменьшатся. Сначала измените одну границу и назначьте дату проверки. Результат: одно действующее изменение.
6. Пересматривайте взаимодействия. Проверьте, выполнила ли связь свою задачу. Сотрудничество, которое породило устойчивый сервис, переходит в режим X-as-a-Service. Результат: обновлённая карта и следующая граница.

Примеры

Маркетинговая организация финтеха

Иллюстративный пример, реальная компания не подразумевается. В платёжной компании отдельные команды ведут платный трафик, lifecycle-рассылки, контент и аналитику. Каждая кампания для новой страны требует всех четырёх. Компания считает потоком запуск в стране и создаёт потоковые команды по регионам. Аналитика становится платформенной командой: она предоставляет общий слой отчётности как услугу. Небольшая обеспечивающая команда обучает региональные команды планировать эксперименты.

Сеть клиник

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

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

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

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

Не применяйте, если одна небольшая команда удерживает в голове всю систему. Подход написан для разработки ПО и ИТ-поставки. Его перенос на маркетинг и другие функции — расширение, которое книга авторов не проверяет.

Частые ошибки

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

Вопросы и ответы

Какие четыре типа команд выделяет Team Topologies?

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

Что такое обратный манёвр Конвея?

Это проектирование команд так, чтобы организация создавала нужную структуру системы, а не ту, которую диктует действующая оргструктура. Скелтон и Паис описывают его как изменение коммуникации между командами до завершения ПО. Закон Конвея восходит к статье Мелвина Конвея 1968 года.

Что такое когнитивная нагрузка в Team Topologies?

Это объём сложности, который команда может удерживать и при этом работать нормально. По словам авторов, каждый добавленный инструмент, зона ответственности или предметная область её увеличивает. Перегруженная команда хуже принимает решения и работает медленнее. Термин пришёл из педагогической психологии: теорию когнитивной нагрузки предложил Джон Свеллер в 1988 году.

Какое издание книги Team Topologies читать?

Первое издание вышло в 2019 году в IT Revolution Press. IT Revolution указывает второе издание от 23 сентября 2025 года: в нём кейсы из нескольких отраслей и новое предисловие.

Источники

1. IT Revolution Press, Team Topologies (2019), excerpt with copyright page and table of contents
2. IT Revolution, Team Topologies, 2nd edition
3. Team Topologies, Key concepts
4. Team Topologies, Books
5. Skelton and Pais, Conway's law: critical for efficient team design in tech, IT Revolution, 2020
6. IT Revolution, Get started with Team Topologies in 8 steps, 2021
7. Conway, How do committees invent?, Datamation, 1968
8. MacCormack, Baldwin and Rusnak, Exploring the duality between product and organizational architectures, Research Policy, 2012
9. Colfer and Baldwin, The mirroring hypothesis: theory, evidence, and exceptions, Industrial and Corporate Change, 2016
10. Nagappan, Murphy and Basili, The influence of organizational structure on software quality, ICSE, 2008
11. Bird, Nagappan, Murphy, Gall and Devanbu, Don't touch my code! Examining the effects of ownership on software quality, ESEC/FSE, 2011
12. Herbsleb and Mockus, An empirical study of speed and communication in globally distributed software development, IEEE Transactions on Software Engineering, 2003
13. Herbsleb and Grinter, Splitting the organization and integrating the code: Conway's law revisited, ICSE, 1999
14. Cataldo and Herbsleb, Coordination breakdowns and their impact on development productivity and software failures, IEEE Transactions on Software Engineering, 2013
15. Parnas, On the criteria to be used in decomposing systems into modules, Communications of the ACM, 1972
16. Sweller, Cognitive load during problem solving: effects on learning, Cognitive Science, 1988
17. Sweller, van Merrienboer and Paas, Cognitive architecture and instructional design, Educational Psychology Review, 1998
18. Miller, The magical number seven, plus or minus two, Psychological Review, 1956
19. Cowan, The magical number 4 in short-term memory, Behavioral and Brain Sciences, 2001
20. Dunbar, Neocortex size as a constraint on group size in primates, Journal of Human Evolution, 1992

Обновлено 30 октября 2026

Илья ПушинОснователь PUSHERS & COO Fintech ServiceИлья строит операционные системы для растущих компаний в медицине и финтехе. С 2021 года руководит трансграничными платежами в ARBI Exchange, лицензированном обменнике в Таиланде, включая KYC, AML и выход в новые юрисдикции.Об автореLinkedIn