Определение резервов времени

Определение резервов времени

После того, как были рассчитаны прямой путь и обратный путь, мож­но определить, какие операции могут задерживаться, вычислив «простой» или «колебание». Полный простой или колебание операции представляет разницу между LS и ES (LS — ES = SL) или между LF и EF (LF — EF = SL). Например, простой для операции С — 5 дней, для операции D — 10 дней и для операции G — 0 (см. рис. 4-9). Полный простой показывает то время, на которое выполнение операции может задерживаться, не задерживая при этом выполнение проекта.

Если происходит простой одной операции на пути, ЕS для цепочки всех последующих операций будет задержано, и их простой сокращен. Исполь­зование полного простоя должно координироваться всеми участниками последующих операций цепочки.

После вычисления простоя для каждой операции легко определить критический путь. Когда LF = EF для конечной операции проекта, крити­ческий путь можно определить, как те операции, у которых LF = EF или простой = 0 (LF - EF = 0) (или LS - ES = 0).

 

 

		B     План конструи рования				E     Отчет персонала
							H     Включе ние в работу
A 5   Утвержде ние приложения		C 15   Изучение трафика		F     Утвержде ние на комиссии		G     Ожидание работ
		D     Проверка наличия службы					ES ID EF SL   LS Dur LF

Рис. 4-9. Сетевой график типа ОУ для проекта создания бизнес центра Колла с указанием резервов времени выполнения операций

 

СЛУЧАИ ИЗ ПРАКТИКИ Критический путь

Долгое время метод критического пути (СРМ) считался «чашей Грааля» всей теории управления проектами.

Вот некоторые комментарии ветеранов управления проектами относительно значения критического пути для управления проектами.

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

- Я уделяю дополнительное внимание при оценке риска выявлению тех рис­ков, которые могут оказать прямое или косвенное влияние на критический путь, когда некритические операции выполняются столь поздно, что становятся критическими. Когда у меня есть деньги, которые можно использовать на сокращение рисков, они обычно идут на критические задачи.

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

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

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

 

 

Критический путь — это путь, который имеет наименьший простой в целом.

Проблема возникает, когда последняя операция проекта имеет LF, ко­торый отличается от EF, полученного в результате прямого анализа — на­пример, из-за того, что сроки выполнения установлены жестко. А если это так, то простой на критическом пути будет не нулевым, а будет равен раз­нице между EF проекта и установленным LF последней операции проекта. Например, если EF для проекта — 235 дней, а установленный LF или пла­новый срок — 220 дней, все операции критического пути будут иметь про­стой минус 15 дней. Конечно, это приведет к позднему старту «—15 дней» для первой операции проекта — хороший трюк, если проект должен на­чаться сейчас. Отрицательный простой случается на практике, когда вы­полнение операций критического пути задерживается.

На рис. 4-9 критический путь показан в виде пунктирных стрелок и блоков — операций А, В, F, G и Н. Отставание одной из этих операций при­ведет к отставанию в выполнении проекта на то же количество дней. Кри­тические операции обычно составляют около 10 % всех операций проекта. Поэтому руководители проектов пристально следят за тем, чтобы опера­ции критического пути выполнялись по графику.

 

Свободный резерв

Операции со свободным резервом уникальны, так как выполнение операции может откладываться, не влияя на ES последующих операций. Свободный резерв некоторой операции определяется, как разница между EF этой операции и ES последующей операции. Свободный резерв никог­да не может быть отрицательным. Только операции в конце цепи опера­ций (обычно там, где есть операции слияния) могут иметь свободный ре­зерв. Например, если единая цепь (путь) операций имеет резерв 14 дней, последняя операция будет иметь свободный резерв, а остальные — нет. Когда цепь не очень длинная, может быть только одна операция. Напри­мер, на сетевом графике бизнес-центра Колла (рис. 4-9) операция Е имеет свободный резерв 165 рабочих дней (200 — 35 = 165).

Операции С и D также имеют свободный резерв, 5 и 10 дней соответ­ственно. Привлекательность свободного простоя в том, что изменение сро­ков начала и завершения для операции со свободным простоем требует меньше координации с другими участниками проекта и дает руководите­лю проекта больше гибкости, чем при полном простое. Поскольку опера­ция является последней операцией в цепи, замедление операции до про­стоя не повлияет на последующие операции.

 

