Границы команд: зависимости, интерфейсы и когнитивная нагрузка

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

Это диагностически важная картинка, потому что она отсекает целый класс неверных объяснений. Если работы одиннадцать часов, а календаря четырнадцать дней, то ни мотивация, ни грейды, ни «давайте лучше оценивать» ничего не изменят. Даже если команда станет вдвое быстрее писать код, срок сократится на пять часов из четырнадцати дней. Проблема не внутри команды — она на границах.

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

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

Что такое граница команды и почему их четыре

«Граница команды» звучит как одна линия, но на практике это четыре разные линии, и беда начинается там, где они не совпадают.

Рабочий тест на здоровье границ ровно один: сколько чужих согласий нужно, чтобы типовое изменение доехало до продакшена. Не «сложное» и не «архитектурное» — типовое, то, что команда делает еженедельно. Ноль — граница проведена по потоку работы. Один — терпимо. Три — команда фактически не автономна, чем бы это ни называлось в оргструктуре.

Худший случай — когда границы расходятся: дежурство на вас, владение кодом на других, право выката у третьих. У команды есть вся боль и ни одного рычага. Это не повод для героизма, а материал для разговора наверх (Вверх по цепочке), и цифры из первой картинки — лучший аргумент, который у вас есть.

Закон Конвея: что действительно известно

Формулировка Мелвина Конвея 1968 года: организация проектирует системы, копирующие структуру её коммуникаций (How Do Committees Invent?). Это была не теорема, а наблюдение — но, в отличие от большей части управленческого фольклора, у него есть эмпирическая проверка.

• MacCormack, Baldwin, Rusnak (2012) сравнили пары продуктов, решающих одну задачу, но сделанных по-разному организованными командами: продукты из компаний с плотной колокацией оказались значимо более связными, из распределённых open source сообществ — более модульными (Exploring the Duality Between Product and Organizational Architectures, Research Policy 41(8)). Это самая прямая проверка гипотезы зеркалирования, и она в пользу Конвея.
• Nagappan, Murphy, Basili (2008) на данных Windows Vista показали, что организационные метрики — сколько инженеров трогало компонент, сколько бывших владельцев, насколько раздроблено владение по оргструктуре — предсказывают склонность компонента к дефектам точнее, чем метрики кода и покрытия (The Influence of Organizational Structure on Software Quality, ICSE).
• Herbsleb и Mockus (2003) на данных Lucent: рабочие элементы, требующие людей с разных площадок, закрывались примерно в 2,5 раза дольше при сопоставимом объёме работы (An Empirical Study of Speed and Communication in Globally Distributed Software Development, IEEE TSE 29(6)). Причина не в часовых поясах как таковых, а в стоимости установления контакта.
• Cataldo и соавторы (2008) ввели socio-technical congruence: чем лучше фактические коммуникации совпадают с техническими зависимостями, тем быстрее закрываются задачи.
• DORA много лет фиксирует «слабо связанную архитектуру и команды» как один из сильнейших предикторов скорости и стабильности доставки (dora.dev).

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

Держится один вывод: граница между командами материализуется в коде и в сроках. Проводя линию между людьми, вы одновременно проводите её в системе — и там она переживёт текущую оргструктуру.

Когнитивная нагрузка: чем она на самом деле измеряется

Термин пришёл из работ Джона Свеллера по педагогической психологии (Cognitive Load During Problem Solving, Cognitive Science 12(2), 1988): нагрузка бывает внутренней — сложность самого материала, внешней — от плохой подачи, и полезной — на построение схем в голове.

Честно о переносе. Свеллер изучал обучение отдельных людей, а не команды. Перенос на «сколько доменов держит команда» популяризован книгой Team Topologies (Skelton, Pais, 2019, teamtopologies.com) и никаким контролируемым исследованием не подтверждён. Это удобная метафора, которая даёт язык и упражнение. Пользоваться ей стоит как термометром, а не как формулой.

