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

Первый выпуск Code of Leadership Александр записывает вдвоём с гостем, который всю карьеру держится где-то между продакт- и инженерным менеджментом в инфраструктурных и платформенных проектах. Станислав сразу объявляет себя скептиком: у руководителя мало свободного времени, а книги по IT подают материал слишком избыточно — хочется формата покороче, и разборы вроде этого дают главную ценность книги без её чтения. Саму книгу участники датируют 2019 годом, через год после Accelerate про ускорение поставки, а написали её два консультанта с фокусом на DevOps и инфраструктуру. Этот крен, предупреждает гость, будет чувствоваться весь разговор: про то, что предшествует поставке, — разработку и управление качеством — в книге почти ничего. Структура простая: три части по три главы, а всё содержание, шутят участники, сворачивается до одной картинки с четырьмя типами команд и тремя режимами взаимодействия.

Первая глава начинается с оргчарта: в хорошей компании его хотя бы нарисовали, а в средней структуру восстанавливают по подписям в Outlook. Он решает административные задачи вроде подписи отпуска, но не показывает, кто с кем работает, тем более что рядом живут проектная, продуктовая и юридическая структуры. Дальше идёт список того, что мешает потоку поставки: софт, когнитивный объём которого больше, чем команда способна удержать; путаница матричных структур; ежегодные болезненные реорганизации; зависимости, которые не убрать быстро; и как конечная точка — команды, чью мотивацию оргструктура уничтожила полностью. Наверху списка стоит закон Конвея, причём гость уточняет: сам Конвей говорил не про оргдизайн, а про структуру коммуникаций, которую в организациях пытаются загнать в границы оргюнитов. Иллюстрация — DBA: в разговоре звучит поправка, что отдельный человек с базой появляется не когда модель сложная, а когда база вообще существует, а дальше Станислав вспоминает архитектора-DBA, который сложные миграции готовил руками и один имел права их применять.

Перевернув структуру команд, авторы получают привычную трёхзвенную архитектуру, а затем предлагают обратный манёвр: если софт повторяет структуру коммуникаций, команды можно спроектировать так, чтобы на выходе вышли автономные сервисы — low coupling между командами и high cohesion внутри. Гость оговаривается: учат делать быстро и независимо, а не хорошо, — управление качеством, надёжность и безопасность остались за рамками, потому что книга писалась из другого времени. Теорию первой части замыкает число Данбара: глубокие доверительные отношения человек выстраивает примерно с пятью людьми, взаимное доверие — в группе человек на пятнадцать, и отсюда авторы выводят предельный размер команды, а участники по памяти — амазоновский принцип двух пицц и шутку про мясную начинку. Модель Такмана Станислав предлагает разбирать по фильмам Marvel о сборке супергероев, на что Александр отвечает, что нормирование там не работает: какие нормы, если в команде говорящий енот.

Вторая часть начинается с классической цепочки, где одни разрабатывают, другие тестируют, третьи эксплуатируют и контекст на каждой стрелке перекидывают через забор; авторы схлопывают четыре кубика в команду, выровненную по потоку ценности. Раньше её звали кросс-функциональной, но термин, по мнению гостя, не передаёт непрерывность потока; Александр возражает, что в такую команду можно собрать кого угодно — разработчика на C++, дизайнера и гончара, — и вопрос в том, вокруг какой идеи людей собрали. Картинка про масштаб и инженерную зрелость участников прямо сломала: подписи осей, судя по всему, перепутаны. Зрелость гость понимает как способность команд собирать временные коллаборации и полностью владеть своим продуктом, Александр — как практики поставки и эксплуатации; он же разбирает по кубикам авторов случай большого масштаба и слабых практик, где сложность прячут в платформу, и считает, что глубже, в устройство платформ и SRE-практик, авторам заходить не стоило.

Complicated-subsystem team держит сложный компонент, знание о котором не хочется размазывать: например, движок time-series-базы внутри системы управления телеметрией, где продуктовой команде важны сценарии про метрики, а не модель хранения байтов. Платформенная команда отдаёт не компонент, а сервисы — деплой, мониторинг, сборку — и внутри устроена как продуктовая, со своими пользователями-инженерами и их историями, тогда как компонентная команда не обязана быть самодостаточной и сопровождать написанное. Enabling team гость встретил под этим названием впервые: у него такие группы экспертов звались командой быстрого реагирования. Пример, который они видели вместе, — Java performance team: она приходит в продуктовую команду, вместе смотрит код, находит лишние сериализации, помогает настроить пулы потоков. Позволить себе такое, по опыту гостя, могут только очень крупные организации с сильным кор-инжинирингом; в стартапах и средних компаниях он enabling-команд не встречал. Отдельно гость признаётся, что мысленно раскладывал знакомые компании по этой модели: DevOps ложится хорошо, а безопасность — нет, как ни крути получается прежний силос из Security Operations Center, который приходит к командам с уязвимостями, и вопрос доверия к сдвигу влево оба оставляют для будущей дискуссии.

Режима взаимодействия три. Коллаборация — самый дорогой: границы ответственности размываются, людям приходится держать в голове соседний домен, и уместна она только коротким окном, пока две команды вместе побеждают когнитивную сложность, после чего должна прекратиться. X-as-a-Service требует зафиксированного контракта и каталога, откуда сервис можно запросить, а спотыкается о многопользовательность: команды без облачного опыта не проектируют модель тенантов и получают пересекающиеся данные, а с плохой изоляцией всё скатывается обратно в коллаборацию. Фасилитация — это enabling-команда, которая, как шутит Александр, причиняет добро; участники вспоминают архетип solver из книги Staff Engineer. Отсюда замечание гостя о слове evolve: движение идёт не к сложному, а к более дешёвым режимам. Полезными оба считают триггеры перемен, разбитые на когнитивную нагрузку, скорость поставки и лишние зависимости. Под конец оба подбивают впечатление: предельная модель выглядит стройной, а вот примеры от лица клиентов написаны генерально, без метрик и деталей, и подпираются ссылками — последние страниц пять-пятнадцать книги, по прикидке гостя, состоят из примечаний. Александр напоминает, что сам вытащил полезное в краткий пересказ на сорок минут чтения, и оба советуют начать с него.