Небольшие проекты

В малых проектах, которые строго контролируются и где участники четко понимают, что они часть команды, можно сократить уровень под­робных описаний благодаря большему вниманию на стадии выполнения. Упор при этом, как правило, делается на работе, по которой предстоит отчитываться. При этом используется упрощенная матрица распределения работ (матрица ответственности) (см. рис. 4-10). Набор работ автоматичес­ки становится операцией, выполнение которой возлагается на одно из под­разделений организации. Однако, если продолжительность операции пре­вышает 5 рабочих дней, то становится необходим четкий план контрольных точек через более короткие интервалы времени. Такой подход возможен для малых проектов, где координация достаточно легко осуществима. Мат­рица ответственности подробно обсуждается в главе 7.

Мат­рица ответственности
Задача	Член проектной группы
	Управляющий проектом	Оценщик / Монитор	Преподаватель	Разработчик курса	Техническая поддержка
Оценка содержания относительно улучшения компетенции при обучении
Создать структуру обучения	A	R	C	-	-
Обучение слушателей	-	R	-	-	-
Обсуждение ответов	-	R	-	-
Составление отчетов	A	R	-	-
Обсуждение отчетов в период еженедельных собраний	P	P	P	P	P
Пересмотр содержания учебных материалов	A	C	P	R	C
Одобрение оценки	A	-	-	-	-

A – Письменное разрешение; R – Ответственность; P – Участие; C – Комментарии

 

 

	Работы
Системные спецификации	Программирование	Руководство пользователя	Формы	План соединения	Обучение персонала	Тестирование
Подразделение сотрудник
Инженерно – конструкторский отдел	R	A					C
Иванов		C			C
Петров	C	R	A	A	A
Сидоров					R
Иззетов							R
Аблямитов				A		A
Цинн-Ель				A		R
Отдел документирования			R	R			C
Обозначения: R - Ответственность C - Участие A - Совет

Рис. 4-10. Пример матрицы распределения ответственности по проекту кон­версии программного обеспечения

СВОБОДНЫЕ ОКОНЧАНИЯ

Ошибки сетевой логики

Методы построения сетевых графиков имеют определенные логичес­кие правила, которые необходимо строго соблюдать. Одно из правил гла­сит, что заявления типа «если испытание прошло успешно, стройте прото­тип, если неудачно — разработайте проект заново» не допускаются. Сете­вой график — это не дерево решений; это план проекта, который должен быть осуществлен. Если бы условные заявления допускались, то прямой и обратный анализ вряд ли имели бы смысл вообще. Хотя в действительнос­ти план редко осуществляется во всех деталях, так как мы его задумали, мы лишь можем предполагать это. Однако вы легко убедитесь в том, что если план разработан, то его можно пересматривать и изменять.

Другое явление, которое нарушает структуру сетевого графика и ло­гику процесса вычислений, — это зацикливание. Зацикливание — это по­пытка вернуться с более поздних операций к ранним. Запомните, что у последующих операций порядковый номер всегда должен быть выше, чем у предшествующих; это правило помогает избежать нарушения логики предшествования—следования операций. Операция должна выполняться только один раз, а если она повторяется снова, операция должна иметь новое название и номер и должна располагаться в соответствующей пос­ледовательности в сети. Рис. 4-11 показывает нелогичную петлю. Наличие таких петель привело бы к постоянному повторению пути. Многие про­граммисты понимают этот тип логической ошибки.

 

 

Рис. 4-11. Петля, нарушающая логику построения сетевого графика

 

Нумерация операций

