Управление зависимостями между задачами: ключ к успешным проектам

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

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

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

Почему первый список задач почти всегда врёт?

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

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

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

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

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

Что делать, когда связи найдены, но живут только у вас в голове?

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

Второй этап наступает, когда зависимости уже выявлены. Менеджер доволен: схема есть, порядок понятен, риски посчитаны. Схема живёт в его файле.

Дальше происходит обычная вещь. Исполнитель открывает доску, видит десять карточек и берёт ту, что интереснее. Он не знает, что карточка «настроить оплату» держит на себе тестирование, релиз и обучение поддержки. Менеджер узнаёт об этом в день релиза, когда двигать что либо уже поздно.

Связи должны жить в инструменте, которым пользуется вся команда. Минимум такой: поля «блокирует» и «заблокирована» в карточке, повышенный приоритет у блокирующих задач и отдельная колонка ожидания для всего, что стоит без внешнего ответа. Как это настраивается в конкретных сервисах, разобрано в материале про выбор и настройку доски под свой проект.

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

Как удержать график, если он рассыпается на второй неделе?

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

Третий этап самый приятный на вид. Появляется график, видно цепочку задач, которая определяет дату финиша. Менеджер показывает его заказчику. Заказчик кивает.

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

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

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

Кто срывает сроки, когда внутри команды всё сделано вовремя?

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

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

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

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

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

Карта этапов и ловушек в одной таблице

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

Что общего у тех, кто доходит до конца?

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

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

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

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

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

Как вернуться, если вы уже бросили следить за зависимостями?

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

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

1. Выпишите задачи, которые сейчас не двигаются. Ровно те, где за последние дни ничего не изменилось.
2. Против каждой напишите причину простоя одним предложением: ждём человека, ждём решения, ждём другую задачу, исполнитель занят.
3. Разделите этот перечень на две части: внутренние блокировки и внешние ожидания. Лечатся они по разному, смешивать их бессмысленно.
4. Соберите цепочку заново, но только на ближайшие две недели. Дальний горизонт сейчас не нужен, его вы восстановите на следующем шаге.
5. Покажите новую цепочку команде и заказчику вместе с честной новой датой. Один неприятный разговор дешевле месяца тишины.
6. Назначьте еженедельную пятнадцатиминутку на пересчёт связей и не переносите её.

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

Быстрые ответы

Главное: зависимости отвечают на вопрос «что за чем», приоритеты отвечают на вопрос «что важнее», и путать эти два инструмента дорого. Ниже пять вопросов, которые чаще всего задают на разборах проектов: про инструменты для маленькой команды, про разговор с заказчиком, про норму количества связей и про взаимные блокировки.

Чем зависимость отличается от приоритета?

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

Нужен ли отдельный сервис для зависимостей в маленьком проекте?

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

Как объяснить заказчику, почему сдвиг одной задачи двигает дату сдачи?

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

Сколько зависимостей считается нормой для одного проекта?

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

Что делать, если две задачи зависят друг от друга?

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

Источники

• Свод знаний по управлению проектами PMBOK Guide, Project Management Institute: раздел об определении последовательности операций и типах связей между работами.
• ISO 21500 «Руководство по управлению проектами»: процессы планирования состава и последовательности работ.
• ГОСТ Р 54869 от 2011 года «Проектный менеджмент. Требования к управлению проектом».