Критическая цепь.

22.

Суббота. Утро. Я не могу решить, что мне делать с ними на сегодняшнем занятии. Изначально я планировал рассмотреть тему нескольких проектов, выполняемых общими ресурсами, один из которых является бутылочным горлышком. Я называю эту тему «бутылочное горлышко проектов». Без сомнения, это вызвало бы оживленную дискуссию. Она могла бы дать мне пару идей, как двигаться дальше. Но теперь это слишком опасно. На занятии будет Джим.

Он решил расширить свой курс по системам и внести в него раздел о проектах. Теперь ему «надо знать уровень знаний студентов». Что я мог ему сказать? Не приходи?

Я пробегаю по списку тем курса, который я подготовил еще летом. За исключением первых занятий то, что в нем написано, не совпадает с тем, чем мы занимаемся. Я пропустил много тем, и по веской причине. Многие называют эти темы академическими: оптимизация использования ресурсов, оптимизация последовательности, оптимизация инвестиций. Я называю их не имеющими отношения к делу. И все-таки, что я буду с ними сегодня делать?

Может, Джим заболеет? Не очень поможет. До конца года у меня еще четыре пары.

Я еще раз просматриваю список. Ничего.

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

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

Хорошая тема. Но сколько времени может на нее уйти? Полчаса? Мне только остается положиться на умение моих студентов долго бродить в потемках. Все равно других идей у меня нет. Сойдет.

— Доброе утро, — здороваюсь с классом.

— Доброе утро.

— Доброе утро гостям, — я киваю в сторону Шарлен и Джима.

— Доброе утро, — отвечают они.

Десять секунд прошло. Не очень помогает. Надо начинать.

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

Им нравится эта идея.

Прежде чем я успеваю продолжить, поднимает руку Рут:

— У меня возникла проблема в области концепций.

Вот это заявление. Особенно от Рут. Ничего хорошего. Я стараюсь не смотреть в сторону Джима.

Прилагая все усилия к тому, чтобы звучать уверенно, я спрашиваю:

— И в чем проблема?

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

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

— В ситуации, описанной Рут, — включается в разговор Фред. — Разве не является очевидным, что критический путь изменился? Что теперь критический путь начинается от операции, в которой возникла проблема?

Я думаю над тем, что они сказали. Прежде чем я успеваю прийти к заключению, с пояснением вмешивается Марк:

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

— Правильно.

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

— Что ты хочешь сказать? — вмешивается Тед. — Что в середине проекта мы должны поменять критический путь? Это сумасшествие.

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

Тед не знает, что сказать. У него отличная интуиция, но он не может так быстро выразить ее словами. За него отвечает Фред. Я догадываюсь, что «фабрика мысли» серьезно над этим думала.

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

— А это, — подхватывает Тед, — внесет неразбериху во весь проект. Этого нельзя делать.

— Согласна, — спокойно говорит Рут. — Но с другой стороны, ты разве не видишь, что произойдет, если мы этого не сделаем.

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

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

— Мы пропали, если мы это сделаем, и пропали, если не сделаем, — подводит итог Тед.

— Это и есть наша концептуальная проблема, — говорит Рут.

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

Почему мы не столкнулись с этим в реальности? Четыре проекта закончились значительно раньше, чем ожидалось. Так что наш метод работает. Может быть, это потому, что все четыре проекта уже прошли значительную часть пути, когда мы начали внедрение нашего метода? Но во всех случаях у нас были питающие буферы, которые были полностью использованы. У нас была ситуация, которую описала Рут, так что проблема не может быть такой большой, как это кажется. Где «фабрика мысли» делает ошибочную исходную посылку?

У меня нет ни одной мысли. И времени тоже нет. Класс ждет. И не только класс. Джим тоже. Я поворачиваюсь к доске и начинаю строить тучу. Задача — закончить проект в срок. Одно необходимое условие — то, что сказал Тед: мы не можем позволить себе все перестраивать. Что означает: не менять критический путь официально.

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

Я применяю трюк, которому меня научил Джонни: сконцентрировать внимание на той стрелке, которая нравится меньше всего. Так же как и Теду, мне не нравится перестраивать весь проект на полпути. Я не хочу официально менять критический путь. Это ломает всю элегантность решения и делает его непрактичным. Кроме того, мы не делали этого в проектах, с которыми мы уже работали. Итак, какова тут исходная посылка?

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

Уверенным голосом я спрашиваю класс:

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

Поскольку они не отвечают, я задаю еще один вопрос:

— Очень ли отличаются друг от друга изначальный критический путь и действительный критический путь?

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

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

— Ложная тревога, — извиняющемся голосом говорит Рут.

— Я так не думаю, — включается в обсуждение Чарли. — Я не думаю, что это ложная тревога.

— Почему? — спрашивает Марк.

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

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

Это серьезно. Я не обращаю внимания на Роджера. Все мое внимание направлено на Чарли. Он говорит не о возможной ситуации или неких обобщенных наблюдениях, а о реально существующей проблеме. Чарли, особенно после того, как его президент был настолько доволен результатами, не делал бы такого заявления, если бы ситуация действительно не вышла из-под его контроля.

