Анализ критического пути проекта
Critical Path (Критический путь) — это задача или последовательность задач, определяющая дату окончания проекта. Если увеличить длительность задачи, лежащей на критическом пути, то длительность проекта тоже увеличится, а если уменьшить ее длительность, то длительность проекта тоже уменьшится.
ПРИМЕЧАНИЕ
MS Project «умеет» определять время, на которое можно задержать исполнение задачи без увеличения длительности проекта. Эта длительность хранится в поле Total Slack (Общий временной резерв), и если она меньше или равна нулю дней, то задача считается критической. Но в некоторых проектах критическими могут считаться задачи, резерв которых больше, например, если он равен 1 дню. Чтобы определить для проекта размер временного резерва критических задач, нужно с помощью команды меню Tools > Options (Сервис > Параметры) открыть диалоговое окно настройки параметров MS Project, перейти на вкладку Calculation (Расчеты) и указать нужное значение параметра Tasks are criticalis slack is less or equal to ... days (Считать критическими задачи, имеющие резерв не более ... дней).
MS Project также относит к критическим задачи, имеющие ограничения типа Must Start On (Фиксированное начало), Must Finish On (Фиксированное окончание), As Late As Possible (Как можно позже) в планируемых от даты начала проектах и As Soon As Possible (Как можно раньше) в проектах, планируемых от даты окончания. Кроме того, критическими считаются задачи, дата окончания которых превышает дату крайнего срока или совпадает с ней.
Для отображения критического пути проекта на диаграмме Ганта нужно воспользоваться мастером Gantt Chart Wizard (Мастер диаграмм Ганта), вызываемым одноименной командой в меню Format (Формат) или контекстном меню диаграммы Гаита. На втором шаге мастера (рис. 15.10) нужно выбрать переключатель Critical Path (Критический путь) и нажать кнопку Finish (Готово).
Рис. 15.10. Отображаем критический путь на диаграмме Ганта
После этого диаграмма Ганта перестроится, а задачи, лежащие на критическом пути (критические задачи), и связи между ними будут выделены красным цветом (рис. 15.11, файл б.mрр). Теперь можно переходить к уменьшению длительностей задач, причем начать стоит с тех, что лежат на критическом пути. При этом следует помнить, что сокращение длительности задач может не только убрать их с критического пути, но и сделать критическими другие задачи.
СОВЕТ
Чтобы оставить на диаграмме Ганта только критические задачи, нужно воспользоваться фильтром Critical (Критические).
Рис. 15.11. Так выглядит наш план после форматирования диаграммы с помощью мастера и применения фильтра для отбора только критических задач
Для сокращения длительности задачи можно применить несколько методов: во-первых, можно сократить объем работы, требуемый для ее выполнения. Во-вторых, можно добавить ресурсы для ускорения выполнения работы при сохранении ее объема. Наконец, можно разбить задачу на подзадачи, выполняемые одновременно разными сотрудниками.
В нашем случае мы сократили длительность двух задач: Подготовка редакционных заданий и Утверждение заданий авторами. Длительность первой задачи мы сократили незначительно, а второй — в два раза (с 4 до 2 дней), поскольку .на скорость ее выполнения можно повлиять административными мерами.
Но сокращение длительности этих задач не помогло уложиться в крайние сроки. И тогда мы разбили задачу Редактирование материалов на 3 подзадачи: Редактирование раздела 1, 2 и 3 и спланировали их одновременное исполнение. Это возможно потому, что журнал состоит из трех разделов, и каждый из редакторов разделов отвечает за свой раздел и осуществляет редактирование материалов в нем независимо от других. Длительность каждой задачи была установлена равной 10 дням, а загрузка ресурсов определена в 70% с ранним пиком в профиле загрузки. В результате бывшая задача и нынешняя фаза Редактирование материалов перестала быть критической (рис. 15.12, файл 7.mрр).
Рис. 15.12. Критический путь проекта после редактирования
Теперь план проекта укладывается в сроки, причем с небольшим опережением. Но прежде чем переходить к анализу и оптимизации стоимости проекта, нужно проверить, не возникло ли перегрузок ресурсов после изменений в плане. Это возможно, например, у задач с фиксированным объемом работ, поскольку уменьшение длительности таких задач приводит к увеличению объема работы, которую задействованные в них ресурсы должны выполнять в течение дня.
В нашем случае превышение доступности снова возникло у Иванова, Петрова, Сидорова и Галкиной (7.mрр) — наиболее активно задействованных в проекте ресурсах. От него нужно избавиться, чтобы при анализе стоимости корректно учитывать трудозатраты и сверхурочную работу. Приемы выравнивания ресурсов вам уже известны, а в нашем случае мы использовали только перераспределение загрузки (файл 8.mpp). Теперь, когда план работ и загрузка ресурсов нас устраивают, можно переходить к анализу и оптимизации стоимости проекта.
