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

Проблема: почему реорганизации не помогают

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

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

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

Stream-aligned teams

Это основной тип, и если вы всё сделали правильно, то 80% и больше ваших команд должны быть именно такими. Stream-aligned team выстроена вокруг потока ценности — конкретного продукта, фичи, пользовательского сегмента или бизнес-домена. У такой команды есть всё необходимое для того, чтобы самостоятельно разрабатывать, тестировать и деплоить свои изменения, не дожидаясь помощи от других команд.

Самое важное тут — слово «aligned», выровненная. Команда не просто пишет код, она понимает свой бизнес-контекст и может принимать решения автономно. Если ваша команда каждый раз бегает согласовывать решения с тремя другими командами, она не stream-aligned, как бы вы её ни называли.

Platform teams

Платформенная команда существует ради одной цели — снизить когнитивную нагрузку stream-aligned команд. Она строит внутренние инструменты и сервисы, которые другие команды используют по модели self-service: CI/CD пайплайны, шаблоны инфраструктуры, observability стек, dev environments. Хорошая платформенная команда работает как внутренний продукт — у неё есть пользователи (другие разработчики), документация, SLA и обратная связь.

Типичная ошибка — делать платформу обязательной и навязывать её сверху вместо того, чтобы сделать её настолько удобной, что команды сами захотят ей пользоваться. Если ваши разработчики обходят платформу и делают всё руками, проблема не в разработчиках.

Enabling teams

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

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

Complicated-subsystem teams

Этот тип команд нужен, когда в системе есть компонент, требующий глубокой специализированной экспертизы — например, движок машинного обучения, видеокодек или криптографический модуль. Смысл выделения в том, чтобы эти сложные знания не размазывались по нескольким stream-aligned командам и не создавали каждой из них непосильную когнитивную нагрузку.

Complicated-subsystem teams встречаются реже всего, и это нормально. Если у вас таких команд больше, чем одна-две, возможно, вы неправильно декомпозировали систему или переоцениваете сложность подсистем.

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

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

Collaboration — две команды работают вместе над общей задачей, границы размыты. Это хорошо для фазы исследования и прототипирования, но плохо как постоянный режим, потому что увеличивает когнитивную нагрузку обеих команд.

X-as-a-Service — одна команда предоставляет другой сервис с чётким API и документацией. Минимальная когнитивная нагрузка, максимальная автономия. Это целевое состояние для взаимодействия с платформенными командами.

Facilitating — одна команда помогает другой, передаёт знания. Это основной режим работы enabling teams.

Как это связано с DX

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

Закон Конвея говорит нам, что архитектура системы неизбежно отражает структуру организации. Team Topologies — это, по сути, практическое руководство по применению Inverse Conway Maneuver: вы проектируете команды так, чтобы получить нужную архитектуру, а не наоборот.

Типичные ошибки при внедрении

Самая распространённая ошибка — переименовать существующие команды в терминах Team Topologies, ничего не меняя по существу. Назвать команду «stream-aligned» не делает её таковой, если у неё нет автономии и если она зависит от десяти других команд.

Вторая ошибка — создать платформенную команду слишком рано, когда ещё непонятно, какие именно инструменты нужны. Платформа должна вырастать из реальных потребностей stream-aligned команд, а не из представлений менеджмента о том, как должно быть.

Третья — забыть про эволюцию. Скелтон и Пайс подчёркивают, что типы команд и модели взаимодействия должны меняться со временем. Команда, которая начинала как enabling, может стать частью платформы, а complicated-subsystem может упроститься настолько, что её знания можно будет влить в stream-aligned команды.