1.2 Топологии команд и организационное проектирование

Обзор и мотивация

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

Топологии команд дают намеренный словарь для такого проектирования. Вместо того чтобы позволять структуре нарастать случайно через реорганизации и штатные расписания, зрелые организации выбирают типы команд и режимы взаимодействия сознательно и пересматривают этот выбор по мере развития системы и бизнеса. Цель состоит в том, чтобы удерживать когнитивную нагрузку каждой команды низкой, то есть общий объём, который команда должна держать в голове, чтобы быть эффективной, чтобы команды могли владеть своей предметной областью от начала до конца и поставлять ровный поток ценности, не ожидая постоянно других.

Для корпораций и государства эта дисциплина решающая. Большие организации естественно разрастаются в глубокие иерархии, общие сервисы с длинными очередями и цепочки передач, превращающие двухдневное изменение в двухмесячный проект. Государство добавляет границы закупок, подрядные команды и обязательные разделения обязанностей, ещё сильнее дробящие ответственность. Явное проектирование топологии это способ, которым такие организации возвращают себе поток: выравнивают команды по потокам ценности, строят платформы, снижающие когнитивную нагрузку, и выбирают шаблоны взаимодействия, делающие зависимости видимыми и намеренными, а не скрытыми и постоянными.

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

Закон Конвея неизбежен; проектируйте команды под ту программную инженерию, которую хотите («обратный манёвр»).
Оптимизируйте когнитивную нагрузку команды, а не максимальную загрузку отдельных людей.
Предпочитайте потоковые команды, владеющие срезом ценности от начала до конца.
Платформы существуют, чтобы снижать когнитивную нагрузку потоковых команд, а не чтобы стоять привратниками.
Делайте взаимодействия команд явными и немногочисленными: сотрудничество, «X как сервис» или содействие.
Минимизируйте зависимости; каждая передача между командами это очередь и риск.
Структура команд это живой проект, который должен развиваться вместе с системой и бизнесом.

Компромиссы: плюсы и минусы

Модель сквозных функций	Плюсы	Минусы
Централизованная (одна команда для всех)	Согласованность, глубокая экспертиза, ясные стандарты	Узкое место, очереди, потеря продуктового контекста
Федеративная («ступица и спицы», гильдии)	Балансирует согласованность и скорость; распространяет знания	Требует дисциплины координации; подотчётность может размываться
Встроенная (специалист в каждой команде)	Быстро, богато контекстом, высокая ответственность	Дублирование, несогласованность, трудно укомплектовать в масштабе

Тип команды	Лучше всего подходит для	Риск при злоупотреблении
Потоковая	Большинства поставок продуктов и сервисов	Нет; она должна преобладать
Платформенная	Снижения общей когнитивной нагрузки	Превращается в привратника в башне из слоновой кости
Поддерживающая	Временного распространения возможности	Превращается в постоянную зависимость
Сложных подсистем	По-настоящему глубоких специализированных областей	Служит оправданием для накопления обычной работы

Повторяющийся компромисс это автономия против согласованности. Полностью автономные команды двигаются быстро, но расходятся по стандартам, инструментам и уровню безопасности. Полностью централизованный контроль сохраняет согласованность, но душит поток. Хорошее проектирование топологии находит шов: автономия для потоковой поставки плюс тонкие центральные стандарты и платформы «проторённой дороги» (хорошо поддерживаемые инструменты по умолчанию, делающие соответствующий требованиям выбор лёгким) для того, что действительно должно быть согласованным.

Вопросы для обсуждения с командой

