Вовремя и в рамках бюджета - Лоуренс Лич

1.6. Найдите критическую цепь — самую длинную последовательность зависимых событий.

2. Найдите способ снизить влияние критической цепи.

2.1. Просмотрите ваш план, проверьте, можно ли, поменяв последовательность выполнения работ, сократить общую длительность. Если можно, внесите соответствующие коррективы. Не позволяйте испытывать различные варианты методом проб и ошибок.

2.2. Добавьте проектный буфер в конец критической цепи.

3. Подчините все операции, цепочки и ресурсы нуждам критической цепи.

3.1. Используйте механизм защиты критической цепи: добавьте буферы ко всем цепочкам работ, которые сливаются с критической цепью (буферы на слияние путей). Определяя размер буферов, ориентируйтесь на самую длинную из вливающихся цепочек. (Обратите внимание: чтобы проект завершился, все пути в конце концов сольются с критической цепью. Если последовательность операций «впадает» непосредственно в проектный буфер, к ней тоже необходимо добавить буфер на слияние путей.)

3.2. Снимите все конфликты ресурсов, появившиеся после добавления буферов, путем перепланирования операций на более ранние сроки.

3.3. Соответственно сдвиньте на более ранние сроки операции, предшествующие тем, которые вы только что перепланировали.

4. Сократите общую длительность проекта, используя дополнительные ресурсы на определенных участках, чтобы снять конфликты.

5. Возвращайтесь на этап 1, не позволяя инерционности мышления стать ограничением.

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

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

На рис. 6.1 дан небольшой пример работы с критической цепью. Вы видите классический график СРМ типа «ранний старт». Первая цифра в каждом прямоугольнике — идентификатор операции из иерархической структуры работ. Вторая цифра — в скобках — показывает длительность операции в днях. Обратите внимание, что операция 3 зависит от завершения операций 1.2 и 2.2.

Как описано в процедуре, в первую очередь мы должны сократить длительность операций до значения с вероятностью 50% и перенести все работы на максимально поздний срок, учитывая зависимость операций в диаграмме (рис. 6.2).

Далее мы добавляем проектный буфер и буферы на слияние путей. Поскольку исполнитель (ресурс) у всех операций один, в данном проекте нет необходимости добавлять ресурсный буфер (рис. 6.3).

Теперь рассмотрим тот же небольшой проект, но уже с конфликтом ресурсов. Рис. 6.4 показывает последовательность операций в виде диаграммы PERT и без временной шкалы. Необходимые ресурсы в диаграмме обозначены разными цветами. Под этими цветами можно понимать, например, различные профессии (инженер, музыкант, оператор станков и т. п.).

Чертим диаграмму, сдвигая все операции на максимально поздние сроки. В данном случае необходимо лишь добавить ограничение «начало как можно позднее» к операции 2.1.

Затем устраняем конфликт ресурсов, двигаясь с конца проекта к началу (рис. 6.5).

На рис. 6.6 дается два способа снятия конфликта за ресурс «зеленый». Посмотрите, в каждом графике отображается новый тип зависимости от ресурса-ограничения. Какой из способов предпочтительней? На первый взгляд может показаться, что второй — нижний, поскольку последовательность операций получается короче. Во втором случае длина обеих цепочек одинакова, так что любую можно выбрать в качестве критической. А теперь добавьте в оба расписания проектный буфер и буферы на слияние путей и посмотрите, что получится.

На рис. 6.7 показан план, полученный после применения первого способа снятия борьбы за «зеленый» ресурс. В критическую цепь вошли все операции, кроме операции 2.1. Размер буферов на слияние путей определяем как 50% от общей длительности работ пути, впадающего в критическую цепь.

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

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

На основе рис. 6.9 постройте план критической цепи со всеми соответствующими буферами. Первая строка в каждом квадратике — номер операции. Вторая — ресурс, обозначенный цветом. Третья — длительность операции в днях (уже сокращенная). (Чтобы проверить приблизительную длительность расписания, которое должно у вас получиться, смотрите последний вопрос раздела 6.10. Учтите: приемлемый вариант критической цепи может отличаться от критического пути лишь на небольшой процент от величины буфера проекта.

На рис. 6.10 дана диаграмма проектных работ следующего, более сложного примера. Верхняя строка в каждом квадратике — идентификатор операции. Цвет обозначает необходимый тип ресурса. Цифры в нижней строке показывают длительность операции в днях. Длительность взята с 50%-ной вероятностью.