Как используются результаты прямого и обратного анализа сетевого графика

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

Знание сроков выполнения операций ES, LS, EF и LF также весьма цен­но для планирования, составления расписания и контроля на всех этапах проекта. ES и LF показывают менеджеру проекта временной интервал, в течение которого операция должна быть завершена. Например, операция Е должна быть выполнена в интервале 20—200 рабочих дней; операция мо­жет начаться на 20 и завершиться на 200 день. И наоборот, операция F (одоб­рение комиссии) должна начаться на 20-й день, иначе выполнение проек­та задержится.

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

УРОВЕНЬ ДЕТАЛИЗАЦИИ ОПЕРАЦИЙ

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

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

В малых проектах, которые строго контролируются и где участники четко понимают, что они часть команды, можно сократить уровень под­робных описаний благодаря большему вниманию на стадии выполнения. Упор при этом, как правило, делается на работе, по которой предстоит отчитываться. При этом используется упрощенная матрица распределения работ (матрица ответственности) (см. рис. 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. Пример матрицы распределения ответственности по проекту кон­версии программного обеспечения

Партнерство или совместная работа с подрядчиками в одной команде

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

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

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

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

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

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

 

 

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

 

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

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