— Чарли, вы не могли бы подробно описать нам, что происходит?

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

— Серьезный удар Мерфи? — сочувственно спрашиваю я.

— Это-то и странно, — отвечает Чарли, — нет никаких особых проблем, никаких сюрпризов, но мы начинаем отставать.

Теперь я ничего не понимаю. Класс тоже в недоумении.

— Чарли, давайте разберемся не спеша. Вы работаете с элементом N на некритическом пути и… Теперь расскажите нам, что происходит.

— Все еще более странно, — говорит он. — Я еще не начал работать с элементом N на некритическом пути, а этот некритический путь становится реальной проблемой. Ничего не делая, я использовал весь питающий буфер.

— Что ты хочешь сказать? — спрашивает за всех нас Тед.

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

— И где ресурс? — нетерпеливо спрашивает Тед.

— Работает на другом некритическом пути.

— Ну так переведи его.

— Не могу. Некритический путь, на котором он работает, тоже опаздывает.

— Чудеса, — хмыкает Тед. — Такого не может быть. Ты говоришь ерунду.

Лицо Чарли багровеет, но он сдерживается и не отвечает Теду. Он смотрит на меня и спрашивает:

— Я могу подойти к доске и показать ситуацию?

— Естественно.

Он начинает рисовать, поясняя:

— Это не мой проект, но это покажет вам мою проблему.

Через две минуты на доске готова диаграмма.

— Что означает «Х»? — спрашиваю я.

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

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

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

— Не спешите, — говорю я. — Вернемся к вашей диаграмме. Что здесь является критическим путем?

— Я не знаю, — отвечает он. — Если я должен принять во внимание ограниченную мощность Х, то не знаю.

Я вижу свет.

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

— И все же, что здесь является критическим путем?

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

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

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

Кажется, они согласны.

— В целом, — продолжаю я, — самая длинная цепь будет состоять из отрезков, зависящих от пути, и отрезков, зависящих от ресурса.

— Тогда, если мы будем придерживаться определения критического пути, мы получим то, что никто не называет критическим путем? — Брайен удивлен.

— И чему ты так удивляешься? — говорит Тед. — Все остальное, что мы делаем, тоже не типично.

— Согласен. Но, думаю, лучше, если мы сделаем поправку в терминологии. Давайте оставим критический путь как то, что все знают под названием «критический путь», то есть самый длинный путь. Но мы знаем, что самое важное — это ограничение. И ограничением является самая длинная цепь зависимых элементов. Поскольку мы признаем, что зависимость может возникнуть в результате ресурса, нам лучше использовать другое название для цепи элементов, являющейся ограничением.

— А почему бы не назвать ее «критическая цепь»? — предлагает Брайен.

Звучит хорошо.

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

— Давайте вернемся к примеру Чарли, — говорю я. — Еще раз: что здесь является критической цепью? — мне нравится это новое название. — Рут?

— Не знаю, — говорит она. — Здесь пять элементов, которым нужен ресурс Х. В какую последовательность мне их поставить? Я не знаю.

— У кого-нибудь есть идеи? — спрашиваю я.

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

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

Все молчат. Они, очевидно, подозревают, что со мной не все в порядке.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— И что случится тогда, известно всем, — подключается Тед. — Мерфи только этого и ждет.

— Стоит проверить все наши проекты, — говорит Фред. — Я уверен, что у нас есть конкуренция за ресурсы. И много.

— Отлично, — говорю я. — И что конкретно вы собираетесь делать?

За него отвечает Марк:

— Во-первых, мы добавим в РЕRТ названия ресурсов. Сейчас они указаны не во всех проектах. Потом мы… — он останавливается.

— Как мы сможем обеспечить, чтобы элементы, выполняемые ограниченными ресурсами, не были поставлены в график параллельно? — спрашивает Рут.

— Это моя проблема, — говорит Марк. — Вместо того чтобы рисовать элементы на бумаге, мы придумаем что-нибудь более мобильное. Например, для каждого элемента мы можем вырезать кусок бумаги так, чтобы его длина представляла время исполнения. И потом мы можем передвигать эти куски бумаги до тех пор, пока не устраним всю конкуренцию за ресурсы.

— Неплохая идея, — соглашается Рут. — Может быть, мы сможем найти подходящее программное обеспечение.

Я смотрю на часы.

— Продолжайте, — подбадриваю я их.

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

— Что случится, если обнаружатся несколько цепей, практически одинаковых по длине? — спрашивает Брайен.

Марк смотрит на меня.

— Выберите одну. Любую, — отвечаю я. — И для того чтобы доказать, что я прав, вот вам домашнее задание: возьмите ваш проект и сделайте с ним то, о чем мы говорили сегодня.

— Мы это в любом случае сделаем, — замечает Брайен.

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

Они выходят из аудитории. Джим подходит ко мне.

— Знаешь, твой стиль преподавания — это действительно что-то, — хвалит он меня. — Такое ощущение, будто новое знание создается прямо на глазах у студентов. Поразительно.

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