PMsoop: Глава №12: Plan is nothing, Planning is everything!

В ролях – Менеджер Проекта, Команда Проекта

Артефакты – ТЗ, таск-лист, список рисков, План Проекта

Суть – Менеджер Проекта создаёт первую версию Плана Проекта

Наконец, у нас есть ТЗ, таск-лист, и список рисков. Переходим к финальной цели подготовительного этапа:

9. Зафиксировать все  принятые решения и сделанные оценки и перейти к составлению плана проект

Что такое план проекта (ПП)? Это основной инструмент как планирования будущих работ, так и отображения работ уже завершенных и текущих. Это очень важный момент – ПП нужен не только чтобы «набросать» что и в какой последовательности делать будем, но и чтобы достоверно отображать ситуацию в проекте в каждый контрольный момент времени.

План проекта – это «живой» документ, который постоянно (регулярно) актуализируется и изменяется в процессе разработки. Актуальный на текущую дату план проекта должен быть своего рода «приборной панелью», по которой можно увидеть, что уже сделано, что в процессе, насколько актуальны сроки сдачи и т.п. Это конечно в идеале…

В реальности на план и поддержание его в актуальном состоянии часто «забивают» сразу после его создания. Тем самым теряя важный инструмент «диагностики» проекта. И увеличивая шансы получения «внезапных» проблем. Впрочем, про то, как правильно обновлять план – будет позже. Для контекста этой главы просто имеем ввиду, что план надо будет неоднократно актуализировать, и учитываем этот момент при его построении.

Базой для создания ПП является таск-лист, так как в нём уже определены основные задачи разработки и тестирования. Оптимальной формой для представления ПП является диаграмма Ганта. Она позволяет наглядным (что важно) образом показать все задачи проекта в последовательности их выполнения, привязанные к календарной сетке, с указанием ответственных за выполнение каждой задачи, с демонстрацией точек появления необходимых артефактов и других «вех», с возможностью указания процентов завершения либо выполненных трудозатрат по каждой задаче, и многое другое. В общем, я думаю все читатели уже знают что такое диаграмма Ганта, а если кто не знает – Гугл в помощь.

Инструменты для создания плана проекта в виде диаграммы Ганта есть разные, из них самый, наверное, распространённый – MS Project, сам им пользуюсь. Но, в дальнейшем изложении постараюсь к инструментам не привязываться.

Итак, задача №1 – берём таск-лист, и все задачи разработки из таск-листа переносим в план проекта. Для каждой задачи назначаем исполнителя (можно несколько). Для каждой задачи не забываем указать планируемые трудозатраты, причем здесь, это важно, в отличие от таск-листа, ставим наиболее вероятную (реальную) оценку (которая обычно где-то посредине между оптимальной и пессимистичной). Учитываем риски – для сложных задач планируемые трудозатраты близки к пессимистичной оценке, для простых – к оптимальной. В первую очередь вносим задачи критического пути, не забывая про последовательность. Потом добавляем задачи которые могут выполняться параллельно с задачами критического пути и расставляем их на календарном плане исходя из возможностей участников команды проекта.

Если вдруг оказалось что из-за «параллельных» задач сроки сдачи сдвигаются – значит, критический путь был определён неверно. В таком случае – собираем разработчиков и переопределяем критический путь.

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

Задача №2 – добавляем в план проекта все задачи тестирования, согласно таск-листу. По завершению финальной задачи тестирования для версий которые сдаются Заказчику рекомендую опять же добавить milestone.

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

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

- подготовка сред тестирования, «показа» и рабочей среды продукта (где он будет жить по окончании разработки) – всё это надо сделать до того как такая среда будет востребована, например параллельно с разработкой

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

- подготовка сред контроля версий, дефектов, отчётности и т.п. – обычно делается на подготовительном этапе, но бывает всякое

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

- подготовка сценариев тестирования – следует делать заранее, до начала тестирования, обычно эта задача выполняется параллельно с разработкой

- после начала «показа» каждой версии иногда стоит «зарезервировать» один или несколько дней (в зависимости от размеров проекта) для ответов на вопросы Заказчика и срочные исправления критических дефектов. Такие задачи вставляются между версиями и растягивают сроки проекта.

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

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

Большинство дополнительных задач обычно расположены «параллельно» критическому пути на диаграмме Ганта, а значит, не влияют на сроки проекта. Но некоторые – такие как исправление критических дефектов и детальное планирование – ставятся между версиями и, соответственно, влияют на сроки.

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

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

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

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

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

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