nologostudio

Итак, метод критического пути. Краткий практикум по использованию метода критического пути для вычленения критических задач (без запаса времени, реально влияющих на сроки проекта или этапа проекта) и некритических задач (с запасом времени).

Первое, что мы делаем, это составляем список задач (этапов) проекта и разбиваем его на подзадачи (составляем заготовку для иерархической структуры работ), как на рис. 1


Далее нам нужно определить, какие задачи можно делать параллельно, а какие только последовательно, какие задачи польностью независимы друг от друга, а какие зависимы. Зависомость может быть как от особенностей разработки (некоторые блоки не могут быть разработаны, пока не разработаны предыдущие), так и от количества человек на проекте (очевидно, что если на проекте 2 программиста, сразу четыре блока параллельно делаться не могут). На этом же этапе уже можно оценить сроки по задачам. Я для этого использовал Microsoft Visio. На рис. 2 показано то, что примерно после проставления связей получается (на примере задач программирования).


Замечу, что сюда же можно внести в качестве задач блоки ожидания (например ожидание некоторой информации).

Далее мы начинаем расчитывать длительность каждой цепочки проекта.


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


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

Таким образом и менеджер и лидер группы разработчиков с одного взгляда способны определить, какие задачи критичны для сроков, с каких задач возможна переброска людей для завершения критических задач. А самих задач, влияющих на срок проекта, становится меньше. Кроме того, по данной методике можно расчитать самый поздний старт проекта исходя из известного времени окончания проекта (обратным расчетом от конца). И, играя сроками старта задач с большим запасом, в некоторых случаях можно уменьшить ресурсы людей на проекте (хотя вообще говоря, это нерекомендуется, ресурсы необходимо закладывать на начальном этапе расчета).

Следующим шагом является дозаполнение иерархической структуры работ. Для задачи можно указать несколько предшественников через “;”.



Сортировкий можно добиться более приятного для глаза отображения диаграммы Ганта, однако это я оставляю Вам.

P.S.: Таким образом, затратив на планирование чуть больше времени (в принципе при готовых шаблонах 15 минут вполне достаточно, чтобы сделать эту работу), мы получаем возможность гибкого управления сроками проекта и снижение рисков. Да и вообще получаем толковый прогноз на проект.

P.S.: Указали на двусмысленность про 15 минут. Конечно же имеется в виду, что не вся работа по планированию займет 15 минут, а только сведение данных от разработчиков, так сказать, причесывание. Оценки разработчиков делаются гораздо дольше, при описанном ТЗ дня два, бывает и больше.