— Доброе утро, — здороваюсь с классом.
— Доброе утро.
— Доброе утро гостям, — я киваю в сторону Шарлен и Джима.
— Доброе утро, — отвечают они.
Десять секунд прошло. Не очень помогает. Надо начинать.
— Теперь, когда почти все из вас имеют практический опыт во внедрении того, что мы изучаем, — начинаю я, — я бы хотел вернуться к концепциям и еще раз в деталях рассмотреть их.
Им нравится эта идея.
Прежде чем я успеваю продолжить, поднимает руку Рут:
— У меня возникла проблема в области концепций.
Вот это заявление. Особенно от Рут. Ничего хорошего. Я стараюсь не смотреть в сторону Джима.
Прилагая все усилия к тому, чтобы звучать уверенно, я спрашиваю:
— И в чем проблема?
— Предположим, что на одном из критических путей мы настолько опаздываем, что уже использовали весть питающий буфер и начали потреблять буфер проекта. На критическом пути у нас все в порядке.
— Может случиться, — подтверждаю я. — Вы можете столкнуться с серьезной проблемой на одном из питающих путей. Но вы сказали, у вас концептуальная проблема. В чем она заключается?
— В ситуации, описанной Рут, — включается в разговор Фред. — Разве не является очевидным, что критический путь изменился? Что теперь критический путь начинается от операции, в которой возникла проблема?
Я думаю над тем, что они сказали. Прежде чем я успеваю прийти к заключению, с пояснением вмешивается Марк:
— Мы определили критический путь как самую длинную цепь зависимых элементов; самую длинную по времени.
— Правильно.
— Рут говорит о ситуации, когда мы работаем с элементом — назовем его элемент N, который находится на пути, который мы считаем некритическим. Однако в данный момент N опаздывает настолько, что он вызывает самое большое проникновение в буфер проекта. Не означает ли это, что в данный момент самая длинная цепь — длинная по времени — начинается в элементе N?
— Что ты хочешь сказать? — вмешивается Тед. — Что в середине проекта мы должны поменять критический путь? Это сумасшествие.
— Почему? — спрашиваю я. Я знаю, почему. Я также вижу, почему это необходимо. Но мне нужно выиграть время, чтобы успеть подумать.
Тед не знает, что сказать. У него отличная интуиция, но он не может так быстро выразить ее словами. За него отвечает Фред. Я догадываюсь, что «фабрика мысли» серьезно над этим думала.
— Мы вводим питающие буферы только в тех точках, где некритический путь вливается в критический. Изменение критического пути потребует изменения месторасположения многих питающих буферов.
— А это, — подхватывает Тед, — внесет неразбериху во весь проект. Этого нельзя делать.
— Согласна, — спокойно говорит Рут. — Но с другой стороны, ты разве не видишь, что произойдет, если мы этого не сделаем.
— Нет! — выстреливает Тед. Мысль о необходимости все полностью перестраивать каждый раз, когда мы столкнемся с серьезным опозданием на некритическом пути, его пугает. Меня тоже.
— Если мы этого не сделаем, это будет означать, что мы игнорируем действительность. Давайте признаем: нравится нам это или нет, но сейчас критический путь начинается в элементе N. И этот путь не защищен питающими буферами от нарушений на других путях. И не защищен ресурсными буферами. А это уменьшает вероятность того, что ситуация поправится. Наоборот, возникает высокая вероятность того, что опоздание увеличится. Вы разве не видите, что мы должны перестроить проект?
— Мы пропали, если мы это сделаем, и пропали, если не сделаем, — подводит итог Тед.
— Это и есть наша концептуальная проблема, — говорит Рут.
Я с трудом контролирую охватывающую меня панику. Концептуальная проблема? Концептуальная проблема! Это мягко сказано. Это может разрушить все, что мы создали!
Почему мы не столкнулись с этим в реальности? Четыре проекта закончились значительно раньше, чем ожидалось. Так что наш метод работает. Может быть, это потому, что все четыре проекта уже прошли значительную часть пути, когда мы начали внедрение нашего метода? Но во всех случаях у нас были питающие буферы, которые были полностью использованы. У нас была ситуация, которую описала Рут, так что проблема не может быть такой большой, как это кажется. Где «фабрика мысли» делает ошибочную исходную посылку?
У меня нет ни одной мысли. И времени тоже нет. Класс ждет. И не только класс. Джим тоже. Я поворачиваюсь к доске и начинаю строить тучу. Задача — закончить проект в срок. Одно необходимое условие — то, что сказал Тед: мы не можем позволить себе все перестраивать. Что означает: не менять критический путь официально.
Второе необходимое условие — то, что сказала Рут: мы не можем позволить, чтобы действительный критический путь оказался под угрозой, что означает, что мы должны поменять критический путь официально.
Я применяю трюк, которому меня научил Джонни: сконцентрировать внимание на той стрелке, которая нравится меньше всего. Так же как и Теду, мне не нравится перестраивать весь проект на полпути. Я не хочу официально менять критический путь. Это ломает всю элегантность решения и делает его непрактичным. Кроме того, мы не делали этого в проектах, с которыми мы уже работали. Итак, какова тут исходная посылка?
Для того чтобы не оставить действительный критический путь под угрозой, мы должны поменять критический путь официально. Почему? Потому что если мы этого не сделаем, критический путь будет не защищен. Так ли это на самом деле? Я знаю ответ.
Уверенным голосом я спрашиваю класс:
— Какую исходную посылку мы делаем, когда утверждаем, что если мы не поменяем официально критический путь, он окажется под угрозой?
Поскольку они не отвечают, я задаю еще один вопрос:
— Очень ли отличаются друг от друга изначальный критический путь и действительный критический путь?
— Нет, — отвечает Рут. — Начиная от точки, в которой они сливаются, и до конца проекта это тот же самый путь. Я понимаю. Тогда под угрозой только отрезок от элемента N до элемента, где они сливаются, но не включая этот элемент. В большинстве случаев это не будет включать дополнительных питающих буферов. Но что насчет ресурсных буферов, которые нам нужны для этих промежуточных элементов?
