Зависимости между задачами проекта: что учитывать в плане

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

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

Что такое зависимость между задачами

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

При запуске новой функции продуктовая команда сначала согласует требования, затем готовит дизайн, разрабатывает функцию, тестирует её и публикует. Если разработчику для старта нужен готовый макет, дизайн становится предшественником разработки.

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

Зависимость отличается от подзадачи, смысловой связи и временного ограничения.

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

Зачем проекту нужны зависимости между задачами

Зависимости нужны проекту, чтобы определить допустимый порядок выполнения работ, согласовать сроки между участниками и заранее увидеть потенциальные блокировки. Обычный список задач показывает состав работы, но не объясняет, какие результаты нужны для перехода к следующему этапу.

Рассмотрим цепочку запуска функции:

Пять карточек можно поставить на один проект и назначить им сроки, но сами даты не показывают причинную связь. Если разработка задержится, тестирование не сможет начаться в запланированный день, а публикация окажется под риском.

При этом не все работы проекта обязаны идти последовательно. Подготовку релизного текста можно начать параллельно с тестированием, если автор уже получил необходимые сведения о функции. Зависимости должны показывать реальные ограничения, а не превращать весь проект в одну длинную очередь.

Зафиксированные связи позволяют определить:

•  
• какие задачи нельзя начинать до получения определённого результата;
• какие работы допустимо выполнять параллельно;
• задержка какого предшественника повлияет на последователей;
• какие результаты команда ждёт от другого отдела или подрядчика;
• какие части календарного плана нужно проверить после изменения сроков.

Зависимая задача не является заблокированной автоматически. Блокировка возникает, когда условие для продолжения работы уже должно быть выполнено, но требуемого результата ещё нет.

Какие виды зависимостей задают порядок работ

Порядок работ описывают четыре временных типа зависимости: «окончание — начало», «начало — начало», «окончание — окончание» и «начало — окончание». Такая классификация используется в стандарте PMI в рамках метода предшествования.

Внутри отдельной связи также встречаются задержка и опережение. Задержка, или lag, добавляет интервал между двумя связанными событиями, а опережение, или lead, разрешает начать следующую работу до полного завершения предыдущей. Для вводного планирования достаточно понимать назначение этих интервалов без отдельного расчёта.

По причине возникновения зависимости также различаются. Логическая зависимость появляется, когда следующей работе объективно нужен результат предыдущей. Ресурсная возникает при конкуренции за одного специалиста, оборудование или другой ограниченный ресурс. Предпочтительная зависимость отражает принятый командой порядок, который технически можно изменить.

Связи также бывают внутренними, межкомандными и внешними. Внутренняя зависимость находится внутри зоны контроля одной команды. Межкомандная появляется, когда один отдел ждёт результат другого. Внешняя связывает проект с клиентом, поставщиком, разрешением, внешней системой или другим событием, которое команда не контролирует напрямую.

Как работает связь «окончание — начало»

Связь «окончание — начало» означает, что последователь не может начаться до завершения предшественника. Тип обозначают FS — Finish-to-Start.

Для запуска функции разработка зависит от дизайна по FS, если разработчику нужен полностью готовый и согласованный макет. Пока результат дизайна не передан, условие старта разработки отсутствует.

FS подходит для действительно последовательных работ. Если разработчик способен начать часть реализации до окончательного завершения дизайна, жёсткая связь FS способна необоснованно увеличить срок проекта.

Как работает связь «начало — начало»

Связь «начало — начало» означает, что последователь может начаться после старта предшественника. Тип обозначают SS — Start-to-Start.

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

SS используют, когда две работы выполняются параллельно, но запуск одной из них всё же зависит от начала другой. Связь не требует, чтобы обе задачи стартовали в один момент.

Как работает связь «окончание — окончание»

Связь «окончание — окончание» означает, что последователь не должен завершиться раньше предшественника. Тип обозначают FF — Finish-to-Finish.

Релизный текст можно готовить параллельно с тестированием, но финальную версию нельзя зафиксировать до окончания проверки. Результаты тестирования могут потребовать изменить описание функции или указать известные ограничения.

FF регулирует моменты завершения, поэтому начало двух работ может происходить независимо.

Как работает связь «начало — окончание»

Связь «начало — окончание» означает, что последователь завершается после начала предшественника. Тип обозначают SF — Start-to-Finish.

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

Редкость SF не означает, что тип нужен для полноты каждого календарного плана. Связь добавляют только при наличии реального условия между работами.

Как зависимости формируют критический путь

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

Для запуска функции цепочка может выглядеть так:

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

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

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

Чем опасны неучтённые зависимости задач

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

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

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

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

Как блокер вызывает каскадную задержку

Блокер вызывает каскадную задержку, когда невыполненное условие останавливает зависимую задачу, а от неё уже зависят следующие работы.

Для запуска функции каскад выглядит так:

Изначальная задержка относится к одной работе, но влияние распространяется по цепочке последователей.

Несколько предшественников усиливают риск скрытой блокировки. Тестирование способно одновременно ожидать готовую разработку, тестовое окружение и набор данных. Завершение одного предшественника не разрешает старт, пока остальные обязательные условия не выполнены.

Одна задача также способна иметь несколько последователей. Если готовность API одновременно требуется мобильной разработке, веб-разработке и интеграционному тестированию, задержка предшественника влияет сразу на несколько ветвей проекта.

Как устная договорённость скрывает простой

Устная договорённость скрывает простой, когда условие между работами существует только в памяти участников и не отражено в плане. Исполнитель видит задачу и срок, но не видит результат, который должен получить перед стартом.

Формулировка «начнём после согласования» не определяет зависимость достаточно точно. Команде требуется знать, какая задача представляет согласование, какой результат считается готовым и кто отвечает за его передачу.

Особенно уязвимы межкомандные связи. Один отдел считает, что передаст результат «в конце недели», а другой уже поставил следующую работу в план на конкретный день. Без общей записи две локально логичные даты образуют конфликт.

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

Как показать зависимости на плане

Зависимости на плане показывают через пары «предшественник — последователь» и конкретное условие между ними. Для первого варианта карты достаточно зафиксировать работы, результат предшественника и ответственного за его передачу.

Такая карта сначала описывает логику, а не даты. После проверки связей команда может составить календарный план, добавить продолжительность задач, конкретные сроки и ответственных.

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

Как диаграмма Ганта показывает цепочку

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

Сетевой график показывает ту же систему с другим акцентом: основное внимание переносится с календарных дат на структуру переходов между работами. Для большинства вводных сценариев достаточно таблицы зависимостей и диаграммы Ганта.

Некоторые системы проектного планирования умеют автоматически переносить даты последователей после изменения предшественника и отправлять уведомления участникам. Автоматический пересчёт зависит от конкретного инструмента и настроек, поэтому такую механику нельзя считать обязательным свойством любого таск-менеджера.

Как настроить зависимости без лишних связей

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

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

Как выбрать реальное условие старта

Реальное условие старта определяют по результату, без которого исполнитель не способен начать следующую задачу. Формулировка «мы всегда сначала делаем дизайн» описывает привычный порядок, а формулировка «разработчику нужен утверждённый макет» описывает зависимость.

Перед поиском связей крупную работу нужно разбить на задачи. Конкретные результаты позволяют понять, что действительно передаётся между исполнителями.

Для каждой потенциальной зависимости проверьте:

•  
• Какой результат нужен следующему исполнителю.
• Какая задача создаёт этот результат.
• Требуется завершение предшественника или достаточно его начала.
• Ограничивает ли работы один ресурс.
• Зависит ли результат от другой команды или внешней стороны.

Сохранится ли ограничение при изменении привычного порядка выполнения.

Последний вопрос помогает находить лишние связи. Если работы можно выполнять независимо без влияния на качество, срок или обязательства, жёсткая зависимость только сокращает свободу планирования.

Как найти замкнутый круг в цепочке задач

Замкнутый круг появляется, когда задача прямо или через несколько промежуточных работ начинает зависеть от самой себя. Такая цепочка не имеет выполнимой первой задачи: каждая работа ждёт результат другой.

Простой цикл выглядит так:

Более длинный цикл способен пройти через несколько работ:

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

Циклическая зависимость часто указывает не на сложность проекта, а на неверно определённые результаты. Команде нужно уточнить, какой промежуточный результат действительно позволяет начать следующую работу. Например, разработчику может требоваться не окончательный дизайн, а согласованный прототип, после которого дизайн и разработка продолжаются параллельно.

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

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

Повторная проверка требуется после переноса срока, изменения состава проекта, смены исполнителя или появления нового внешнего ограничения.

В цепочке проверяют четыре ситуации:

• появился новый предшественник, который прямо или косвенно зависит от самой задачи;
• у задачи несколько предшественников, но один из них пропущен;
• ранее обязательная связь больше не ограничивает работу;
• перенос одной задачи изменил сроки последователей или потребовал пересогласования с другой командой.

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

Во время выполнения проекта руководитель продолжает контролировать выполнение предшественников, сроки последователей и изменение внешних условий.

Когда команде достаточно статусов задач

Статусов задач достаточно, когда работа движется потоком и между отдельными карточками нет жёсткой календарной последовательности. Например, редакционная команда ведёт материалы через этапы «Идея», «В работе», «Редактура» и «Готово», а каждый новый материал не обязан ждать завершения предыдущего.

В поточном сценарии команда может вести общую доску и контролировать текущий статус, исполнителя и срок каждой карточки. В Strive доступны канбан-доски с настраиваемыми колонками и свойствами задач, а таймлайн позволяет показывать задачи на временной шкале. 

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

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