Эту страницу открывают, когда проект зависит не только от собственной команды: нужны решения смежников, доступы, поставки, интеграции, согласования, ресурсы, окна релиза или участие руководителей. В таких условиях зависимость, не вынесенная в отдельный контур, почти всегда становится источником внезапной задержки.
Dependency register — это реестр зависимостей проекта. Он помогает PM видеть, от чего именно зависит движение, кто владеет внешним шагом и где надо заранее создавать запас времени, коммуникацию или эскалацию.
Когда нужен
- несколько команд должны синхронно дать вклад в результат;
- есть внешние поставщики, подрядчики, ИБ, инфраструктура, согласующие;
- проект проходит через сложные технические и организационные стыки;
- сроки зависят не только от выполнения внутренних задач;
- задержки часто возникают не внутри команды, а на внешнем контуре.
Что должно быть в реестре
- описание зависимости;
- тип зависимости: команда, система, решение, ресурс, поставка, согласование;
- внешний или внутренний владелец;
- ожидаемая дата или окно;
- влияние на проект при срыве;
- текущий статус и следующие действия.
Как использовать на практике
1. Выписывайте зависимости уже при сборке ограничений и плана. 2. Не смешивайте зависимости с рисками: зависимость может быть нейтральной, пока не начинает угрожать сроку. 3. Если зависимость становится ненадёжной, отражайте это и в risk log. 4. Регулярно выносите критические зависимости в status report. 5. Не допускайте зависимостей без владельца и следующего шага.
Практический шаблон
Минимальная строка в dependency register полезна, если в ней сразу видно:
- сама зависимость;
- её тип: внутренняя или внешняя, организационная или техническая;
- владелец с другой стороны;
- ближайшая дата контакта или контрольная точка;
- влияние при срыве;
- текущий статус и следующий шаг.
Так PM быстрее отличает реальную управляемую зависимость от абстрактного знания, что «мы от кого-то там зависим».
Как работать с зависимостями, а не просто хранить их
Сильная практика обычно выглядит так:
1. Отдельно выделяются зависимости, которые влияют на ближайшие этапы и релизы. 2. По каждой критичной зависимости назначается ритм пинга или проверки. 3. Если внешний контур начинает сдвигаться, зависимость сразу поднимается в status report. 4. Если срыв уже вероятен, зависимость дополнительно переводится в risk log.
Это позволяет не ждать, пока внешняя проблема станет внезапной блокировкой для команды.
Что ломается без него
- задержки постоянно приходят «извне» неожиданно;
- команда живёт по внутреннему плану, который не учитывает реальный внешний контур;
- PM поздно эскалирует проблемы по зависимым сторонам;
- руководители слышат о критической внешней блокировке уже после срыва срока.
Типовые ошибки
- считать зависимость просто задачей и терять внешний контур;
- не фиксировать дату следующего контрольного контакта;
- не разделять критичность зависимостей;
- не пересматривать реестр по мере изменения плана;
- забывать связать зависимость с этапами, релизом и рисками.