Вот собрался писать про управление планом-графиком при том, что у меня за последнее время статистика такая:

• Время на проекте: 4 месяца
• Сдвиги проекта: почти 3 месяца

Ладно, будем считать, что "за одного битого двух небитых дают". :) Рассмотрим следующие вопросы:

1. Подход к составлению план-графика
2. Изменение сроков
3. Ужимание, распараллеливание и другие мифы

Подход к составлению план-графика

Подход, который я опишу, больше подходит для waterfall и гибридных проектов, когда план-график (и соответствующая ему диаграмма Гантта) имеют место быть. Если вы работаете исключительно в системе agile (Scrum или Kanban), то вы больше работаете с приоритетами, то есть определяете объём следующего спринта (или того, что берёте в работу в рамках Kanban) на основе относительной важности задач. Дальше у вас есть либо фиксированный по длине спринт, либо то, что попало в работу. Другими словами, отрезок времени и ресурсы фиксированы, объём определяется приоритетами, поэтому приоритетами и нужно заниматься в первую очередь.

План-график нужен, когда у вас есть заданная технологией (или подходом) последовательность работ: на уровне достаточно детальных задач в случае waterfall или на уровне этапов в случае гибридного подхода. Поскольку планирование – это процесс, лучше всего на него смотреть с точки зрения входов и выходов:

• входы: задачи, их последовательность, трудоёмкость и сроки
• выходы: общая длительность проекта

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

Специализированные инструменты вроде MS Project или GanttProject сильно облегчают составление плана-графика, поскольку позволяют учесть выходные дни, календарь праздников, а также вносить изменения и при этом не переделывать всё. Если зависимости между задач установлены корректно, зависимые задачи подвинутся автоматически.

Лично я пользуюсь одним-единственным подходом при составлении плана-графика, который страхует от крупных ошибок и дисциплинирует мышление – сверху-вниз:

1. Ставим одну задачу на верхнем уровне, которая совпадает с названием проекта: в ней будет автоматически считаться старт и окончание проекта;
2. Ставим этапы на уровне -1, только после составления перечня этапов переходим на нижний уровень и так далее;
3. Детализируем до уровня крупных задач, но это не те задачи, которые будут выданы конкретным исполнителям; в основном, здесь исходят из того, чтобы план слишком сильно не разрастался по количеству строк.

Балансировка ресурсов – немного отдельная тема, и она не всегда требуется, поэтому пока едем дальше.

Изменение сроков

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

1. Честно внести изменения
2. Учесть влияние на другие задачи, которые не всегда видны на плане-графике, поэтому нужно понимать также сутевую часть зависимостей
3. Сообщить всем заинтересованным лицам через правильные средства коммуникации об изменениях: связанным проектам, Проектному комитету, акционерам

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

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

Очень часто бывает, что видимые результаты на проекте появляются достаточно поздно, поэтому долгое время можно ходить на статусы и спрашивать "как дела?", а в ответ слышать "всё в работе". Через 2 года окажется, что ничего не сделано, поэтому:

1. Детализация изначального плана-графика определяет риск сдвига на уровне одной задачи; если он разбит на задачи длительностью месяц, то он может сдвинуться на месяц
2. Косвенным признаком, как на самом деле идут дела, могут быть не только вопросы об окончании задачи, но и вопросы о начале задачи
3. Можно и нужно до окончания массивной по сроку задачи устраивать обсуждения драфта, поэтому отмазки по планированию таких встреч не принимаются – либо есть что показать, либо там никто ничего не делал

С другой стороны, здесь легко можно свалиться на уровень микро-менеджмента, и тут вступает в силу другое правило: если у вас такие люди, которыми можно управлять только с помощью микро-менеджмента, может, пора менять людей?

Ужимание, распараллеливание и другие мифы

После скрытия сдвигов следующими грехами проектного менеджера являются:

• Ужимание ранее запланированных сроков
• Распараллеливание задач, у которых изначально была очерёдность

В целом это нарушение общего правила "лучше не будет". Исключением является предварительная проработка задачи, в рамках которой её объём уточнился и действительно уменьшился. Именно потому, что бывает обычно хуже, лично я предпочитаю не трогать зависимости и сроки, но использовать для новых задач и для понимания срока окончания уже начатых задач планирование от освоенного объёма. И тут кроется ещё один грех: мы сделали 10% за 90% времени, оставшиеся 90% объёма сделаем сейчас / сегодня / внезапно. Планирование от освоенного объёма это опровергает: грубо говоря, 100% задачи займёт 900% от первоначального срока, следовательно, оставшийся объём можно сделать за 810%.

Но это ещё не всё, в реальности всегда происходит замедление по следующим причинам:

• Люди устают, и темпы падают
• Накапливается технический долг – те вопросы, которые задвинули на попозже
• Риски с течением времени имеют свойства реализовываться, в том числе, возникают технические проблемы
• Объём тоже имеет свойство увеличиваться с течением времени, особенно если им не управлять: это относится и к критериям приёмки, то есть если первые результаты можно сдавать легко, то следующие будут принимать всё более тщательно
• На более поздних стадиях выясняется дельта между тем, что необходимо сделать для достижения результата, и теми задачами, которые есть в проектном плане

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

При возникновении такого рода вопросов у проектного менеджера возникает два варианта решения:

• закладывать средние или даже максимальные сроки, то есть маскировать проблемы в сроках
• закладывать минимальные сроки и подсвечивать риски отдельно

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