Список хорошо хранит задачи, но плохо объясняет их отношения
Список задач удобен, когда нужно быстро зафиксировать, что вообще должно быть сделано. Но дальше начинается главная проблема: список почти не показывает, как эти работы связаны между собой. Из него трудно понять, что стартует только после согласования, где один этап держится на другом и какая задержка потянет цепочку вниз.
В результате проект вроде бы описан, но управляется всё равно через личную память руководителя и бесконечные уточнения в сообщениях.
Без времени проект кажется спокойнее, чем он есть на самом деле
Когда задачи лежат просто перечнем, не видно плотности плана. Можно случайно набить одну неделю работами так, будто у команды бесконечный ресурс. Список не кричит об этом. Он спокойно показывает двадцать пунктов и не даёт понять, что половина из них должна идти параллельно и упрётся в одних и тех же людей.
Именно поэтому у многих команд ощущение контроля держится до первого серьёзного сдвига. Пока никто не спросил про реальные сроки, кажется, что всё под контролем.
Список плохо показывает риск, а проект обычно срывается именно там
Риск в проекте редко выглядит как одна большая красная проблема. Чаще это пара неочевидных зависимостей, тесный запас по времени и перегруженный участок команды. Список задач не собирает это в одну картину. Он показывает элементы по отдельности, но не показывает напряжение между ними.
- не видно, где задача уже сидит на критическом пути;
- сложно понять, какие работы нельзя сдвигать без последствий;
- почти невозможно быстро объяснить команде, почему один небольшой срыв заденет несколько этапов.
Поэтому списку нужен сосед, который показывает проект целиком
Сам по себе список задач не плох. Он нужен как рабочий уровень детализации. Но если команда хочет управлять сроками, зависимостями и загрузкой, ей нужна ещё одна плоскость просмотра — там, где виден весь маршрут проекта. Обычно именно здесь появляется диаграмма Ганта, таймлайн или система вех и зависимостей.
Поэтому дело не в том, чтобы отказаться от списка, а в том, чтобы перестать считать его достаточным. Как только проект становится сложнее набора мелких поручений, одного перечня уже мало.