Каждая операция требует своего собственного кода — как правило, номера. На практике существует достаточное число весьма элегантных схем. В большинстве таких схем операции нумеруются в порядке их возра­стания, то есть каждая последующая операция имеет больший номер, что указывает на приближение проекта к завершению. Принято оставлять пробелы между цифрами (1, 5, 10, 15...). Это желательно делать, чтобы вы могли позднее добавить пропущенные или новые операции. Так как почти невоз­можно с первого раза выстроить совершенный сетевой график проекта, нумерация сетей часто не делается до тех пор, пока сеть не завершена. На практике вы можете столкнуться и с компьютерными программами, кото­рые допускают как цифровое, так и алфавитное или комбинированное обо­значение операций. Комбинированное обозначение часто используется для обозначения стоимости, рабочих специальностей, отделов и расположения. Как правило, система нумерации операций должна быть восходящей и как можно проще. Смысл заключается в том, чтобы участники проекта могли легко следить за работой и узнавать конкретные операции.

 

Рис. 4-12. Air control inc. Проект индивидуального заказа. Сетевой график

 

Рисунок 4-12 представляет общий результат ОУ для проекта «проект индивидуального заказа». Критический путь обозначен затемненными пря­моугольниками и пунктирными стрелками, показывающими зависимость соответствующих операций. Описание операции дано в правом верхнем углу. Сразу же под номером операции приведена ее продолжительность, а под ней — сроки выполнения операции — ES, EF, LS, LF (читается сначала верхний ряд, затем нижний)

 

Рис. 4-13. Air Control Inc. Проект индивидуального заказа. График Ганга

 

Рис. 4-13 представляет график Ганта, построенный на основании ин­формации о ранних началах выполнения операций. Такие графики доста­точно популярны, так как дают четкую и понятную картину проекта в при­вязке к временной шкале. Они применяются во время планирования, со­ставления расписания ресурсов и отчетов о ходе работ. График Ганта привязан к двум осям на плоскости. По оси ординат располагаются опера­ции в порядке возрастания их номеров, а по оси абсцисс откладывается временной горизонт.

Например, «разработка программного обеспечения» имеет продолжи­тельность 18 (затемненные области на графике). Столбец также показыва­ет, что операция может начаться во временной период 2, закончиться в период 20, но может завершиться и позже в период 40, потому что у нее есть резерв времени, равный 20 (чистая область в столбце). Когда на вре­менной оси проставляются календарные даты, график Ганта дает еще бо­лее ясную картину выполнения проекта, и его можно повесить на стене в офисе.

Основным недостатком графика Ганта является отсутствие видимой взаимосвязи между операциями проекта. Например, если резерв времени выполнения операции используется на ранней стадии сетевого графика, он уже не может быть использован на последующих стадиях в той же це­почке операций. Эта зависимость на графике Ганта не отражается. Поэто­му график Ганта всегда используется вместе с сетевым графиком. Хотя некоторые компьютерные программы строят графики Ганта и с линиями зависимости. Но на реальных проектах этих линий появляется так много, что они перечеркивают главное достоинство этих графиков — наглядность. Заметьте, что график Ганта является производной от сетевого графика, но не наоборот.

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

 

Календарные даты

В итоге вы захотите определить календарные даты по всем операци­ям проекта. Если компьютерная программа не используется, даты про­ставляются вручную. Запланируйте календарные рабочие дни (исклю­чив нерабочие) и пронумеруйте их. Затем соотнесите календарные ра­бочие дни с рабочими днями в сети проекта. Большинство компьютерных программ распределяет календарные даты автоматически, после того как определены стартовая дата, единица времени, нерабочие дни и другие данные. На рис. 4-14 показан сетевой график заказа на индивидуаль­ный проект с датами.

 

Рис. 4-14. Air Control Inc. Проект индивидуального заказа — сетевой график с датами

Ступенчатый метод

Предположение, что все предшествующие операции должны быть завершены на 100%, не всегда может оправдаться на практике. Очень часто этого не происходит из-за того, что выполнение одной операции перекрывает начало другой. По условиям выстраивания отношений по типу «от конца к началу», если операция продолжительна и задержива­ет начало непосредственно следующей за ней операции, ее можно раз­бить на части и начертить сеть, используя ступенчатый метод, чтобы последующая операция могла начаться быстрее, не задерживая надолго общую работу. Разбивка на части продолжительных операций ведет к появлению ступенек на сети, о чем говорит и название метода. Класси­ческим примером, который приводится во многих книгах и статьях, яв­ляется пример с прокладкой трубы. Нужно выкопать траншею, уложить в нее трубу, засыпать траншею. Если длина трубопровода 1 миля, нет необходимости рыть траншею длиной в милю, прежде чем начнется зак­ладка труб, или заложить 1 милю трубами, прежде чем начнется засып­ка траншеи. Рис. 4-15 показывает, как эти перекрывающие операции могут появиться в сети ОУ.

 

 

