Как вы управляли зависимостью от другой команды, которая блокировала ваш результат?

3. Параллельная работа и заглушки

// Mock API для параллельной разработки пока зависимость не готова
const getPartnerData = async (id: string) => {
  if (process.env.USE_MOCK === 'true') {
    return mockPartnerData[id]; // локальная заглушка
  }
  return fetch(`/api/partner/${id}`).then(r => r.json());
};

Команда продолжает разработку и тестирование на моках; интеграция вставляется позже без перестройки логики.

Суть вопроса

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

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

1. Визуализация зависимостей заранее

На planning-этапе явно строить dependency map: какие команды блокируют вас и когда. Инструменты: Jira dependency links, Miro-диаграмма, таблица в Confluence с именами владельцев и датами нужных deliverables.

2. SLA-соглашение

Договориться с блокирующей командой о явном SLA: когда именно будет готов API/интеграция/данные. Устная договорённость не считается — нужен тикет или письменное подтверждение.

4. Конкретный пример по STAR

Ситуация: наша команда строила checkout-флоу, зависящий от команды платёжного шлюза, которая должна была предоставить новый webhook API к 3-й неделе спринта. На 2-й неделе стало ясно, что у них сменился приоритет и дедлайн сдвинулся на 2 недели.

Действия:

• Немедленно встретился с PM блокирующей команды — понял причину: их спринт занят критическим багом production. Конфликта нет, но наш дедлайн в риске.
• Договорились о минимальном interim deliverable: не полный API, а только эндпоинт подтверждения платежа — 3 дня работы вместо 2 недель.
• Разработали mock-сервер на основе согласованного контракта OpenAPI, продолжили разработку.
• Эскалировали своему PM для прозрачности — не для давления на другую команду, а чтобы спонсор был в курсе риска.

Результат: interim deliverable получили на 5-й день, полная интеграция — через 10 дней. Наш дедлайн выдержан с 3-дневным буфером.

5. Эскалация как последний, не первый инструмент

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

Подводные камни

• Ждать без действий, надеясь что «они сделают в срок» — узнаёте о задержке слишком поздно для манёвра.
• Публично критиковать блокирующую команду — создаёт враждебность, затрудняет сотрудничество в будущем.
• Не иметь contract-first подхода (OpenAPI/Protobuf) — параллельная разработка без чёткого контракта приводит к несовместимости при интеграции.
• Принимать «скоро будет готово» без конкретной даты — измеряйте статус по артефактам, не по обещаниям.
• Не информировать свою команду о задержке — разработчики планируют работу с учётом несуществующей зависимости.
• Использовать mock до production без feature flag — мок может попасть в прод случайно.
• Не документировать согласованный API-контракт — после интеграции команды расходятся во мнениях о поведении.
• Не планировать регрессионное тестирование после замены мока на реальный API — различия в edge cases обнаруживаются в production.

• Ждать молча, пока другая команда освободится.
• Эскалировать без попытки договориться о контракте.
• Не иметь плана B.

• Управляет dependencies явно.
• Работает через договорённости и интерфейсы.
• Снижает coupling между командами.