Руслан Шарипов, Руководитель проектов, ООО «Антел»: «Управление проектами по ТОС. Сказ о непотерянном времени»

Как известно, большинство проектов не завершаются в рамках запланированных сроков/бюджетов/объемов. На мой взгляд, отчасти это происходит потому, что «традиционное» управление проектами (PM Book) не учитывает некоторых важных моментов. В качестве дополнения я в своих проектах использую Метод критической цепи Теории ограничений (Critical Chain Project Management, CCPM). Давайте посмотрим, что же он нам предлагает.

Теория ограничений (ТОС) является методологией управления системами. Она была придумана доктором Э. Голдраттом около 30 лет назад и с тех пор активно развивается и дополняется. Изначально был предложен подход для управления производством («Барабан–Буфер–Канат», ББК), который в дальнейшем лег в основу Метода критической цепи (МКЦ).
Как следует из названия, ТОС сосредотачивает внимание на немногих критических факторах, определяющих успех системы. В основе управления по ограничениям лежат четыре предположения:

•    У каждой системы есть цель и конечный набор необходимых условий, которые должны быть выполнены для достижения цели.
•    Сумма локальных системных оптимумов не равняется оптимуму системы в целом.
•    В любой конкретный момент времени работа системы ограничивается очень малым – возможно, только одним фактором.
•    Все системы подчиняются причинно-следственной логике.

ТОС предлагает пять фокусирующих шагов для осуществления изменений (по аналогии с циклом PDCA Деминга):

Шаг 1. Определите ограничения системы.
Шаг 2. Максимально используйте ограничение.
Шаг 3. Согласуйте все остальное с принятым решением.
Шаг 4. Увеличьте пропускную способность ограничения.
Шаг 5. Если на предыдущем шаге ограничение было устранено, переходите к шагу 1, но не позволяйте ИНЕРЦИИ стать новым ограничением.

Как выглядит типичное планирование проекта?

1. Определяем список задач и оцениваем каждую задачу по срокам выполнения.
2. Планируем выполнение работ, исходя из установленных сроков.
3. Требуем от исполнителей соблюдения установленных сроков.

Казалось бы, все логично. Давайте посмотрим, где мы совершаем ошибку.

Оценка задач по срокам выполнения

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

Рисунок 1. Вероятность завершения задачи/проекта в определенный срок

 

С учетом, что с исполнителя будут требовать соблюдения сроков, вполне логично, что он указывает срок с запасом, т.е. с вероятностью соблюдения срока в 95% (рис. 1). Плюс к этому начальник исполнителя добавляет свою подстраховку (с него же будут спрашивать сроки). Если же начальство урежет срок, то исполнитель в следующий раз учтет это, добавив дополнительное время «на урезание».

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

 

Метод КЦ дает этому несколько объяснений.

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

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

Третье — многозадачность(рис. 2). Сколько задач одновременно у вас выполняет сотрудник на проекте (проектах)? А ведь в действительности человек не может выполнять две задачи разом. Получается псевдомногозадачность. То есть задачи разбиваются на мелкие последовательные выполнения. Таким образом, при двух параллельных задачах каждая будет выполняться в два раза дольше, при трех задачах — в три! И это не учитывая время, необходимое на «переключение» между задачами.

 

Рисунок 2. Многозадачность

 

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

 

Цель проектного управления

 

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

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

Проект запускается для получения каких-то выгод, которые должны превысить его стоимость. Представим себе проект по строительству завода. Объем задачи определен и изменению не подлежит. Что важнее — сэкономить часть затрат (5%? 10%? Вряд ли получиться снизить стоимость в два раза) или сосредоточиться на том, чтобы проект был закончен вовремя (а лучше раньше планового срока)? В ИТ-проектах ситуация аналогичная (например, внедрение ERP-системы). Таким образом, первичной бизнес-целью проектного управления по ТОС является сокращение сроков проекта. Насколько же можно сократить срок? Если опросить менеджеров проектов, то ответ, скорее всего, будет между 0 и 10%. На самом деле сокращение срока может доходить до 50%. Ведь, как мы уже выяснили, чем больше неопределенность в проекте, тем большая подстраховка закладывается, а значит, что больше и потенциал для улучшения!

 

Что же делать?

 

Все достаточно просто и сложно одновременно.

Просто — потому что ТОС предлагает набор достаточно несложных действий для выхода из сложившейся ситуации. Сложно — потому что изменение системы затрагивает в первую очередь людей. Им нужно помочь перестроиться под новый порядок. При этом не надо забывать, что поведение людей во многом зависит от показателей, по которым мы оцениваем их работу. При внедрении метода КЦ помните об этом!

Итак, что же нужно сделать? Если жесткие сроки не работают, давайте попробуем управлять сроками более гибко.

 

Пять шагов ТОС

 

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

 

Шаг 1. Определите ограничение системы (схема 1).

 

 

Схема 1.

 

Насколько этот график реален? Сможем ли мы одним ресурсом выполнять две задачи одновременно? В первую очередь нам нужно определить КЦ проекта. Отличие от критического пути в том, что мы помимо последовательности задач учитываем так же ресурсы, избегая многозадачности.

Для этого мы разносим все одновременные задачи, использующие один ресурс, так, чтобы общая длительность была минимальна (схема 2).

 

 

Схема 2.

 

Мы хотим, чтобы ресурсы работали по принципу Road Runner, т.е. работа выполняется так быстро, как это возможно, и затем передается на следующую задачу. Это предотвращает разбазаривание резервов времени.

Шаг 2. Максимально используйте ограничение.

 