Рис. 4-15. Пример использования ступенчатого метода с отношениями «от конца к началу»

Использование задержек (лагов)

Для достижения большей гибкости при разработке сетевых графиков было придумано использование задержек (лагов). Лаг — это минимальное количество времени, на которое может быть отложено начало или окон­чание зависимой операции. Лаги используются в сети проекта по двум ос­новным причинам:

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

2. Лаги могут использоваться для ограничения времени начала и окон­чания операции.

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

Отношения типа «от конца к началу». В начале главы был описан наиболее типичный, общий стиль отношений между операциями в сете­вом графике «от конца к началу». Однако бывают такие ситуации, когда последующая операция в цепочке должна быть задержана, даже если пред­шествующая операция завершена. Например, выемка бетонных форм не может начаться, пока залитый цемент не будет выдержан в течение двух единиц времени. Рис. 4-16 показывает этот лаг для сетевого графика ти­па ОУ. Лаги в отношениях «от конца к началу» часто используются при отображении операций, связанных с заказами ресурсов. Например, может потребоваться 1 день для того, чтобы сделать заказ, но 19 дней, чтобы дож­даться его исполнения. Использование отношений «от конца к началу» дает возможность иметь продолжительность операции — 1 день и лаг — 19 дней. Такой подход увязывает стоимость операции только с размещением зака­за, а не со стоимостью операции за 20 дней работы. Такие же отношения финиш — старт полезны и для описания транспортных, юридических и почтовых лагов.

 

 

Рис. 4-16. Отношения «от конца к началу»

 

Использование лагов в отношениях «от конца к началу» должно быть тщательно выверено и обосновано. Известно, что консервативные менед­жеры проектов и те, кто отвечает за завершение операций, использовали лаги, как средство для создания экономического («дополнительного») фак­тора для уменьшения риска запаздывания. Простое правило, которому надо следовать, состоит в том, что использование лагов финиш — старт должно быть обосновано и одобрено тем, кто отвечает за большой раздел проекта. Закономерность использования лагов обычно нетрудно понять. Законное использование дополнительных отношений может значительно повысить качество сети, давая более точное представление о проекте.

Отношения «от начала к началу». Альтернативой делению опера­ций является использование отношений типа «от начала к началу». Ти­пичные отношения «от начала к началу» показаны на рис. 4-17. На рис. 4-17 А показаны отношения старт—старт с нулевым лагом, тогда как на рис. 4-17 В показаны те же самые отношения с лагом 5 единиц времени. Важно отметить, что эти отношения могут использоваться как с лагом, так и без него. Если устанавливается время, то это обычно показано с помо­щью стрелки зависимости в сети AON. На рис. 4-17 В операция Q не может начаться раньше, чем пройдет время в 5 единиц после начала операции Р. Этот тип отношений обычно отражает ситуацию, в которой часть опера­ции может быть выполнена и следующая операция начата, хотя первая еще не завершена.

 

A	B

 

Рис. 4-17. Отношения «от начала к началу»

 

Эти отношения могут применяться в проекте по прокладке труб. На рис. 4-18 показан проект с сетевым графиком типа ОУ. Отношения «от на­чала к началу» уменьшают уровень детализации сети и отставание проек­та, используя задержки.

 

Рис. 4-18. Использование лагов для сокращения уровней детализации описания проекта

 