Какие конкретные сигналы подскажут, что когнитивная нагрузка команды слишком высока, до того как рухнет качество? «Ограничьте каждую команду областью, которую она освоит» легко сказать и трудно исполнить без свидетельств, потому что когнитивная нагрузка остаётся невидимой, пока не ухудшатся поставка и надёжность. Следите за измеримыми симптомами: число несвязанных сервисов или репозиториев команды, длительность адаптации, число предметных областей, между которыми один инженер переключается за неделю, и растущая частота инцидентов в уголках зоны ответственности команды. Для большой организации это важно, потому что перегруженные команды молча становятся узкими местами, которых не предскажет никакая схема реорганизации. Принесите эти цифры в обсуждение вместе с собственным ощущением команды того, что она может и чего не может удержать в голове. Если сигналы говорят о перегрузке, шаг состоит в том, чтобы сбросить недифференцирующую работу на платформу или поддерживающую команду, а не требовать большего героизма.
Стоит ли реорганизация здесь на самом деле связанных с ней потрясений или вы подпитываете пристрастие к реорганизациям? Перерисовка границ ради обратного манёвра Конвея мощная вещь, но каждая реорганизация также разрушает стабильность, нужную командам для сплочения, и обнуляет с трудом накопленные знания предметной области. Противоположные соображения: постоянный налог на координацию нынешней структуры против разовой стоимости и удара по морали от её изменения. В корпоративной и государственной среде границы закупок, подрядные команды и обязательные разделения обязанностей делают реорганизации медленнее и дороже, поэтому планка должна быть выше. Приведите свидетельства задержек из-за зависимостей: сколько инициатив заблокировано в ожидании другой команды и как долго. Реорганизуйте, когда ожидание структурное и большое, и сопротивляйтесь перетасовке, когда боль временная или дешевле решается вкладами inner-source и более ясными интерфейсами.
Какое событие заставит вас перейти между встроенной, федеративной и централизованной моделями для безопасности, данных и дизайна? Рекомендация главы в том, чтобы выбирать для каждой функции и каждого масштаба, а более трудная дисциплина заключается в том, чтобы заранее решить, какой рост или риск заставит пересмотреть выбор. Модель, подходящая для пятидесяти инженеров, может стать узким местом или катастрофой согласованности на пятистах, и корпорациям и государственным органам особенно нужно назвать стандарты, которые небольшое центральное ядро будет держать всегда. Принесите текущее время в очередях и разрывы согласованности для каждой функции: центральная команда безопасности с многонедельными очередями ревью сигнал к федерализации, а встроенные специалисты, производящие несовместимые модели данных, сигнал добавить центральное ядро стандартов. Определите триггер сейчас, например порог длины очереди или замечание аудита, чтобы перемена стала плановой эволюцией, а не реакцией на кризис. Ответ определит, куда вкладываться: в проторённые дороги и чемпионов или в центральную ступицу.
Как вы узнаете, действительно ли ваша платформенная команда снижает когнитивную нагрузку или тихо превращается в привратника? Платформа существует, чтобы сделать соответствующий требованиям, надёжный выбор лёгким через самообслуживание, и та же команда может дрейфовать в сторону навязывания инструментов, ручной проверки каждого запроса и добавления трения, которое она призвана была убрать. Для большой организации это различие решает, окупится ли вложение в платформу или она превратится в центральное узкое место, перед которым стоят в очереди все потоковые команды. Противоположные соображения: согласованность и контроль с одной стороны, автономия потребителей и поток с другой. Принесите свидетельства, которые узнает потребитель: сколько времени потоковой команде нужно, чтобы самостоятельно получить новую среду или конвейер без заявки, соотношение действий самообслуживания к действиям с участием человека и внедрение платформы, измеряемое командами, которые выбрали её, а не загнанными на неё. В корпоративной и государственной среде настаивайте, чтобы платформа автоматически порождала свидетельства для аудита и соответствия, а не через ручные шлюзы, ведь платформа, соблюдающая правила разделения обязанностей вставкой человека-ревьюера, воссоздала узкое место, которое её финансировали ради устранения.
Какие из ваших отношений между командами превратились в постоянное сотрудничество и что превратило бы каждое из них в чистый сервисный интерфейс или перерисованную границу? Режим сотрудничества предназначен быть интенсивным и временным, а совместная работа, которая никогда не кончается, обычно сигнал, что ответственность находится не там или что интерфейс между двумя командами так и не был сделан явным. В масштабе это важно, потому что неназванное постоянное сотрудничество то место, где прячется стоимость координации: оно не видно ни на одной оргсхеме, но облагает налогом каждое изменение, которого касаются две команды. Противоположные соображения: ценность исследования при близости против потока, который вы получаете, превратив отношения в контракт «X как сервис» с определённым интерфейсом или слив ответственность в одну команду. Принесите список пар команд, непрерывно сотрудничавших дольше квартала, изменения последних месяцев, потребовавшие обе команды, и можно ли записать стабильный интерфейс между ними. В корпоративном и государственном контекстах, где границы подрядчиков и лоты закупок могут на годы заморозить передачу, назовите, какие отношения можно преобразовать интерфейсом и вкладами inner-source, а какие закреплены контрактом и должны управляться как явные зависимости.
Когда поддерживающая команда помогает другой команде выстроить возможность, как вы узнаете, что она преуспела и может отойти, а не стать постоянной зависимостью? Поддерживающие команды призваны научить потоковую команду осваивать тестирование, безопасность или наблюдаемость и затем уйти, а без явного условия выхода отношения коучинга застывают в постоянную услугу, которую потоковая команда так и не усваивает. Для большой организации это разница между распространением возможности по десяткам команд и созданием нового общего узкого места, которое с каждым годом масштабируется всё хуже. Противоположные соображения: глубина и согласованность, которые даёт специалистская команда, против автономии и сквозной ответственности, которые вы пытаетесь заложить в потоковые команды. Принесите свидетельства передачи возможности: выполняет ли принимающая команда работу без присутствия поддерживающей, со сколькими командами одновременно связана фиксированная поддерживающая группа и насколько каждое участие затянулось сверх запланированной передачи. В корпоративной и государственной среде, где редкий специалистский навык может находиться за одной центральной командой или одним контрактом, заранее решите, как финансировать передачу возможностей и чемпионов, чтобы экспертиза растекалась по командам поставки, а не оставалась запертой за очередью, в которой должны ждать каждый аудит и релиз.

Взгляд по секторам

