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

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

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

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

График «барабана» — это план привлечения ресурса-ограничения к работам по всем проектам, где он нужен. Ведет график обычно тот, кто отвечает за ресурс-ограничение. Ресурс-«барабан» — первоочередной фактор, который определяет возможность системы выполнять проекты.

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

Чтобы разработать график, менеджер «барабана» (так иногда называют составителя графика) должен располагать информацией о приоритетности всех проектов и их потребностях в данном ресурсе. В составленных методом критической цепи планах отдельных проектов содержатся данные о длительности операций, самой ранней дате начала и относительных датах всех работ критических цепей проектов. На рис. 7.3 дана схема (не график) требуемого вовлечения ресурса-«барабана» в три проекта, при этом внизу находится наиболее важный проект, а в самом верху — проект с самым низким приоритетом. График «барабана» должен охватить все три проекта, оставаясь в рамках возможностей ресурса. В нашем примере доступны два ресурса нужного типа (два исполнителя).

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

Идея в том, чтобы менее важные проекты откладывать на поздние сроки, когда для них будет отведено свободное окно ресурса-«барабана». Из этого и складывается график «барабана». Обратите внимание, что при составлении этого графика вы взяли из планов отдельных проектов среднеоценочную длительность операций. Поскольку нам хотелось бы быть максимально уверенными в том, что «барабан» будет доступен в нужный момент, необходимо заложить в график запас на реальную длительность. Для этого добавляем буфер на доступность ресурса БДР. Результат — на рис. 7.4.

БДР (The Capacity Constraint Buffer) обеспечивает доступность ресурса в тот момент, когда он требуется для проектных работ. Теоретически буфер помещается между операцией, где используется ресурс в предыдущем проекте, и первой операцией, для которой он понадобится в интересующем вас проекте. БДР влияет скорее не на общую продолжительность проекта, а на дату начала работы в нем данного ресурса.

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

В некоторых компьютерных программах заложена возможность указывать временные промежутки для выравнивания ресурсов (например, еженедельно или ежемесячно). Так вы сможете перераспределять ресурсы и не пытаться их выравнивать, пока в среднем спрос в данный период времени совпадает с предложением (имеющимися ресурсами). Это подходит для использования ССРМ, поскольку мы понимаем, что возникающие при этом в программе пересечения в реальности не наблюдаются, являясь просто последствием попытки передать объемную переменчивую действительность при помощи «плоских» графических средств.

При определении размера БДР нужно учитывать теорию очередей и методику выравнивания ресурсов. Теория очередей требует, чтобы буфер на доступность ресурса соответствовал как минимум 25% мощности ресурса, ограничивающего мощность системы. Иначе проекты начнут тормозить.