Разработка предварительного расписания проекта

Собственно говоря, показанная на рис. 3.17 линейная диаграмма уже обладает всеми свойствами расписания, т. к. на ней определены даты начала и окончания каждой из задач проекта, предусмотренные в его предварительном плане. Дело в том, что Project по умолчанию работает в режиме, при котором после любого внесенного изменения показатели графика автоматически пересчитываются. Для управления этим режимом вокне команды Сервис\Параметры на вкладке Расчет (рис.3.18) предусмотрены переключатели режима расчета.

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

Это можно сделать нажатием клавиши <F9> или кнопки Рассчитать в окне Параметры на вкладке Расчет (рис.3.18).

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

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

Если рассматривать показанное на рис. 3.17 расписание как первое приближение к расписанию проекта, то в первом приближении цикл проекта оказался равным 24 рабочим дням (см. число в первой строке столбца Длительность). Так как подобное расписание проекта может быть сформировано еще на стадии переговоров с заказчиком, то при отсутствии прямого требования заказчика по дате окончания проекта целесообразно рассмотреть расписание вместе с заказчиком, чтобы выяснить требуемую дату окончания проекта, а также согласовать сроки наступления других ключевых событий проекта.

Так как на рис. 3.17 показано только первое приближение к расписанию проекта, оно еще не может служить надежной основой для оценки действительного цикла выполнения проекта до соответствующей проработки.

Предположим, что на основании анализа предварительного расписания заказчик выразил желание довести длительность выполнения проекта до 20 рабочих дней.

Исходя из этого, руководитель проекта должен проработать расписание так, чтобы найти возможность удовлетворить требования заказчика без ущерба для своей компании или обоснованно доказать нереальность требований заказчика. Это можно сделать путем решения одной из наиболее популярных в управлении проектами задач - сокращения длительности выполнения проекта.

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

Для этого можно использовать предусмотренный в Project механизм управления временными ограничениями задач.

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

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

- Как можно раньше (As Soon As Possible);

- Как можно позже (As Late As Possible);

- Начало не позднее (Start No Later Than),

- Начало не ранее (Start No Earlier Than);

- Окончание не позднее (Finish No Later Than);

- Окончание не ранее (Finish No Earlier Than);

- Фиксированное начало (Must Start On);

- Фиксированное окончание (Must Finish On).

Большинство перечисленных ограничений (кроме первых двух) должно быть связано с конкретными датами ограничений.

В общем случае управление временными ограничениями задач включает две основные операции:

- ввод временного ограничения;

- отмена временного ограничения, установленного ранее.

Рассмотреть первую из этих операций целесообразно при установке временного ограничения цикла выполнения проекта-примера. Наиболее простым способом решения этой задачи является установление ограничения срока окончания события - вехи "Окончание проекта" при помощи алгоритма 3.13.