Главная

Статьи

Библиотека статей

Организационное проектирование

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

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

Краткая история методологий управления проектами

Многие западные школы бизнеса выделяют три важнейшие даты в еще недолгой истории развития методологий управления проектами.Первая дата приходится на 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) и множество средних и мелких промышленных, государственных и военных организаций.

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

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

В чем секрет МКЦ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Видно, что задачи “красной” группы накладываются друг на друга (требуют одинаковых ресурсов) и не могут быть выполнены одновременно. Они выравниваются — например, так (рис. 3).

Заметно, также, что конфликтуют задачи “желтой” группы — надо сдвинуть влево задачу с продолжительностью 27 недель (рис. 4).

На следующем шаге определяем КЦ (входящие в нее задачи выделены жирной каймой; рис. 5).

Общая продолжительность работ получается 27 + 15 + 15 = 57 недель.

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

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

Добавляется общий буфер для КЦ (рис. 7). Оказалось, что одна из некритических задач (“зеленая”) вследствие добавления буфера стартует раньше КЦ. Последний шаг в плане — синхронизация первой задачи КЦ с самой ранней некритической задачей (рис. 8).

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

Размер буфера обычно определяется простыми способами — например, берется половина продолжительности КЦ (в нашем примере — 57/2 = 29 недель), корень из суммы квадратов ресурсов каждой задачи КЦ [sqrt(27х27 + 15х15 + 15х15) = 34 недели] или значение, основанное на корпоративном опыте.

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

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

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

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

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

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

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

Источник: www.bigspb.ru

Коротко о системе Е-МАСТЕР

Е-МАСТЕР® — система управления корпоративной информацией. Е-МАСТЕР® включает в себя возможности систем класса ECM (Enterprise Content Management). Система обеспечивает: Совместное создание и согласование документов Каждый документ может быть обсужден как при помощи прикрепленного к нему мини-форума, так и в главном форуме Разработанный документ может быть направлен на согласование по указанному маршруту Хранение документов любых форматов Хранение и передача документов в зашифрованном виде Встроенные системы восстановления после сбоев и резервного копирования Поиск документов Возможность поиска по ключевым словам и другим атрибутам документов (автор, дата создания…) Возможность поиска с помощью навигации по рубрикам Управляемый доступ к документам Возможность установки доступа к документам для различных категорий пользователей Возможность введения ограничений на работу с документами Функциональный интерфейс пользователя Веб-интерфейс, позволяющий просматривать карточки и скачивать файлы из системы хранения документов Удаленный доступ или работа пользователя из любой точки мира (при условии подключения к Интернету). Подробнее о Е-МАСТЕР >>

Система FLAMORY™

FLAMORY™ — уникальный программный продукт, позволяющий сохранять историю действий пользователя на компьютере, таких, например, как работа в приложениях Windows, посещения сайтов и д.р. Сохраненные последовательности действий, далее, можно просмотреть, сохранить в файл и передать коллегам. FLAMORY позволяет аккумулировать и делиться знаниями. Работая с FLAMORY, обмен опытом, обучение новых сотрудников, обсуждения технологий, становятся, как никогда ранее, простой и удобной, в практических аспектах, задачей. FLAMORY™ разрабатывается при участии специалистов KMSOFT. Скачать бета-версию можно по этой ссылке.

Версия для печати  |  Пользовательское соглашение