Практическая ценность разделения в том, что три ветки лечатся по-разному. Внешнюю сложность убирают инструментами и автоматизацией — это дёшево и почти всегда окупается (см. Технический долг). Прерывания лечат интерфейсом и ротацией дежурного. А вот внутреннюю сложность нельзя оптимизировать — только передать или удалить, и это уже не техническое решение, а переговоры.

Упражнение, которое показывает перегруз за час

Соберите команду и заполните таблицу. Строки — зоны ответственности (домен, сервис, легаси-кусок, интеграция, дежурство). Колонки:

1. Кто может починить это ночью один? Пишите имена, а не «команда».
2. Когда мы последний раз меняли это осмысленно, а не под давлением?
3. Сколько вопросов в неделю приходит извне по этой зоне?
4. Что случится, если мы перестанем это трогать на квартал?

Диагнозы читаются прямо из таблицы:

• В колонке 1 одно имя у трёх строк подряд — у вас не команда, а три человека-одиночки с общим чатом. Это делегирование и ротация, а не топология.
• Строка, где колонка 1 пустая, — зона без носителей. Она не исчезнет, она рванёт.
• Строки с высоким значением в колонке 3 и низким в колонке 2 — это чужая работа, которую вы обслуживаете. Кандидат на интерфейс или на передачу.
• Если строк больше пяти-шести при команде в пять человек — дальше можно не считать. Это не результат исследования, а порог, за которым в отраслевой практике начинаются одинаковые симптомы: решения откладываются, ревью формальны, на вопрос «кто это знает» звучит одно имя.

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

Зависимости: их шесть типов, и лечатся они по-разному

Слово «зависимость» склеивает вещи, у которых нет ничего общего, кроме симптома «мы ждём».

Дальше — иерархия ответов, от самого дешёвого к самому дорогому. Порядок важнее списка: командам свойственно сразу прыгать на последний пункт.

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

Что чинить в первую очередь

Не все зависимости стоит трогать. Разовое ожидание в две недели дешевле, чем перестройка владения кодом; ежедневное ожидание в час — дороже.

Левый верхний угол — самый спорный. Редкие, но дорогие пересечения (безопасность, юристы, внешний аудит) чинить обычно не в вашей власти, и правильный ход — не бороться, а встроить в план заранее, как известный срок, а не как сюрприз (см. Планирование и оценки).

Интерфейс команды: как выглядит и что даёт

«Интерфейс команды» звучит бюрократично ровно до первого раза, когда вы посчитаете, сколько времени команда тратит на ответы в чатах. Это не документ ради документа, а способ сделать две вещи: убрать вопрос «а к кому идти» и превратить невидимую очередь в видимую.

# team-api.yaml — лежит в репозитории команды, ссылка закреплена в общем канале
team: payments
mission: "Приём платежей и сверка. Отвечаем за успешность оплат и точность расчётов."

owns:                       # где мы принимаем решения и кого будят ночью
  - service: payment-gateway
    oncall: payments
  - service: reconciliation
    oncall: payments
not_owns:                   # частая причина недоразумений: пишем явно
  - "Витрина тарифов — это команда billing-ui"
  - "Антифрод — команда risk, мы только вызываем их API"

how_to_ask:
  bug_in_prod:              # деградация оплат
    channel: "#payments-oncall"
    response_time: "15 минут в рабочее время, 30 минут ночью"
  question:
    channel: "#payments-help"
    response_time: "1 рабочий день"
    before_asking: "docs/faq.md — закрывает примерно половину вопросов"
  feature_request:
    where: "тикет в очередь payments-intake"
    review: "разбираем по вторникам, ответ да/нет/когда — в тот же день"
  escalation: "тимлид payments, при отсутствии ответа сутки — руководитель направления"

self_service:               # то, за чем не нужно приходить к нам вообще
  - "Тестовые карты и песочница: docs/sandbox.md"
  - "Права на чтение логов: заявка в IdM, шаблон payments-read"

commitments:
  - "Ломающие изменения API — уведомление за 30 дней, две версии одновременно"
  - "Ответ на запрос ревью в наших репозиториях — 1 рабочий день"
