Управление зависимостями — это система, которая делает видимыми и управляемыми связи «кто от кого ждёт результат», чтобы проект не умирал от сюрпризов на интеграции; на зрелом процессе вы снижаете срывы сроков на уровне недель уже за 4–8 недель внедрения, но ключевой риск — превратить это в бюрократию без владельцев и решений.

Почему зависимостей боятся даже опытные ПМы

Масштабный проект ломается редко из‑за «плохой разработки». Чаще — из‑за идеального шторма: одна команда ждёт API, другая — доступы, третья — решение безопасности, и всё это не считается «задачей» и поэтому не происходит. Зависимости живут между бэклогами, между Jira‑проектами, между начальниками. И обожают фразу «мы думали, они уже сделали».

Самая дорогая зависимость — та, которая всплывает на интеграции. Она выглядит как: «А у вас формат даты другой», «А нам нельзя в прод без скана», «А доступов нет, но вы же знали». Хорошая новость: зависимостями можно управлять так же прагматично, как рисками — с владельцами, SLA, триажем и прозрачной доской решений.

Что такое зависимость (чтобы не спорить на созвонах)

Рабочее определение

Зависимость — это внешний по отношению к команде результат (артефакт, решение, доступ, изменение), необходимый для выполнения работы в срок и с нужным качеством.

Классификация (упрощает triage)

• Технические: API/контракт, схема БД, инфраструктура, интеграции, окружения.
• Продуктовые: требования, приоритеты, UX, legal/комплаенс.
• Орг/процессные: доступы, закупки, найм, решение архитекткомитета.
• Внешние: подрядчик, регулятор, партнёр, AppStore/Google Play.

Подводный камень: путать «зависимость» и «риск». Риск — вероятность и влияние. Зависимость — конкретный чей-то deliverable, который вам нужен.

Процесс управления зависимостями: минимально жизнеспособная версия (MVP)

0) Договоритесь о правилах игры (30–60 минут)

• Где живёт реестр зависимостей (Jira/Confluence/Sheets) и кто его ведёт.
• Как выглядит карточка зависимости (поля ниже).
• Как часто триаж (обычно 2 раза в неделю) и кто обязателен.
• Эскалация: через сколько дней просрочки и на какой уровень.

Вывод: без общего «вот так мы работаем» вы получите 14 разных трактовок и ноль исполнения.

1) Постройте карту критического пути через зависимости

В масштабе вам не нужен идеальный план на год. Нужна карта: какие результаты критичны для ближайших 4–8 недель, и кто их должен принести. Начните от ближайших интеграционных точек и релизных ворот (security review, UAT, миграция, cutover).

Типичная ошибка: собирать зависимости «вообще все на свете». Тогда вы утонете. Начинайте с критических.

2) Создайте реестр зависимостей (и сделайте его пригодным к действиям)

Карточка зависимости должна отвечать на вопрос: «Кто? Что? Когда? Чем подтверждаем? Что если не успеют?»

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

3) Введите triage: коротко, регулярно, с решениями

Собрание по зависимостям — не стендап и не терапия. Это диспетчерская.

1. Открываем список P0/P1 (не всё подряд).
2. По каждой: что изменилось с прошлого раза, какие блокеры, что делаем до следующей точки.
3. Если нет движения — эскалируем (сразу, при всех).
4. Фиксируем решение и следующую дату проверки.

Важная механика: зависимость обязана иметь следующий шаг (next action) и дату. Иначе это просто грусть в таблице.

4) Настройте SLA и правила эскалации (чтобы «пинги» не превращались в хобби)

• P0: блокирует релиз/критический путь. Обновление статуса ежедневно, эскалация через 48 часов без прогресса.
• P1: влияет на срок итерации/интеграции. Статус 2 раза в неделю, эскалация через 5 рабочих дней.
• P2: полезно, но есть обход. Проверка раз в неделю.

Типичная ошибка: эскалировать «потому что бесит». Эскалировать нужно по правилам, иначе вы сожжёте доверие и получите пассивную агрессию вместо результата.

Инструменты и артефакты: что реально работает в энтерпрайзе

Dependency board (канбан зависимостей)

Колонки: Draft → Confirmed → In progress → Delivered → Accepted, плюс отдельная дорожка At risk. Смысл простой: зависимость «закрыта» только когда потребитель её принял (accepted), а не когда поставщик сказал «готово».

Контрактное мышление (особенно для API и данных)

• OpenAPI/AsyncAPI как источник правды.
• Consumer-driven contract tests (потребитель задаёт ожидания).
• Версионирование, депрекации, сроки поддержки.

Подводный камень: «скинули в чат пример JSON». Это не контракт, это фанфик.

Интеграционные «ворота» (gates) по календарю

Поставьте фиксированные события: demo интеграции раз в 2 недели; readiness review перед релизом; security review заранее. Календарь дисциплинирует лучше, чем мотивационные речи.

Скрытая цена плохого управления зависимостями

• Мультиблокировка: одна зависимость простаивает 3 команды сразу.
• Интеграционный долг: «потом склеим» превращается в отдельный мини‑проект.
• Переоценка прогресса: 80% задач «почти готовы», а релиза нет.
• Выгорание: люди делают «работу по работе» — пинги, статус‑апдейты, оправдания.

Экспертный вердикт: чек-лист ПМа, который экономит недели

• Есть ли у каждой зависимости владелец и у поставщика, и у потребителя?
• Есть ли критерии готовности (definition of done) и способ приёмки?
• Есть ли “need by” дата, привязанная к реальному событию (интеграция, релизное окно), а не «когда-нибудь в спринте»?
• Есть ли план Б (фича-флаг, мок, деградация, обходной процесс)?
• Вы проводите triage по P0/P1, а не созвон «обо всём»?
• Эскалации формализованы (SLA), чтобы не превращать вас в человека‑пинг?

Частые вопросы