В мультикомандных проектах задачи редко выполняются изолированно.
Большинство из них имеют зависимости - от данных, других задач, команд или внешней инфраструктуры.
Если такие зависимости не идентифицированы и не отслеживаются, они становятся источником сбоев в сроках, качестве и управляемости проекта.
Три типа рисковых зависимостей:
1. Блокирующие (Hard Dependencies)
Пример: задача не может стартовать без готового API или утвержденного макета.
2. Плавающие (Soft Dependencies)
Пример: смежная команда пообещала отдать результат «в течение недели», но у них другие приоритеты.
3. Распределённые (External Backlog Dependencies)
Пример: связанная задача ведётся в другой Jira-доске и не входит в сферу контроля вашей команды.
Стратегия управления зависимостями (Dependency Mapping)
1. Выявление и фиксация
Создаём карту зависимостей: визуально (например, через Miro или Notion) или в виде таблицы. Указываем источник, тип зависимости и степень риска.
2. Назначение ответственного
Каждая зависимость должна иметь владельца, отвечающего за коммуникацию и актуализацию статуса.
3. Включение в план
Зависимости учитываются в планировании: сроки, риски, буферы. Они становятся частью спринта или релизного плана, а не “фоном”.
4. Регулярный мониторинг
Формализуем точки синхронизации: кто, с кем и когда синкается. Это особенно критично при кросс-функциональных интеграциях.
📌 Вывод
Dependency Mapping - это не избыточная бюрократия, а базовый инструмент для устойчивости проекта.
Пока зависимости не описаны, ни один план не может считаться реалистичным.