we_expect:
  - "Воспроизведение и request-id в обращении об ошибке"

Три вещи делают такой файл рабочим, а не мёртвым. Сроки вместо намерений: «постараемся ответить быстро» — не интерфейс, а срок ответа — обязательство, нарушение которого заметно. Раздел not_owns: половина межкомандных конфликтов — не про то, кто должен сделать, а про то, что обе стороны были уверены, что делает другая. Самообслуживание: каждая строка там — вопрос, который больше не придёт в чат; это единственная часть файла, которая уменьшает нагрузку, а не перераспределяет её.

Что происходит без интерфейса и с ним:

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

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

Режимы взаимодействия и их срок годности

Team Topologies даёт три режима работы двух команд: сотрудничество, «как сервис» и содействие. Ценность здесь — не в классификации, а в утверждении, что режим должен меняться со временем.

Правила, которые из этого следуют, проверяемы:

• У сотрудничества всегда есть дата окончания. Нет даты — вы получите состояние «скрытая постоянная связка»: две команды в структуре, одна в реальности, зато с двойными накладными расходами на согласование. Нарушение видно на любой ретроспективе: «мы всё ещё синхронизируемся с ними каждый день, уже год».
• Сотрудничество дорогое. Оно временно повышает когнитивную нагрузку обеих команд — и это нормальная плата за неизвестную область, но не за постоянную работу.
• Режим «как сервис» требует, чтобы кто-то оплатил интерфейс. Если у сервисной команды нет времени на самообслуживание, режим фиктивен, и все всё равно ходят ногами.

