Критическая цепь – третья революция в управлении проектами

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

В 1917 году массовое распространение получили работы Ганта, в середине 50-х годов ВМС США разработали теорию PERT, а в 1997 г., всего 20 лет назад, была опубликована работа Илиахи Голдратта «Критическая цепь». Новый подход к планированию, который описал в своей  книге Голдратт, позволил многим производственным компаниям резко увеличить свою производительность.

Например, завод компании Harris Semiconductor выполнил первый проект, в котором применил метод критической цепи, на 34 месяца раньше срока. В среднем использование метода «Критическая цепь» дает ускорение работ на 90%. Данный метод сегодня используют 450 крупнейших предприятий мира (в частности, AT&T, Boeing, Eriсcson, Ford Motor, General Motors, GTE, IBM) и множество средних и мелких промышленных, государственных и военных организаций.

Проблемы классических подходов

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



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

В чем успех метода «Критическая цепь»?

Прежде чем перейти к рассмотрению практического применения метода «Критическая цепь», несколько слов о ее идеологической основе. Критическая цепь базируется на теории ограничений (Theory of Constraints), которая в самом общем виде предлагает для выполнения проекта сделать следующие шаги:

  • определить накладываемые на него ограничения (например, по ресурсам);
  • учитывать их при построении плана и в процессе работ;
  • подчинить все второстепенные задачи этим ограничениям и не начинать их, пока не возникнет реальная необходимость;
  • определить способы смягчения этих ограничений.

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

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

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

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

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

Применение критической цепи  описывается достаточно просто и кратко:

  • выявляются задачи, которые влияют на дату окончания проекта (находится критическая цепочка задач);
  • выполняется перестройка плана под эту цепочку с учетом ограничений, накладываемых ресурсами;
  • организовывается единый буфер ресурсов для критической цепочки (КЦ), который помещается в конец проекта, и отдельные буферы для некритических задач.

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

К недостаткам МКЦ следует отнести влияние ошибок планирования, которые возникают из-за сложности выявления на ранних фазах скрытых взаимосвязей между задачами проекта (критические задачи становятся некритическими и наоборот, а также появляются новые задачи; от этого, впрочем, страхует буфер), и отсутствие в данной методологии контроля за качеством работ.

Практический пример

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

Имеется пять видов задач, выполняемых соответственно пятью группами людей. Для каждой задачи определена ее продолжительность в неделях (рис. 1; цифры — длительность в неделях).

Критическая цепь - Задачи проекта

Рис.1 — Задачи проекта.

Шаг 1. Сдвиг задач

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

Критическая цепь - Сдвиг задач вправо

Рис.2 — Сдвиг задач

Шаг 2. Выравнивание задач

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

Также видно, что конфликтуют задачи «желтой» группы — надо сдвинуть влево задачу с продолжительностью 27 недель. (рис. 3)

Критическая цепь - Выравнивание задач

Рис.3 — Выравнивание задач

Шаг 3. Определение критического пути

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

Критическая цепь - Определение критической цепи

Рис.4 — Определение критеческой цепи

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

27 + 15 + 15 = 57

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

Шаг 4. Формирование временных буферов

Далее требуется сформировать промежуточные буферы для цепочек некритических задач (серые прямоугольники).

Формирование промежуточных временных буферов

Рис.5 — Формирование промежуточных временных буферов.

Формируется и добавляется общий буфер для критической цепи (рис. 5). Серый прямоугольник с диагональной штриховкой.

Критическая цепь - Формирование общего буфера критической цепи

Рис.6 — Формирование общего буфера критической цепи

Оказалось, что одна из некритических задач («зеленая») вследствие добавления буфера стартует раньше критической цепи.

Шаг 5. Синхронизация задач

Последний шаг — синхронизация первой задачи критической цепи с самой ранней некритической задачей (рис. 7).

Критическая цепь - Синхронизация задач

Рис.7 — Синхронизация задач

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

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

57/2 = 29 недель,

и корень из суммы квадратов ресурсов каждой задачи критической цепи:

 (27 x 27 + 15 х 15 + 15 х 15) = 34 недели.

Размер буфер также может быть пределен на основании корпоративного опыта.

Важность общего буфера ресурсов

Планировать отдельный небольшой буфер для каждой задачи — нерационально:

Общий буфер

Рис.9 — Общий буфер

Синие квадраты — это задачи, серые — буферы ресурсов. В первом варианте каждая задача имеет свой буфер и общая продолжительность проекта с учетом подстраховочных пауз составляет 8 недель. При этом в ходе работ возможны простои, так как далеко не каждый буфер будет использован полностью, а вот если существенная задержка произойдет на последней задаче (например, она будет выполняться в три раза дольше), то сроки все равно окажутся сорванными.

Если же общий буфер перемещается в конец проекта и дополнительные ресурсы черпаются из него по мере необходимости, то он служит серьезной защитой для каждой задачи, не допускает простоев и позволяет закончить проект в сравнении с первым вариантом как минимум на 25% раньше (если общий буфер составляет половину от КЦ), а как максимум — на 50%. В первом случае сроки можно сократить не более чем на продолжительность последнего буфера:

1/8 = 13%.

Другое назначение основного буфера — мониторинг хода проекта. МКЦ позволяет отказаться от сложных методик контроля, достаточно только следить за соотношением «использованный на данный момент объем буфера/объем выполненных задач КЦ» (например, если это отношение порядка 0,5 — хорошо, 1 — ситуация плоха). Данное соотношение не просто показывает объем законченных работ, а фактически определяет эффектность выполнения критически важных для проекта задач.

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

Заключение

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

Бобровский Сергей

Комментарии к “Критическая цепь – третья революция в управлении проектами

Комментарии недоступны