Управление зависимостями между командами

Ждём другую команду

Разработчик закончил фичу, отправил PR, тесты зелёные, продакт доволен. Осталось задеплоить. Но для деплоя нужен новый endpoint от платформенной команды, а у них спринт расписан на три недели вперёд. Фича лежит в ветке и ждёт. Через три недели контекст потерян, надо ребейзить, прогонять тесты заново, вспоминать детали. Помножьте это на десять команд и двадцать фич — получится организация, в которой все работают, но ничего не выпускается.

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

Типы зависимостей

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

Blocking dependencies. Самый разрушительный тип. Команда A не двигается, пока команда B не сделает свою часть. Работа стоит, контекст теряется, мотивация падает. Каждая блокирующая зависимость порождает задержку и переключение контекста: разработчик откладывает заблокированную задачу, берёт что-то другое, потом возвращается обратно.

Coupling dependencies. Команды могут работать параллельно, но обязаны согласовывать интерфейсы и контракты. Менее разрушительные, чем блокирующие, но требуют постоянной коммуникации и порождают extraneous-нагрузку.

Knowledge dependencies. У одной команды есть экспертиза, нужная другой. Формально работа не блокирована, но без консультации с экспертами команда рискует принять неверное решение или потратить время на изобретение того, что уже есть.

X-as-a-Service как целевое состояние

Самый масштабируемый способ управления зависимостями — перевод взаимодействия в режим X-as-a-Service. Одна команда предоставляет сервис через чётко определённый интерфейс, другая потребляет его без прямого взаимодействия с людьми. Документация, API, примеры использования — всё доступно в self-service.

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

Переход к X-as-a-Service требует инвестиций: спроектировать API, написать документацию, построить автоматизацию, заложить golden paths для типовых сценариев. Каждая такая инвестиция окупается многократно, потому что устраняет повторяющиеся блокировки для десятков команд.

API-first подход к межкомандному взаимодействию

Закон Конвея утверждает, что системная архитектура отражает структуру коммуникаций в организации. Тесно связанные сервисы вынуждают команды постоянно общаться. API-first переворачивает эту логику: команды сначала договариваются о контрактах (API-спецификация, формат событий, SLA), а потом работают автономно, каждая внутри своих границ.

Контракты помогают формализовать инструменты: OpenAPI для REST, Protocol Buffers для gRPC, AsyncAPI для событийных архитектур. Контрактное тестирование через Pact автоматически проверяет, что обе стороны соблюдают договорённости, без ручной координации.

Принцип: контракт определяется совместно, реализация — каждой командой самостоятельно. Это сводит coupling dependencies к минимуму и развязывает команды по деплоям.

Как обнаружить проблемные зависимости

Зависимости часто скрыты. Команда может не осознавать, что тратит 30% времени на координацию с другими, потому что для неё это «просто работа». Несколько способов вытащить зависимости на свет.

Dependency mapping. IT Revolution описывает практику визуализации: каждая команда рисует карту «от кого зависим» и «кто зависит от нас». Сводная картинка показывает узлы с высокой связностью.

Team API. Каждая команда публикует описание своего интерфейса: что предоставляет, как обращаться, какие SLA. Формализация делает зависимости явными.