Элияху Голдратт - Критическая цепь

Я записываю на доске «(8±1) x (8±1) =?»

— Ответ «шестьдесят четыре» неверен. Он дает ошибочное впечатление точности.

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

— Верно, — мне нравится пример Фреда. — Все видят, как это связано с нашим спором?

Мне приходится им помочь:

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

Чарли видит связь:

— Вы хотите сказать, что нет разницы в том, в какой последовательности мы сделаем график работ для X?

— В некоторых случаях есть. На эту тему написаны бесконечные статьи. Вопрос только в том: есть ли действительная разница?

Было бы странно, если бы Рут не спросила:

— Что вы имеете в виду, говоря «действительная разница»?

— Разница, превышающая степень неопределенности в проекте, — говорю я.

И прежде чем она успевает задать вопрос на мой ответ, я делаю это сам:

— Что мы можем взять в качестве разумного измерителя неопределенности в проекте?

Я даю им время подумать.

— Буфер проекта? — неуверенно спрашивает Брайен.

— Почему?

Более уверенным тоном он отвечает:

— Потому что буфер проекта — это то, где мы гасим все аккумулированные эффекты неопределенности.

— Что вы думаете? — спрашиваю я у класса.

Они думают, что Брайен прав. Я тоже так думаю.

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

Джим приподнимает одну бровь. Конечно, эти статьи не указывают размер буфера. Но его можно приблизительно определить с помощью правила «большого пальца»: исходя из того, что время оценки исполнения каждого элемента содержит подстраховку, буфер проекта составляет около одной четвертой времени исполнения. Я отмечаю у себя в голове, что должен не забыть это ему объяснить. Но поскольку студенты не будут читать эти академические статьи, я на этом не задерживаюсь и возвращаю обсуждение назад в русло нашей темы.

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

Чарли не спорит, он для этого слишком практичен. Вместо этого он спрашивает:

— Так что я должен делать?

— Устранить конкуренцию за ресурс, — отвечает Тед.

— Легко сказать.

Тед пытается объяснить, что это легко сделать, но его объяснение настолько запутано, что даже я его не понимаю.

— Может быть, вы подойдете к доске и покажете на графике Чарли? — предлагаю я.

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

— Отметьте, пожалуйста, критическую цепь, — прошу я.

Он рисует пунктирную линию.

— Поскольку вы изменили ограничение, вы должны в соответствии с этим изменить питающие буферы, — напоминаю я.

Он делает это с небольшой помощью класса.

Мы изучаем две диаграммы: изначальную диаграмму Чарли, показывающую критический путь, и диаграмму, которую нарисовал Тед. Разница существенная.

— Это отодвигает дату завершения, — озабоченно говорит Чарли.

— Нет, не отодвигает, — возражает Марк. — Это просто не позволяет тебе себя обманывать.

— Это понятно. Я имел в виду, что конкуренция за ресурс X отодвигает дату завершения. Мне надо будет проверить, что из его работы можно передать другим ресурсам.

— Или не другим ресурсам, а другому времени, — замечает Брайен.

Чарли смотрит на него непонимающим взглядом.

Брайен спешит объяснить:

— Ресурс X не загружен все время проекта. Если ты проверишь детали его работы, может оказаться, что часть работы может быть сделана намного раньше или позже. По своему опыту я знаю, что люди часто «формируют партии» работы одного типа не потому, что эта работа должна быть сделана именно тогда, а просто для экономии времени.

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

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

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

Я задаю этот вопрос классу и прошу их соотнести это с ситуацией в их проектах. Насколько серьезна конкуренция за ресурсы?

Меньше чем через десять минут мы делаем вывод: это зависит от проекта.

Для многих проектов это не имеет значения, поскольку конкуренция за ресурсы несущественна. Но для ряда проектов, и их довольно много, это имеет серьезное значение.

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

— Это может привести к катастрофам, — отвечает Чарли. — То, что случилось со мной. Критический путь начинает прыгать. Ты теряешь контроль.

— Даже еще хуже, — басит Марк. — Посмотрите на обе диаграммы на доске. Питающие буферы, уже не говоря о ресурсных буферах, находятся в неправильном месте. Ограничение не защищено.