Перейти к содержимому
    Оглавление · Тема 2

    Обновлено: 13 августа 2026 г. в 00:00

    Team Topologies (short summary)

    hard

    Team Topologies

    Авторы: Matthew Skelton, Manuel Pais
    Издательство: IT Revolution
    Объем: 2019

    Первоисточник: сама работа

    Обзор 3 частей: teams as the means of delivery, топологии для flow и эволюция взаимодействий команд.

    Team Topologies — оригинальная обложкаОригинал

    Источник

    Teams as the means of delivery

    Обзор 1-й части Team Topologies: почему команда становится единицей поставки.

    Перейти на сайт

    Team Topologies (short summary)

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

    Ниже - сжатая карта трех ключевых частей: команда как единица поставки, типы команд и эволюция взаимодействий.

    Часть 1: Team as the means of delivery

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

    Ограничение когнитивной нагрузки - ключ к производительности. Если команда вынуждена держать в голове слишком много доменов и зависимостей, поток ломается.

    Ключевые принципы

    Команда - базовая единица доставки ценности, а не отдельный инженер.

    Стабильные долгоживущие команды почти всегда эффективнее проектных сборок.

    Чем меньше handoff между командами, тем выше скорость и предсказуемость.

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

    Практический вывод

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

    См. также

    Закон Конвея

    Почему структура коммуникаций напрямую отражается в архитектуре систем.

    Читать обзор

    Размер команды и когнитивная нагрузка

    Команда

    Обычно 5-8 человек, в высокодоверительных средах до 15.

    Семья / tribe

    Группировка нескольких команд, как правило до 50 (иногда до 150).

    Дивизион / stream

    Контур из 150-500 человек с формальными границами и интерфейсами.

    Числа Донбара

    Диаграмма ДонбараКонцентрические круги показывают когнитивные уровни отношений и типичные размеры групп: около 5, 15, 50, 150 и 500.~5~15~50~150~500close personal relationshipsdeep trustmutual trustcan remember

    Модель Такмана

    Модель развития команды по ТакмануКривая эффективности команды во времени: forming, storming, norming и performing.EffectivenessTimeformingstormingnormingperforming

    Источник

    Team topologies that work for flow

    Обзор 2-й части Team Topologies: четыре типа команд и их назначение.

    Перейти на сайт

    Часть 2: Типы команд

    Вместо случайного формирования команд авторы предлагают устойчивые роли. Это позволяет осознанно распределять ответственность и снижать системную перегрузку в организации.

    Карта базовых топологий

    Визуализация четырех типов команд Team TopologiesStream-aligned команда в центре потока, Platform как базовый слой, Enabling и Complicated Subsystem как поддерживающие контуры.Platform teamStream-aligned teamEnablingteamComplicatedsubsystem

    Stream-aligned

    Владеют потоком ценности в конкретном домене и сами доводят изменения до продакшена.

    Platform

    Строят внутренние сервисы и self-service инструменты, чтобы ускорять продуктовые команды.

    Enabling

    Помогают другим командам освоить новые практики и технологии, убирают блокировки.

    Complicated Subsystem

    Берут на себя узкие и сложные подсистемы, где нужна высокая экспертная глубина.

    Источник

    Evolving team interactions

    Обзор 3-й части Team Topologies: модели взаимодействий между командами.

    Перейти на сайт

    Часть 3: Эволюция взаимодействий

    Collaboration

    Временная плотная совместная работа над новой или особенно сложной задачей.

    X-as-a-Service

    Поставщик дает понятный сервисный интерфейс, а потребители используют его как продукт.

    Facilitating

    Одна команда помогает другой поднять практики, процессы или инженерную зрелость.

    Как менять режимы по мере зрелости

    На старте чаще нужен режим collaboration для быстрых открытий. После стабилизации решений выгоднее переходить к X-as-a-Service. Facilitating подключается точечно, когда требуется прокачка практик или переход на новые технологии.

    Антипаттерны

    Длительная collaboration как постоянный режим вместо временного ускорителя.

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

    Слишком широкие зоны ответственности и постоянный контекст-свитчинг.

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

    Итоги

    Оргструктура должна поддерживать поток поставки, а не мешать ему.

    Тип команды выбирают по когнитивной нагрузке и контексту, а не по моде.

    Режимы взаимодействия должны эволюционировать вместе с продуктом.

    Постоянная диагностика bottleneck - ключевая часть лидерской работы.

    Трекинг прохождения выключен. Включите его в настройках.

    Доказательство обучения

    Чтение — только начало. Перенесите идею в рабочий эксперимент и разберите результат.

    Локальная карта знаний

    Небольшое типизированное окружение вместо графа всего каталога.