Спросите любую команду, почему сдвинулся дедлайн, и честный ответ редко звучит как "мы недооценили объём работы". Чаще это "мы не поняли, что X ждёт Y, а Y ждёт решение, которое никто ещё не принял". Сама работа была оценена нормально — зависимость между частями работы была невидима, пока не вызвала задержку.
Список задач скрывает зависимости по своей природе
Плоский список или даже колонка канбана показывает, в каком статусе каждая задача, но не то, чего она ждёт. Две задачи, лежащие рядом в колонке "To Do", выглядят одинаково готовыми к старту — пока не выясняется, что одна из них на самом деле не может начаться, пока не выпустится другая. Информацию о зависимостях нужно представлять явно, как связи — иначе она не существует нигде, кроме головы того, кто последний об этом подумал.
Составляйте карту зависимостей до того, как оценивать даты
Команды часто сначала строят таймлайн, а зависимости обнаруживают позже — и таймлайн пересобирается каждый раз, когда всплывает скрытая зависимость. Если делать в обратном порядке — сначала составить карту того, что от чего зависит, и только потом назначать даты — назначение дат нужно сделать всего один раз, потому что структура под ним уже верна.
Простой способ начать: для каждой задачи спросите "что должно случиться, чтобы это могло начаться" и проведите линию к тому, что это обеспечивает. Для этого не нужен формальный софт для метода критического пути — доска, на которой можно рисовать связи между узлами, достаточна, чтобы выявить 90% значимых зависимостей.
Критический путь — это цепочка, которая реально управляет вашим дедлайном
Когда зависимости составлены в карту, критический путь — самая длинная цепочка зависимых задач — это единственная последовательность, способная задержать весь проект. У всего, что не на ней, есть запас: оно может немного сдвинуться без сдвига дедлайна. Большинство команд управляют всеми задачами с одинаковой срочностью, потому что не знают, какие из них реально на критическом пути — и тратят внимание на задачи с недельным запасом, пока критические задачи тихо сдвигаются.
Пересматривайте карту, когда меняется задача, а не только на старте
Карты зависимостей устаревают так же, как дорожные карты — они точны на старте и с каждой неделей всё более неверны, если их не обновлять при изменении объёма или сроков задачи. Самый дешёвый момент заметить новую зависимость — когда задача меняется, а не три недели спустя, когда что-то ниже по цепочке внезапно заблокировано. Хранение карты зависимостей на той же доске, где живёт сама работа, а не в отдельном документе планирования, — то, что делает её поддержку реалистичной.