Полный набор из четырёх типов команд (поток создания ценности, платформа, включающая, сложная подсистема) полезен как словарь: он позволяет спросить «мы вообще какая команда?» и получить неудобный ответ вроде «мы платформа, которую все считают потоковой». Но это модель без эмпирической проверки, и карго-культ распознаётся легко: команды переименовали, взаимодействия не изменились. История «модели Spotify» — ровно об этом: сама компания позже признавала, что описанная в докладах структура не работала так, как её копировали (Failed #SquadGoals); про масштабирование фреймворков — в scrum-master.

Размер команды и число связей

Внутри команды число каналов общения растёт как n*(n-1)/2: пять человек — десять пар, девять — тридцать шесть. Отсюда закон Брукса (The Mythical Man-Month, 1975): добавление людей в опаздывающий проект задерживает его ещё сильнее.

Дальше начинается фольклор, и это надо назвать своими именами. «Две пиццы» — эвристика Amazon, никем не проверявшаяся. «Число Данбара» в применении к компаниям — экстраполяция приматологической регрессии, которую сами исследователи не подтверждают: попытка воспроизвести расчёт дала доверительные интервалы такой ширины, что говорить о конкретном числе бессмысленно (Lindenfors et al., 2021, Biology Letters).

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

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

Что ломается чаще всего

Деление по слоям. Фронтенд, бэкенд и «команда БД» — структура, при которой любая фича требует трёх команд, трёх бэклогов и трёх приоритетов. Соблазн понятен: так проще управлять компетенциями. Цена: у каждой фичи минимум два пересечения границы, что по картинке из начала главы означает недели ожидания. Признак, что вы в этом: команда честно закрыла свою часть и ждёт, и все считают это нормальным.

Общий репозиторий без владельцев. Формально «код общий», фактически ревью делает тот, кто согласился. Работы Nagappan и соавторов показывают ровно это: раздробленное владение коррелирует с дефектностью. Лечится не запретами, а явной парой «модуль — владелец» и inner source: чужие PR принимаются, но у модуля есть тот, кто отвечает за него.

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

Реорг как рефлекс. Заметив зависимость, руководители часто хотят переставить людей. Иногда это верно, но у перестановки есть цена, о которой не говорят: команда теряет накопленный контекст, новые люди месяц входят в домен, метрики просаживаются на квартал. Честное правило: реорг — самый дорогой инструмент, применяйте его, когда исчерпаны интерфейс, самообслуживание и передача владения.

Границы, нарисованные под текущих людей. «Здесь будет команда Пети, потому что Петя это знает» — решение, которое через год превращается в систему, спроектированную вокруг чьего-то отпуска. Границы стоит проводить по доменам, а людей назначать после.

Чего тимлид не может — и что всё-таки может

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

Из этого следует не самая приятная, но полезная тактика: сначала измерьте, потом просите. Просьба «дайте нам ещё человека» проигрывает почти всегда. Аргумент «за квартал 60 % наших изменений пересекали границу с командой X, среднее ожидание на этой границе — 4 дня, это 30 рабочих дней команды; предлагаю передать им зону Y вместе с дежурством» — принципиально другой разговор, потому что он про деньги и про конкретное решение.

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

Как измерять границы

Метрики здесь нужны не для отчётности, а чтобы разговор о границах перестал быть спором о вкусах. Ни одна из них не годится как цель — только как термометр.

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

Связь с архитектурой

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

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

Мини-итог

• Границ у команды четыре — владение кодом, ответственность за результат, эксплуатация, право выката. Боль возникает там, где они не совпадают.
• Первый замер — не опрос, а восстановление пути одного изменения по часам: работа против календаря почти всегда показывает, что проблема снаружи команды.
• Про закон Конвея есть эмпирика (MacCormack 2012, Nagappan 2008, Herbsleb 2003) — она поддерживает связь оргструктуры с архитектурой и сроками, но не даёт рецептов.
• Когнитивная нагрузка — рабочая метафора без доказательной базы. Считайте зоны и носителей; перегруз проявляется как поверхностные ревью и отложенные решения, а не как «не успеваем».
• У зависимостей шесть типов и одна иерархия ответов: устранить → самообслуживание → контракт → временное сотрудничество → вопрос об оргструктуре. Встреча синхронизации — не ответ, а обезболивание.
• Интерфейс команды работает, только если в нём есть сроки, раздел «чем мы не владеем» и растущий раздел самообслуживания. У сотрудничества двух команд обязана быть дата окончания.
• Реорг — самый дорогой инструмент из доступных, и обычно не ваш. Дешёвые вы можете применить сами уже на этой неделе.

Источники

• Conway, M. E. How Do Committees Invent?, Datamation, 1968 — исходная формулировка.
• MacCormack, A., Baldwin, C., Rusnak, J. Exploring the duality between product and organizational architectures: A test of the mirroring hypothesis, Research Policy 41(8), 2012.
• Nagappan, N., Murphy, B., Basili, V. The Influence of Organizational Structure on Software Quality: An Empirical Case Study, ICSE 2008.
• Herbsleb, J. D., Mockus, A. An Empirical Study of Speed and Communication in Globally Distributed Software Development, IEEE TSE 29(6), 2003.
• Cataldo, M., Herbsleb, J. D., Carley, K. M. Socio-technical congruence, ESEM 2008.
• Sweller, J. Cognitive Load During Problem Solving, Cognitive Science 12(2), 1988 — исходная теория, про обучение людей, а не команд.
• Skelton, M., Pais, M. Team Topologies, IT Revolution, 2019 — словарь и модель без эмпирической проверки.
• Forsgren, N., Humble, J., Kim, G. Accelerate, 2018 и dora.dev — слабо связанные архитектура и команды как предиктор скорости.
• Brooks, F. P. The Mythical Man-Month, 1975 — рост числа связей и закон Брукса.
• Lindenfors, P., Wartel, A., Lind, J. ‘Dunbar’s number’ deconstructed, Biology Letters 17(5), 2021.
• Reinertsen, D. The Principles of Product Development Flow, 2009 — очереди и стоимость ожидания.
• Lee, J. Failed #SquadGoals — почему «модель Spotify» не работала так, как её копировали.

Что дальше

Границы, переданные зоны и очереди на ревью — это ещё и люди, которые считают, что вы забираете их работу или сваливаете на них своё легаси. Разговор о границах почти всегда превращается в разговор с конкретным человеком, у которого другое мнение и своя правота.

Конфликты и трудные разговоры.