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

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

При назначении исполнителей в компьютерной программе нужно принять несколько решений. Во-первых, определить, кого вообще вовлечь. Обычно необходимо указать конкретных людей, хотя программе, составляющей расписание, чаще всего все равно, вписываете ли вы в качестве ресурса человека или вид оборудования (например, подъемный кран) или учитываете какое-либо иное ограничение (люк подводной лодки или количество рабочих мест на каком-то участке). Показывать нужно лишь то, что, вероятнее всего, станет сдерживающим фактором для вашего расписания.

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

Метод эстафеты, используемый в ССРМ, подразумевает, что тех, от кого зависит длительность операции, вы назначаете только на выполнение данных работ. Занятость остальных можно расписать в разных долях, однако помните, что при выравнивании ресурсов результат может оказаться неожиданным. Компьютерная программа производит выравнивание по определенному алгоритму. Некоторые параметры этого алгоритма можно изменять, но затем программа будет неуклонно следовать заданным вами правилам. Так, если у вас есть исполнитель, временем которого вы можете распоряжаться на 100%, и вы назначаете его на две операции по 49% времени на каждую, при составлении графика компьютер может заложить параллельное выполнение этих операций. А если установите занятость 51%, программа вообще может спланировать начало второй операции только после завершения первой. (В некоторых программах можно производить выравнивание по задаваемым пользователем единицам времени, например дням, неделям или месяцам. Таким образом, сдвинется ли операция после выравнивания, будет зависеть от ее длительности, места в графике и загрузки исполнителя.) На рис. 5.5 приведен пример потенциальных неожиданных последствий выравнивания ресурсов. Что-то подобное наблюдалось на одном из проектов, где использовался метод критической цепи. Технари заявили, что ошибка в логике. Нет, с логикой все в порядке. Компьютер работает так, как его запрограммируют. В этом случае, вероятно, не следовало назначать ресурсы на операцию «проверка документа», если не предусматривалась полная занятость исполнителей на данной операции. В большинстве программ существует возможность вставлять примечания по каждой операции, где и можно было бы указать, кто будет проводить проверку. Обычно, экспериментируя в ходе работы, можно определить оптимальный способ моделирования загрузки по ресурсам в конкретных планах ваших проектов.

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

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

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

Рассмотрим тот факт, что средняя величина операции в плане (затраты на нее в долларах, длительность выполнения или время работы исполнителей) обратно пропорциональна количеству операций. Следовательно, средняя операция в плане из 100 операций составляет 1% от всего проекта. Поскольку параметры большинства операций нельзя оценить точнее, чем с вероятностью плюс-минус 50%, нет смысла делить проект на более мелкие составляющие.

Часто говорят, что недостаточно подробный план становится причиной провала проекта. Но когда проект заканчивается неудачно, речь идет о гораздо больших величинах, чем доли процента (так, затраты могут превышать плановые в два-три раза). Не логично заключать, что план, в котором 100 или чуть больше операций, недостаточно подробен и приведет к проблемам. Вряд ли вы обнаружите недостающие для полного счастья работы, нехватка которых привела к нарушениям на сотни процентов от нормы, если будете дробить далее операции, равняющиеся всего 1% от всего проекта. Проблема не в этом. И решение тоже.