Можно найти возможности сжатия графика, изменив отношения «от конца к началу» на отношения «от начала к началу». Пересмотр отноше­ния «от конца к началу» между критическими операциями открыл возмож­ности запараллеливания работ с использованием отношений типа «от на­чала к началу». Например, вместо операций, связанных отношением типа «от конца к началу» «сначала проектирование дома, затем закладка фун­дамента», можно установить, что «закладка фундамента» начинается, ска­жем, через 5 дней (лаг) после начала проектирования, допустив, что проек­тирование фундамента дома является первым этапом всей операции про­ектирования. Отношения типа «от начала к началу» с небольшим лагом дают возможность осуществлять последовательные операции параллель­но и сокращать общую продолжительность критического пути. Такой под­ход часто используется в строительных проектах, когда одновременно про­водятся проектно-конструкторские и строительные работы для ускорения выполнения проекта в целом. При одновременном выполнении проектно-конструкторских и строительных работ операции разбиваются на более мелкие части, чтобы работа могла проводиться параллельно, и проект мог быть ускорен. Отношения типа «от начала к началу» могут отражать одно­временные конструкторские условия и уменьшать необходимый уровень детализации сетевого графика. Такой же результат может быть получен с помощью разбивки операции на небольшие наборы, которые могут осу­ществляться параллельно, но этот подход значительно увеличивает размер сетевого графика.

Отношения «от конца к концу». Этот тип отношений можно видеть на рис.4-19. Окончание одной операции зависит от окончания другой, На­пример, испытания не могут завершиться раньше, чем через 4 дня после завершения работ над прототипом.

 

Рис. 4-19. Отношения «от конца к концу»

 

Отношения «от начала к концу». Эти отношения представляют си­туацию, когда завершение одной операции зависит от начала другой опе­рации. Например, документирование системы не может быть заверше­но, пока не пройдут три единицы времени после начала испытания см. рис. 4-20).

 

Рис. 4-20. Отношения «от начала к концу»

Комбинация отношений задержки. Одна и та же операция может оказаться связанной с другой сразу несколькими отношениями задержки разных типов. Это обычно комбинация отношений типа «от начала к нача­лу» и «от конца к концу». Например, отладка программного обеспечения не может начаться, пока не пройдут две единицы времени после начала написания кода программы. Кодирование же должно завершиться за 4 еди­ницы времени до окончания отладки (см. рис. 4-21).

 

Рис. 4-21. Комбинация отношений задержки

Пример использования отношений задержки — прямой и обратный анализ

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

Результаты прямого и обратного анализа представлены на рис. 4-22. Операции С и D зависят от начала операции В («от начала к началу»). На­чало операции С должно задержать начало операции В на 10 единиц вре­мени, а начало операции D должно отложить начало операции В на 5 еди­ниц времени. Операция Е должна задержать окончание операции С на 5 единиц времени («от конца к концу»). Операция G не может завершить­ся, пока не пройдет 10 единиц времени после начала операции F («от начала к концу»). И, наконец, окончание операции Н зависит от завершения операции G на 10 единиц времени.

Обратите внимание на то, что операция может иметь критическое окончание или начало. Операция Н имеет критическое окончание (нуле­вой резерв времени) в 50 единиц времени, но эта же операция имеет нача­ло с 5 единицами резерва. Критическим для операции Н является только окончание. И наоборот, операция F имеет нулевой резерв времени начала ее выполнения, но вместе с тем имеет 5 единиц резерва у окончания. Кри­тический путь показан пунктирной линией.

Если отношения задержки имеют место, необходимо проверить каж­дую операцию на наличие ограничений по ее началу и окончанию. Напри­мер, при прямом анализе EF операции G (40) регулируется началом опера­ции F и задержкой в 10 единиц времени (30+ 10 лагов = 40). EF (40 + 10 ла­гов = 50) операции Н зависит от окончания операции G и лага 10, кото­рый — 50, а не 45 единиц. При обратном анализе становится очевидным, что LS операции F ограничивается LF (40) операции G и лагом в 10 единиц времени (40 — 10 лагов = 30), что приводит к LS = 30 для операции F.

 

 

Рис. 4-22. Сетевой график с отношениями задержки

 

Операции растяжки

