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 команды.