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

• Планировать начало операций по правилу «как можно позднее», соблюдение сроков защищается буфером. Это тоже подчинение операций нуждам ограничения, ведь в данном случае, как правило, в первую очередь запускается критическая цепь и не более одной-двух других цепочек работ.

• Работать в стиле «эстафеты». Не допускать многозадачности и проявления студенческого синдрома. Исполнитель принимается за операцию при первой же возможности, выполняет ее максимально быстро и сразу же передает готовый результат на следующий этап. Так мы начинаем устранять ограничение.

• Называть исполнителям длительность операции и примерную дату начала работы, но не даты ключевых событий. Таким образом мы ломаем устоявшуюся ориентацию на даты контрольных точек (парадигма «либо пан, либо пропал»). В этой ситуации у исполнителей нет стимула придерживать результат своей работы, и он сразу же передается на следующий этап. Это тоже способствует устранению ограничения.

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

На рис. 11.5 показаны прорывные события в том порядке, в каком они появляются в ДБР.

11.4.3. ДБР КАК РУКОВОДСТВО

ПО ПРОВЕДЕНИЮ ПРЕОБРАЗОВАНИЙ

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

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

В основе ДБР лежат перечисленные ранее прорывные события. Каждое из них сопровождается объяснением, почему именно оно видится нам необходимым и как оно может помочь.

11.4.4. ЦИКЛЫ ОБРАТНОЙ СВЯЗИ

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

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

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

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

11.4.5. НЕЖЕЛАТЕЛЬНЫЕ ПОСЛЕДСТВИЯ И НЕГАТИВНЫЕ ВЕТВИ

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

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

Основной способ обнаружить НВ — попросить кого-то проанализировать ваше ДБР. У тех, кто смотрит диаграмму, должен быть достаточный опыт и интуиция, чтобы разглядеть, как запланированные вами преобразования, взаимодействуя с какими-то известными им явлениями, могут привести к нежелательным результатам.

На рис. 11.6 представлена НВ для ССРМ, отражающая распространенное опасение, что явное отображение запаса времени в плане неизбежно побуждает руководство и клиентов этот запас урезать. В литературе по традиционному управлению проектами в данном случае советуется планировать запасное время в скрытой форме. Однако это трудно назвать профессиональным подходом к делу!

Первым делом вы рисуете диаграмму, в которой прорыв связывается с неким НЯ. НВ основана на логике достаточности, как ДТР и ДБР, и читается при помощи формулировок «если... то». Думаю, вы уже поняли, как следует читать логические диаграммы. Построение необходимо проанализировать по КПЛП.

Построив НВ, мы должны подумать, как предотвратить появление нежелательного эффекта. Для этого мы тщательно изучаем диаграмму и выявляем ту точку, в которой ход событий меняет свой оттенок на негативный. В нашем случае этой поворотной точкой оказывается блок 602 — «Клиенты хотят сократить длительность проекта и урезать буфер». Затем мы выявляем исходные установки, легшие в основу появления стрелок, ведущих к этому блоку. На нашем рисунке таких стрелок две. Обратите внимание, эти стрелки исходят из элементов 600 и 601, которые связаны строгим логическим «и» (это передается символом «эллипс», или, как его еще называют практики ТОС, «банан»). Поэтому мы избавимся от блока 602, если сумеем устранить хотя бы один из ведущих к нему блоков, потому что для появления события 602 должны одновременно соблюдаться условия 600 и 601. Вот что значит «строгое и».