— Не спешите, — говорю я. — Вернемся к вашей диаграмме. Что здесь является критическим путем?
— Я не знаю, — отвечает он. — Если я должен принять во внимание ограниченную мощность X, то не знаю.
Я вижу свет.
— Вернемся к определению критического пути, — уверенно говорю я. — Самая длинная цепь зависимых элементов, самая длинная по времени. Нельзя игнорировать ограниченную мощность X. Нельзя игнорировать тот факт, что могут существовать зависимости между двумя элементами, потому что они выполняются тем же самым ресурсом, который имеет ограниченную мощность, и таким образом вы не можете делать два элемента одновременно, вы должны их делать последовательно, а не параллельно. Это зависимость.
— И все же, что здесь является критическим путем?
— Это вы мне должны сказать, — теперь я обращаюсь ко всему классу. Джим лихорадочно записывает.
— Мы не можем начать с X — говорит Рут, — поэтому нам надо откуда-то начинать. X тут же становится проблемой и определяет все время исполнения. Когда мы закончим с X, мы еще не закончим проект, там еще элементы, которые мы должны выполнить.
— Именно, — говорю я. — Зависимости между элементами могут возникнуть в результате пути или в результате общего ресурса. Почему нас так удивляет, что оба типа зависимостей определяют самую длинную цепь зависимых элементов?
Кажется, они согласны.
— В целом, — продолжаю я, — самая длинная цепь будет состоять из отрезков, зависящих от пути, и отрезков, зависящих от ресурса.
— Тогда, если мы будем придерживаться определения критического пути, мы получим то, что никто не называет критическим путем? — Брайен удивлен.
— И чему ты так удивляешься? — говорит Тед. — Все остальное, что мы делаем, тоже не типично.
— Согласен. Но, думаю, лучше, если мы сделаем поправку в терминологии. Давайте оставим критический путь как то, что все знают под названием «критический путь», то есть самый длинный путь. Но мы знаем, что самое важное — это ограничение. И ограничением является самая длинная цепь зависимых элементов. Поскольку мы признаем, что зависимость может возникнуть в результате ресурса, нам лучше использовать другое название для цепи элементов, являющейся ограничением.
— А почему бы не назвать ее «критическая цепь»? — предлагает Брайен.
Звучит хорошо.
— Итак, это будет «критическая цепь», — твердо объявляю я, чтобы избежать потока других, еще более странных предложений. Я знаю, как люди любят спорить об именах, а я вдруг замечаю, что у меня осталось очень мало времени. А нам еще надо сформулировать выводы, вытекающие из нашего нового понимания. Мы не можем ограничиться только изменением в терминологии.
— Давайте вернемся к примеру Чарли, — говорю я. — Еще раз: что здесь является критической цепью? — мне нравится это новое название. — Рут?
— Не знаю, — говорит она. — Здесь пять элементов, которым нужен ресурс X. В какую последовательность мне их поставить? Я не знаю.
— У кого-нибудь есть идеи? — спрашиваю я.
Людям нравятся задачи подобного типа. Предложения несутся со всех сторон. Как и должно быть, многие из них противоречат друг другу. Я сражаюсь с собой, чтобы не прервать эту бесполезную дискуссию. Она становится все более и более запутанной, и они все больше и больше сбиты с толку. Очень хорошо. Через пятнадцать минут я решаю, что они готовы.
— Сколько будет восемью восемь? — спрашиваю я.
Все молчат. Они, очевидно, подозревают, что со мной не все в порядке.
— Позвольте вам напомнить, что в проектах мы имеем дело не с детерминированными цифрами, — начинаю я объяснять им смысл моего вопроса. — Если мы скажем, что, к примеру, на исполнение элемента потребуется восемь дней, разве мы на самом деле имеем в виду, что это займет точно восемь дней?
Я записываю на доске «(8±1) x (8±1) =?»
— Ответ «шестьдесят четыре» неверен. Он дает ошибочное впечатление точности.
— Это как бухгалтера просят дать ответ с точностью до цента, когда точность даже первой цифры вызывает сомнение, — замечает Фред.
— Верно, — мне нравится пример Фреда. — Все видят, как это связано с нашим спором?
Мне приходится им помочь:
— Когда данные неточны, пытаться дать точный ответ — это ошибка. Ответы, претендующие на то, чтобы быть более точными, чем неопределенность, заложенная в задаче, неверны.
Чарли видит связь:
— Вы хотите сказать, что нет разницы в том, в какой последовательности мы сделаем график работ для X?
— В некоторых случаях есть. На эту тему написаны бесконечные статьи. Вопрос только в том: есть ли действительная разница?
Было бы странно, если бы Рут не спросила:
— Что вы имеете в виду, говоря «действительная разница»?
— Разница, превышающая степень неопределенности в проекте, — говорю я.
И прежде чем она успевает задать вопрос на мой ответ, я делаю это сам:
— Что мы можем взять в качестве разумного измерителя неопределенности в проекте?
Я даю им время подумать.
— Буфер проекта? — неуверенно спрашивает Брайен.
— Почему?
Более уверенным тоном он отвечает:
— Потому что буфер проекта — это то, где мы гасим все аккумулированные эффекты неопределенности.
— Что вы думаете? — спрашиваю я у класса.
Они думают, что Брайен прав. Я тоже так думаю.
— Я даже не могу вам сказать, сколько я прочитал статей об оптимизации последовательности ресурсов, — говорю я им. — Больше, чем могу перечислить. Они содержат множество алгоритмов и эвристические правила для расчета последовательности ресурсов. Собранные вместе, эти статьи охватывают все вопросы, о которых вы сегодня говорили, и еще большее количество тех вопросов, о которых не говорили. Но я больше не выбрасываю время на то, чтобы их читать. Почему? Потому что в каждом случае эффект, оказываемый на время исполнения проекта, меньше, чем хотя бы половина буфера проекта.
Джим приподнимает одну бровь. Конечно, эти статьи не указывают размер буфера. Но его можно приблизительно определить с помощью правила «большого пальца»: исходя из того, что время оценки исполнения каждого элемента содержит подстраховку, буфер проекта составляет около одной четвертой времени исполнения. Я отмечаю у себя в голове, что должен не забыть это ему объяснить. Но поскольку студенты не будут читать эти академические статьи, я на этом не задерживаюсь и возвращаю обсуждение назад в русло нашей темы.
— Чарли прав, указывая, что мы должны учитывать конкуренцию за ресурсы. В некоторых проектах конкуренция за ресурсы слишком велика, чтобы питающий буфер мог ее поглотить. Но надо видеть разницу между принятием во внимание конкуренции за ресурсы и игрой в оптимизирование графика этих ресурсов.