Стартап. При горстке инженеров и небольшом запасе времени правильная топология это единственная потоковая команда, владеющая всем продуктом, а дисциплина состоит в отказе создавать силосы раньше нужды. Сопротивляйтесь найму одинокого «DevOps» или «QA», который станет шлюзом; вплавьте эти навыки в единую команду как встроенную возможность. Заставьте закон Конвея работать на вас, сохраняя плоскую организацию, чтобы архитектура оставалась такой же простой и изменяемой, как команда.

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

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

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

Примеры

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

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

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

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

Игнорирование закона Конвея: проектирование архитектуры, которую оргструктура не может поставить.
Функциональные силосы: отдельные команды фронтенда, бэкенда, QA и эксплуатации, которым для любого изменения нужно координироваться.
Узкое место общего сервиса: центральная команда, за которой должен стоять в очереди каждый проект.
Платформа как привратник: платформенная команда, которая предписывает, а не служит, добавляя трение вместо его устранения.
Когнитивная перегрузка: команды, владеющие разросшимися несвязанными системами, которые не могут освоить.
Постоянное «сотрудничество»: две команды, вечно спутанные друг с другом, что сигнализирует о неверно проведённой границе.
Пристрастие к реорганизациям: постоянная перетасовка, разрушающая стабильность, нужную командам для сплочения.

Модель зрелости

Уровень 1, Начальный. Команды формируются случайно, по штатному расписанию или по унаследованной иерархии; никто не называет типы команд и режимы взаимодействия; функциональные силосы и узкие места общих сервисов повсюду, а зависимости скрыты, пока не заблокируют релиз.
Уровень 2, Развитие. Существуют некоторые потоковые команды и появляется первая платформа или попытка inner-source, но шаблон применяется неравномерно: несколько команд владеют своим срезом от начала до конца, а другие по-прежнему стоят в очередях к центральным функциям, и о когнитивной нагрузке говорят анекдотически, а не управляют ею.
Уровень 3, Стандартизация. Четыре типа команд и три режима взаимодействия задокументированы и намеренно используются по всей организации; платформы и inner-source снимают межкомандные зависимости; операционная модель для безопасности, данных и дизайна выбрана и записана, а новые команды формируются по этим стандартам, а не по импровизации.
Уровень 4, Управление. Топология измеряется и контролируется относительно базовых значений: команды отслеживают когнитивную нагрузку, задержки из-за зависимостей (инициативы, заблокированные в ожидании другой команды, и как долго), доли самообслуживания платформы и её внедрение, длительность режимов взаимодействия и метрики потока поставки вроде времени выполнения и частоты изменений. Пороги запускают действия, например длина очереди, вынуждающая функцию федерализироваться, или постоянное сотрудничество, сигнализирующее о неверной границе, так что решения опираются на свидетельства, а не на мнения.
Уровень 5, Оркестрация. Проектирование команд непрерывно улучшается и встроено в планирование архитектуры, продукта и рисков; организация перекраивает границы по мере развития системы и бизнеса, завершает поддерживающие участия, когда возможность передана, и перебалансирует вложения в платформу по мере смещения когнитивной нагрузки, сохраняя быстрый поток как адаптивное постоянное свойство, а не разовую реорганизацию.

Идеи для обсуждения

Сколько команд должно координироваться для типичного изменения и почему?
Какие из наших команд несут слишком большую когнитивную нагрузку и что могла бы снять платформа?
Где мы боремся с законом Конвея вместо перерисовки границ?
Служат ли наши платформенные команды потоковым командам или стоят у них привратниками?
Должны ли безопасность, данные и дизайн быть у нас сейчас централизованными, федеративными или встроенными?
Какие «временные» сотрудничества тихо стали постоянными зависимостями?

Главные выводы

Оргструктура определяет архитектуру и скорость поставки; проектируйте её намеренно.
Используйте четыре типа команд: потоковые по умолчанию, остальные в поддержку.
Применяйте обратный манёвр Конвея, чтобы желаемая архитектура стала лёгким путём.
Управляйте когнитивной нагрузкой; ограничивайте каждую команду областью, которую она может освоить.
Ограничивайте и называйте режимы взаимодействия команд; воспринимайте затянувшиеся зависимости как дефекты границ.
Выбирайте централизованные, федеративные или встроенные модели для сквозных функций по масштабу и используйте InnerSource для снятия очередей.

Источники и дополнительное чтение

Matthew Skelton and Manuel Pais, “Team Topologies: Organising Business and Technology Teams for Fast Flow”
Melvin Conway, “How Do Committees Invent?” (the origin of Conway’s Law)
Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate”
Will Larson, “An Elegant Puzzle: Systems of Engineering Management”
Sam Newman, “Building Microservices” (on aligning services to teams)
Danese Cooper and Klaas-Jan Stol, “Adopting InnerSource,” and the InnerSource Commons patterns
Frederick Brooks, “The Mythical Man-Month” (communication overhead)

1.2 Топологии команд и организационное проектирование

Обзор и мотивация

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

Рекомендации

Используйте четыре основных типа команд

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

Управляйте когнитивной нагрузкой явно

Выбирайте режимы взаимодействия намеренно

Выберите операционную модель для сквозных функций

Инвестируйте в inner-source