Как мы уже поняли, в каждой задаче заложена подстраховка. Но нам-то важно выполнение всего проекта в срок, а не каждой отдельной задачи. Поэтому и подстраховку нужно поместить туда, где проект целиком будет максимально защищен, т.е. в конец проекта. Для этого избавляемся от лишней подстраховки в задачах: сокращаем плановый срок завершения наполовину и переносим всю подстраховку в конец проекта (назовем это проектным буфером).
Теперь задачи оценены по срокам с вероятностью завершения 50%. Таким образом, половину задач мы закончим в плановый срок, а другую половину — с запозданием. При такой ситуации размер проектного буфера представляется слишком большим, поэтому мы можем смело сократить его на 50% (схема 3).
 

 

Схема 3

 

Теперь времени на выполнение задач достаточно, чтобы исполнители имели шанс завершить все вовремя, но не так много, чтобы терять время (устраняем «синдром студента»)!

Если мы хотим предотвратить потери времени, то обязаны выполнять мониторинг раннего выполнения задач. Следующая задача должна начать выполняться сразу же после окончания выполнения предыдущей. Как обеспечить доступность ресурсов всегда, когда это необходимо? Как мы убедимся, что время раннего завершения задач не будет разбазарено?
Для этого мы используем ресурсные буферы (флажки). То есть ресурс (исполнитель) извещает следующего заранее об окончании своей задачи, чтобы тот был готов «принять эстафету» (схема 4).

 

Схема 4

 

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

 

Шаг 3. Согласуйте все остальное с принятым решением.

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

 

Схема 5

 

Теперь, когда план готов, можно приступить к следующему шагу.

 

Шаг 4. Увеличьте пропускную способность ограничения.

 

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

 

 

 

Схема 6

 

И последний, но очень важный, шаг.

 

Шаг 5. Если на предыдущем шаге ограничение было устранено, переходите к шагу 1. Но не позволяйте ИНЕРЦИИ стать новым ограничением.

 

Обратите внимание, что в результате наших действий критическая цепь изменилась. Поэтому необходимо заново пересмотреть все наши предпосылки и решения. Как правило, для построения устойчивого графика требуется 3-5 итераций.

Итак, график построили, начинаем проект. Сразу возникает вопрос: как контролировать ход работ? Как написал еще 35 лет назад Фредерик Брукс в книге «Мифический человеко-месяц», у проектов есть свойство бодро по графику доходить до 90% выполнения и оставаться в таком состоянии еще очень долго. При этом менеджеры пытаются с маниакальной точностью контролировать сроки каждой мелкой задачи.

ТОС предлагает простое и эффективное решение – управление буферами. Наша подстраховка от срыва срока заложена в буфере проекта. Вот за буфером и будем следить. Разделим его на три части — зеленую, желтую и красную. По ходу проекта некоторые задачи, как мы и ожидали, будут выполняться дольше запланированного и, соответственно, будут съедать проектный буфер. Пока мы находимся в зеленой зоне — все нормально, ничего делать не нужно. Если по ходу проекта мы оказываемся в желтой зоне, то требуется разработать резервный план. Если обстоятельства и дальше складываются неблагоприятно, и задействована красная зона буфера, то немедленно применяем резервный план для ускорения хода проекта.

Какими же должны быть размеры каждой зоны? По мере продвижения по критической цепи остается все меньше задач, а следовательно, и рисков. Поэтому размер зон не постоянен, зеленая будет увеличиваться к окончанию проекта, а красная — уменьшаться. На рисунке представлен пример буферов и описанное выше продвижение проекта — от зеленой зоны в красную и возврат в желтую в результате применения резервного плана (рис. 4).

Рисунок 4. Статус буфера

 

Таким образом, метод КЦ помогает:

• избежать действия закона Паркинсона;
• защититься от закона Мерфи;
• изменить отношение людей к работе:
o они не будут подвержены студенческому синдрому;
o уменьшается многозадачность, а значит, люди сфокусированы.
• концентрировать внимание менеджера проекта на производительности команды;
• отслеживать прогресс проекта на основе использования буферов времени и ресурсов.
Этот метод может быть использован практически в любых областях, где применяется методология управления проектами.

 

* * *

Мы рассмотрели метод КЦ для одного проекта. Не менее интересным является применение данного подхода в мультипроектной среде, но это тема для отдельного разговора.

В заключение поделюсь собственным опытом применения. Изначально я опробовал элементы метода на процессе поддержки EPR-системы. Казалось бы, проект и поддержка — совершенно разные вещи. Но суть задач, стоящая перед отделом ИТ, по сути та же. В первую очередь мы по максимуму убрали многозадачность. Для этого ввели систему приоритетов заявок (обычная и срочная). А также ввели правило, что следующая задача будет начинаться только после окончания предыдущей. Эта нехитрая система позволила увеличить скорость выполнения заявок на 20%.

Для оценки сроков выполнения новых задач (ведь нужно учесть очередь перед задачей) я создавал график текущих работ по принципу КЦ. В итоге получал предполагаемую дату выполнения. Точность попадания по факту была на уровне 80-85%. На мой взгляд, это хороший результат.

Следующий мой опыт применения метода КЦ был при внедрении ERP-системы. Тут все оказалось не так радужно. Мы составили красивый график, и со стороны ИТ все делалось быстро, буфер проекта практически не затронули. Но когда задачу выполняли сотрудники других бизнес-подразделений, то мы имели все проблемы, описанные в статье («синдром студента» и т.д.), и еще немного сверху. В итоге получился классический результат – проект был выполнен, но срок увеличился в два раза,  с шести месяцев до года. Основная проблема в том, что нам не удалось сделать так, чтобы задачи выполнялись по принципу «как можно быстрее». Отчасти это оправдано, когда текущие процессы имеют больший приоритет, чем проект (сдача отчетности, отгрузка товара покупателям и т.д.), но чаще всего имело место нежелание сотрудников выходить из привычного размеренного режима работы.

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