Другим распространенным приемом при построении сетевых графи­ков является включение подвесных операций. Основная цель каждой та­кой операции — обозначить использование зафиксированных ресурсов или фиксированную стоимость в конкретном сегменте проекта. Типичным примером являются расходы по обслуживанию, консультированию или услуги по управлению строительством. Продолжительность подвесной операции устанавливается равной промежутку времени между охватыва­емыми ею операциями. Например, в части выполнения комплексного про­екта проведения выставки-ярмарки может потребоваться специальная цветная копировальная машина. Подвесная операция может быть включе­на в сетевой график для того, чтобы идентифицировать потребность в дан­ном виде ресурса и добавить его стоимость к стоимости всего сегмента дан­ного проекта.

Эта подвесная операция связана с началом первой операции сегмента проекта, где используется цветная копировальная машина, и концом пос­ледней операции того же сегмента. Ее продолжительность будет состав­лять разницу между EF последней операции и ES первой операции. Про­должительность вычисляется в результате прямого анализа и, следователь­но, не влияет на время других операций. Рис. 4-23 дает пример включения подвесной операции в сетевой график. Продолжительность этой операции определяется ранним началом операции В и ранним окончанием операции F, то есть разницей между 13 и 5 или 8 единицами времени. Продолжительность подвесной операции изменится, если любые ES или EF в цепочке охватываемых ею операций изменятся.

Подвесные операции часто включаются в сетевой график для агре­гирования его разделов. Это что-то наподобие разработки подсети, но при этом общая очередность выполнения операций остается нетрону­той.

 

 

Рис. 4-23. Операция растяжки

 

ВЫВОДЫ

Многие руководители проектов полагают, что сетевой график — это наиболее важный документ планирования проекта. Сетевой график опре­деляет последовательность и временные границы работ, используемые ресурсы и стоимость. Для разработки сетевого графика используются дан­ные, полученные в результате анализа наборов работ по проекту. Любой менеджер проекта должен иметь хорошее представление таком методе построения сетевого графика, как ОУ. Метод ОУ использует блоки для обозначения операций и стрелки для обозначения их за­висимости. Прямой и обратный анализ позволяют определить раннее и позднее время начала и окончания выполнения операций и наступления событий. Хотя большинство менеджеров проекта сегодня пользуется компьютерами при разработке сетевых графиков и определении их временных параметров, тем не менее, они должны прекрасно разбираться и в теории этих вопросов. Менеджеры проектов, хорошо знакомые с ос­новами построения и анализа сетевых графиков, будут иметь гораздо меньше проблем в своей деятельности, чем те, кто целиком и полностью полагается только на компьютер. Сетевой график помогает избегать неожиданностей.

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

Подвесные операции используются для отслеживания затрат ресурсов используемых на определенном участке проекта. Они могут также ис­пользоваться для сокращения размера сети проекта путем группировки ряда операций.

Вопросы для повторения

1. Чем отличается структура распределения работ от сетевого графи­ка проекта?

2. Как связаны структура распределения работ и сетевой график про­екта?

3. Зачем надо разрабатывать структуру распределения работ? Поче­му бы не перейти сразу же к построению сетевого графика, минуя структуру распределения работ?

4. Почему знание резервов времени имеет значение для менеджера проекта?

5. Почему при построении сетевых графиков иногда пользуются от­ношениями задержки?

6. Что такое подвесная операция и когда она используется?

Упражнения

Операция

 

Операция	Продолжительность	Предшествующая
А		Нет
В		Нет
С		А
D		А
Е		В
F		С
G		Е
Н		D, Е, F
I		G

 

7. На основании следующей информации постройте сетевой график типа ОУ. Выполните его прямой и обратный анализ, рассчитайте резервы времени операций и определите критический путь.

ID	Операция	Предшествующая	Время
А	Проверка заказа	Нет
В	Заказ стандартных деталей	A
С	Изготовление стандартных деталей	A
D	Проектирование нестандартных деталей	A
Е	Разработка программного обеспечения	A
F	Производство нестандартного оборудования	C, D
G	Сборка	B, F
Н	Тестирование	E, G

8. Джеймс Волд, менеджер проекта Print Software, Inc. хочет, чтобы вы разработали сетевой график проекта: рассчитали раннее, позднее время начала и окончания операций, резервы времени их выполнения, опреде­лили плановую продолжительность проекта и критический путь. Его асси­стент собрал следующую информацию для проекта Color Printer Drivers Software.