Понимание зависимостей задач в управлении проектами

Что такое зависимости задач на самом деле?

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

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

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

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

Разные типы зависимостей отражают разные требования к последовательности. Выбор типа для каждой связи — плановое решение, и на график оно влияет напрямую. Ошибка оборачивается одним из двух. Либо появляются лишние ограничения и сроки растягиваются — либо исчезают нужные, и задачи стартуют раньше, чем готово всё необходимое для них.

В проектной работе тестирование не может начаться, пока нет кода, который тестируют. Утверждать бюджет нельзя, пока не готово бюджетное предложение. Договорённость тут ни при чём — это операционные требования. Правильно выбранный тип зависимости и отличает график, отражающий реальность, от графика, который рождает завышенные ожидания.

Два самых распространённых типа зависимостей:

• Финиш — Старт (FS) — задача-последователь не может начаться, пока не завершена задача-предшественник. Это самый частый тип. Он нужен везде, где результат одной задачи служит обязательным входом для следующей.

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

• Старт — Старт (SS) — задача-последователь не может начаться, пока не начата задача-предшественник. Этот тип допускает параллельную работу. Он подходит, когда две задачи делят ресурсы или когда ранний результат одной позволяет продвинуться по другой ещё до того, как первая закончена.

Пример: разработку и документацию можно начинать одновременно. Документации достаточно начатого кода — готовый ей не нужен.

Как эффективно управлять зависимостями

Управление зависимостями — постоянная операционная практика, и разовой настройкой тут не обойтись. Первичная разметка даёт структурную опору, а дальнейшая работа решает, останется ли эта опора точной, пока проект движется и обстоятельства меняются.

Практики, которые дают стабильный результат:

• Ведите наглядную карту зависимостей. Актуальная карта связей, открытая всей команде, показывает каждому, какие задачи стоят до и после его собственной работы. Если его задача рискует задержаться, он вовремя предупредит о последствиях.
• Определяйте и отслеживайте критический путь. Критический путь — самая длинная цепочка зависимых задач, и от неё зависит минимальная длительность проекта. Задержка на нём сдвигает дату завершения ровно на столько же. На некритических путях — нет, пока задержки не съедят весь резерв. Различие между ними подсказывает руководству, куда смотреть.
• Планируйте регулярные обзоры зависимостей. Пересмотр карты через заданные интервалы (для активных проектов — раз в неделю) помогает найти узкие места прежде, чем они закрепят задержки в последующих задачах. Больше всего пользы от обзора, когда он заканчивается конкретными решениями о перепланировании, а не одним обновлением статусов.
• Держите запас гибкости ресурсов под задержки из-за зависимостей. Если предшественник буксует, вместе с ним сдвигается и старт последователя. А если ресурсы последователя тем временем ушли на другую работу, восстановление займёт больше времени, чем сама задержка. Небольшой запас гибкости под корректировки зависимостей не даёт эффекту нарастать.

Больше об этом: Управление проектами.

Продвинутые инструменты и аналитика

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

• Интерактивные карты зависимостей — дают наглядное представление всех связей между задачами, по которому можно перемещаться, и позволяют проследить, как одно изменение расходится по всей сети, без ручного пересчёта.
• Анализ влияния в реальном времени — сам пересчитывает последствия, когда меняется дата задачи, и показывает, какие поставки под угрозой и насколько, ещё до того как команда начнёт действовать по исходному плану.
• Умные подсказки по перераспределению ресурсов — предлагают, как перебросить людей, когда задержка из-за зависимости оставляет простой в графике одного участника и узкое место у другого.
• Предиктивная аналитика для раннего выявления проблем — по истории завершения задач находит текущие задачи, которые статистически рискуют сорвать срок, и даёт вмешаться раньше, чем позволяет реактивный контроль.
• Обзор зависимостей между проектами — показывает связи между отдельными проектами, которые делят ресурсы или поставки. Именно такие зависимости руководители отдельных проектов чаще всего не видят, и именно они чаще всего стоят за межпроектными задержками.

Читайте также:

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

Об оптимизации процессов читайте в статье о шаблонах рабочих процессов: как оптимизировать процессы для максимальной эффективности.

За идеями о гибких методологиях загляните в материал о преимуществах Agile: почему Agile помогает командам добиваться успеха в управлении проектами.

Заключение

Управление зависимостями задач — структурная практика. От неё зависит, на чём строится график: на точной модели того, как работа в действительности идёт одна за другой, или на оптимистичном допущении, что задачи независимы. Инструменты, обзоры и типы зависимостей, описанные здесь, не добавляют проекту накладных расходов. Они заменяют расходы куда более дорогие — когда сбои последовательности обнаруживаются уже после того, как привели к задержкам. Taskee даёт слой видимости задач и отслеживания рабочих процессов, с которым управлять зависимостями можно на уровне команды. Выделять под ручное обслуживание отдельных людей для этого не нужно.