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

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

Многие западные школы бизнеса выделяют три важнейшие даты 1в еще недолгой истории развития методологий управления проектами. Первая дата приходится на 1917 г., когда массовое распространение получили работы Ганта (общеизвестные диаграммы). Затем в середине 50-х годов ВМС США разработали теорию PERT-сетей. И наконец? в 1997 г., всего около трех лет назад, была опубликована работа Илиахи Голдратта "Critical Chain" (метод критических цепочек, МКЦ; см. www.goldratt.com). МКЦ позволил многим производственным компаниям резко увеличить производительность. Например, завод компании Harris Semiconductor выполнил первый проект, в котором применил МКЦ, на 34 месяца раньше срока. В среднем МКЦ дает ускорение работ на 90%. Данный метод сегодня используют 450 крупнейших предприятий мира (в частности, AT&T, Boeing, Eriсcson, Ford Motor, General Motors, GTE, IBM) и множество средних и мелких промышленных, государственных и военных организаций.

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

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

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

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

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

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

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

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

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

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

МКЦ описывается достаточно просто и кратко:

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

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

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