Глава 4. Комплексное решение для отдельного проекта

Глава 4. Комплексное решение для отдельного проекта

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

4.1. От системных требований к модели системы

4.1.1. МАТРИЦА ТРЕБОВАНИЙ

Табл. 4.1 представляет собой свод требований к эффективной системе управления проектом, разработанный по методу Джозефа Джурана [1]. В ней дается иерархия желаемых свойств, и в первую очередь самые необходимые условия реализации проекта. К ним относятся три граничных технических условия (содержание, бюджет и график) и необходимость удовлетворять ожиданиям участников проекта. Участники — это как минимум заказчик проекта и проектная команда, а в некоторых ситуациях и многие другие (например, субподрядчики, акционеры, законодательные органы, соседи, правительство и иные сообщества).

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

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

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

Таблица не является и не может быть полной. Это только идея, предмет для обсуждения и совершенствования. Например, я не очень доволен тем, что требования полностью включают в себя только глубинные знания, особенно знание психологии. Полагаю, можно пойти и дальше, включая в список принципы шести сигм и бережливого производства. Я считаю, что список «вполне приемлемый» для того, чтобы выстроилась картина ССРМ и мы занялись совершенствованием проектной системы, бросив вызов трудностям, описанным в главе 1.

4.1.2. КРИТИЧЕСКАЯ ЦЕПЬ ДЛЯ ОТДЕЛЬНОГО ПРОЕКТА:

КРАТКОЕ ИЗЛОЖЕНИЕ

Рис. 4.1 показывает ключевые элементы метода критической цепи как решения для отдельного проекта. Это решение соответствует функциональным требованиям к системе управления проектом. Изображение наглядно демонстрирует разницу между ССРМ и СРМ. Основные особенности ССРМ следующие:

1) критическая цепь определяется как самая длинная цепочка операций проекта с учетом ограничений как по ресурсам, так и по логике последовательности операций;

2) конфликты по ресурсам не рассматриваются до момента определения критической цепи;

3) в плане используются среднеоценочные характеристики операций (имеющие вероятность 50/50), а запас на компенсацию влияния общих причин вариабельности сосредоточен в конце цепочек работ (на рис. 4.1 буфер изображен в виде амортизатора);

4) выполнение цепочек работ, вливающихся в критическую цепь, координируется с помощью специальных буферов на слияние путей (при одновременном продолжении работ по снятию конфликта ресурсов);

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

6) в качестве средств оценки и контроля за реализацией проекта используются проектный буфер и буфера на слияние путей.

В следующих разделах мы рассмотрим каждый из данных пунктов подробно.

Для эффективного применения ССРМ в отдельном проекте крайне необходимо добиться следующих изменений привычного стиля работы:

1) руководство должно способствовать тому, чтобы при оценке операций давались средние величины, и не требовать от исполнителей завершения работ в точно обозначенные сроки;

2) руководство должно дать исполнителям возможность в конкретный момент времени заниматься только одним заданием;

3) исполнители должны сосредотачивать усилия на одной операции и передавать результаты на следующий этап, как только работа завершена;

4) чтобы решить, над чем дальше работать, каждый должен использовать план проекта и отчеты по буферу.

Вот и все!

4.2. Разработка решения «критическая цепь»

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

4.2.1. ОПРЕДЕЛЕНИЕ ОГРАНИЧЕНИЯ В ПРОЕКТЕ

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

В этих определениях не уточняется несколько важных моментов. Во-первых, предположение о том, что длительность операции определяется точно и с первого раза (детерминирована). Во-вторых, не указано, с какой вероятностью сделана оценка (50% и более высокая степень вероятности?). А ведь это весьма существенно.

В РМВОК идет речь и о вероятностных подходах к составлению расписания проекта, таких как методы PERT и Монте-Карло. Однако определения даются очень скудные, так что пользоваться этими методами, исходя только из описаний в РМВОК, невозможно. Как показали мои исследования, реально на практике они применяются редко.

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

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

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

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

Читая курс для членов PMI, я провел небольшое исследование. Среди слушателей много сертифицированных профессионалов в управлении проектами РМР. Практически все они согласны с тем, что получить в свой проект ресурс именно в тот момент, когда он необходим, очень трудно и часто из-за этого случаются задержки. Однако мало кто (менее 5%) указывает, что регулярно занимается выравниванием ресурсов (то есть учитывает ограниченность ресурсов на проекте). Когда я интересуюсь причинами, большинство объясняет, что после выравнивания ресурсов срок реализации превышает ожидания руководства.

На рис. 4.2 изображен типичный график, построенный методом критического пути. Имена исполнителей на нем указывают на уникальные ресурсы. Очевидно, что не удастся уложиться в срок, поскольку исполнитель не может выполнять несколько заданий одновременно.

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

Что еще более важно, первоначальный критический путь не является ограничением для выполнения проекта. Поскольку ресурсное ограничение в проекте часто самое значительное, метод планирования проекта по ТОС всегда его учитывает. Таким образом, критическая цепь зависит от ресурсов, а эта зависимость и определяет самый длинный путь (ограничение) в проекте. Этот метод снимает все ресурсные ограничения в ходе нахождения критической цепи. В критической цепи проекта между операциями могут иметься разрывы. На рис. 4.4 приведена критическая цепь для рассматриваемого нами примера.

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

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

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

4.2.2. МАКСИМАЛЬНОЕ

ИСПОЛЬЗОВАНИЕ ОГРАНИЧЕНИЯ

Определив критическую цепь как ограничение, мешающее выполнять проекты быстрее, мы должны теперь постараться максимально использовать возможности ограничения. Это означает сокращение как планового, так и фактического времени реализации проекта. ССРМ использует критическую цепь, опираясь на знание вариабельности. Вот в чем основное отличие метода критической цепи от существующих систем управления проектами: Голдратт учел как статистические колебания, так и явление взаимозависимости событий. Конечно, не только автор ТОС признает действие вариабельности. Новое в том, чтобы применить его метод в управлении проектами.

Деминг отмечал, что многие менеджеры, не понимая фундаментальной разницы между общими и особыми причинами вариабельности, наносят системам вред. Он говорит: «Исходя из собственного опыта, должен сказать, что для большинства проблем и возможностей для улучшения справедливо следующее распределение: 94% присущи системе (лежат в зоне ответственности руководства) и 6% — являются особыми случаями».

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

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

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

Подобная вариабельность в исполнении проектных работ, вызванная общими причинами, — не исключительное явление, в отличие от отдельных выявленных в проекте рисков. Методика PERT — попытка оценить воздействие общих причин вариаций, используя три варианта прогноза длительности операции, по ряду причин оказалась не очень удачной. Создатели РМВОК и других источников до сих пор ссылаются на этот прием, хотя сегодня он используется редко. Диаграммы PERT в том виде, в каком они упоминаются в большинстве источников по проектному управлению и применяются в программных продуктах, всего-навсего показывают логику сети проекта вне зависимости от временной шкалы; в них не задействованы три типа оценки длительности. В некоторых проектах для оценки степени влияния неопределенности длительностей и затрат используются симуляции или метод Монте-Карло. И хотя данные приемы позволяют оценить степень неопределенности, они не являются инструментом для систематического управления ею.

ССРМ рассматривает вариабельность, вызванную общими причинами, как неотъемлемую составляющую системы управления проектом. В процессе применения метода устраняются выявленные отклонения, вызываемые общими причинами, включая недоступность ресурсов и общие модели поведения исполнителей, такие как «студенческий синдром» и «многозадачность» (описанные в главе 3). Менеджеры, работающие по ССРМ, используют списки операций по приоритетам, «флаги» для исполнителей и другие способы отметить и обеспечить наличие исполнителей проектных работ.

4.2.2.1. Извлекаем выгоду из оценок

ССРМ стремится использовать средние или сделанные примерно с 50% вероятности оценки отдельных операций. Руководитель, работающий с ССРМ, осознает, что реальная длительность выполнения отдельного задания включает отклонения, вызванные общими причинами. И он не критикует исполнителей, если фактические сроки исполнения работ расходятся с плановыми.

Большинство менеджеров проектов пытаются учесть действие общих причин вариабельности, добавляя резерв на непредвиденные обстоятельства к оценочным значениям длительности каждой операции. В явном виде наличие и размер этого резерва обычно никак не обозначаются. Специалисты, производящие оценку длительности работ, исходят из убеждения, что менеджер проекта хотел бы видеть максимально реальные цифры — такие, чтобы можно было с вероятностью 80%, а то и 95% утверждать, что работа завершится именно за это или меньшее время. Как видно на рис. 4.5, такая оценка в два и более раз превышает значение, выведенное с 50%-ной долей вероятности. Как правило, на проектах исполнителю будет хорошо, если он завершит свое задание в срок, и нехорошо — если нарушит плановую дату. Это также побуждает людей при оценке называть максимально вероятные сроки выполнения работ. Уолтер Шухарт, наставник Эдвардса Деминга, говорил [3]:

«Необходимо отметить, что специалист по статистике не станет пытаться делать какие-либо достоверные прогнозы для одного-единственного оценочного значения некоего показателя. Он сформулирует, как поведет себя все множество значений данного показателя, полученных путем оценки в тех же условиях, что и отдельное выбранное им значение».

Сказанное объясняет, почему попытки справиться с неопределенностью по каждой отдельной операции в проекте бесполезны.

Сейчас много говорят о «повышении точности оценок». Раньше я думал, что так и надо, что стоит организовать более строгий процесс — и можно будет лучше оценивать длительность и стоимость проектов. В общем-то, все правильно. Однако, поняв особенности явления вариабельности, я по-новому взглянул на смысл, стоящий за словами «повышение точности». Большинство людей под «повышением точности оценки» понимают увеличение точности оценки каждой отдельной составляющей, входящей в общую величину длительности и затрат. Шухарт объясняет, что это невозможно. Постепенно я понял, что вероятность оценки каждой отдельной составляющей равна нулю. Вы можете оценить конечную вероятность лишь тогда, когда речь идет об интервале значений, в котором может находиться некоторый показатель. Таким образом, точности в том виде, как ее трактует большинство людей, с научной точки зрения не существует.

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

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

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

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

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

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

2) исполнители склонны в следующий раз оценивать длительность с запасом.

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

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

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

Как показывает мой опыт, при планировании проектов в сотнях самых разных компаний либо не уточняется степень надежности оценочных значений длительности операций, либо не указывается, на чем основана оценка, либо и то и другое. РМВОК призывает менеджеров проектов показывать эти параметры, однако практически не объясняет, что с ними делать. Исключением являются строительные проекты. Здесь накоплен большой объем численных данных. Например, «Государственное руководство к составлению смет в строительстве» (National Construction Estimator) [4] написано с использованием обширнейшей базы данных. В нем приводится перечень потенциальных факторов (общих причин вариабельности), влияющих на точность оценки. Указывается, что действие почти каждого из этих факторов вызовет изменение оценочного значения затрат на несколько десятков процентов. Следовательно, зачастую они будут оказывать аналогичное влияние и на график.

4.2.2.2. Используем законы статистики для управления общими причинами вариабельности

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

Отметим, что в терминах статистики говорят о стандартном квадратичном отклонении, обозначаемом обычно как s¹¹. Для конкретного определенного статистического распределения заданное число стандартных отклонений определяет совокупную вероятность. Например, при нормальном распределении в область плюс-минус одно стандартное отклонение попадает 67% данных, или совокупная вероятность того, что результат будет наблюдаться в пределах одного стандартного отклонения от среднего значения, составляет 67%.

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

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

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

В ССРМ при построении плана берутся значения длительности с вероятностью 50%, так получилась критическая цепь из четырех операций общей длительностью четыре недели. Буфер проекта — квадратный корень из суммы квадратов отдельных отклонений, то есть в нашем случае разностей между оценочными значениями длительности каждой операции с вероятностью завершения 50% и 90%. Так как для каждой операции разность между оценочными значениями составляет одну неделю, то суммарное отклонение по проекту составит две недели¹². Следовательно, общий план проекта будет иметь длительность всего шесть недель. А с учетом такой особенности, как жесткая ориентация исполнителей на плановую дату, есть надежда, что проект завершится и за четыре недели.

4.2.2.3. Работаем с доступностью ресурсов

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

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

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

4.2.3. ИЕРАРХИЧЕСКОЕ ПОДЧИНЕНИЕ ПУТЕЙ ПРИ СЛИЯНИИ

В большинстве проектов есть несколько последовательностей работ. И все последовательности к концу проекта «сливаются» в критический путь, хотя бы просто для того, чтобы достичь контрольной точки, знаменующей завершение проекта. Обычно такие объединения происходят ближе к окончанию проекта. Одна из причин этого в том, что различные сборки и тесты чаще всего проводятся в самом конце и для этого нужно иметь множество составляющих. Далее мы увидим, что в этом кроется основная причина всем известного явления: многие проекты 90% пути проходят в первый год, и оставшиеся 10% — во второй. На рис. 4.8 показан эффект слияния путей в проекте. Операция не может начаться, пока не закончится последняя из предшествующих работ.

Когда несколько цепочек работ сходятся в одну, возникает эффект фильтра: он «отсеивает» положительные отклонения и оставляет в силе, передавая на следующий этап, самую большую временную задержку. Объясняется это тем, что при слиянии путей объединенный путь не может начаться, пока не завершатся все «вливающиеся» в него цепочки. Следовательно, работы на объединенном пути не стартуют, пока не закончится самая последняя из вливающихся работ. Представим себе некую проектную операцию на критическом пути, для начала которой необходимы результаты трех отдельных заданий. Это распространенная ситуация, характерная для этапа сборки или для проведения крупных мероприятий, таких как шоу и съезды, например. В день открытия все должно быть готово. Обычно требуется не три, а гораздо больше составляющих. Однако даже если предположить, что их три и вероятность своевременного завершения каждой равняется 50%, то шансы того, что хотя бы одна поступит с опозданием, составляют 88%! И даже если вероятность того, что каждое задание будет выполнено вовремя, равна 90%, то ожидать срыва сроков хотя бы по одному из них можно с 30%-ной долей уверенности, то есть практически шансы один к трем.

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

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

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

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

4.2.4. ВЫПОЛНЕНИЕ РАБОТ

4.2.4.1. Искореняем привязанность к датам

Важнейшая составляющая проджект-менеджмента, которую чаще всего пытаются оптимизировать, — это оценка длительности каждой отдельной операции проекта. Если руководство оценивает исполнителя по тому, выполнил ли он свое задание в строго оговоренный срок (оптимальное поведение отдельного элемента), как это сказывается на времени выполнения проекта в целом (оптимальном состоянии системы)?

В планах проектов, управляемых методом критической цепи, приводятся только даты начала цепочек работ и дата окончания буфера проекта. В остальном же даны приблизительные даты начала работ и оценочная длительность каждой. Менеджеры, управляющие своим проектом по методу критической цепи, не критикуют исполнителей, нарушивших сроки, если те, во-первых, принялись за работу, как только получили результаты предыдущего этапа; во-вторых, 100% времени уделяли одному заданию (не допускали «многозадачности»); в-третьих, сразу же по завершении работы передали результаты на следующий этап. Руководители проектов, использующие ССРМ, готовы к тому, что 50% работ будут идти с опозданием.

Анализ промежуточных результатов практически всех проектов показывает, что исполнители очень редко рапортуют о досрочном завершении работ. Если оценки длительности операций вашего проекта сделаны с 50%-ной долей вероятности, то можно было бы ожидать, что в 50% случаев работы будут выполняться раньше срока. Если оценка сделана с вероятностью 99%, то и в отчетах 99% заданий должны быть помечены как выполненные с опережением графика. Обычно же люди сообщают о выполнении большинства работ точно в срок и о некоторых как завершенных с опозданием. И почему это на проектах не проявляются результаты положительных отклонений?

Причина в том, что в большинстве случаев исполнители блокируют действие положительных отклонений. В работе «Критическая цепь» (Critical

Chain) описаны несколько факторов, обуславливающих систематическое нарушение сроков, даже если изначально у исполнителя был очень хороший запас на непредвиденные обстоятельства. Джек Мередит и Сэмюель Мэнтл [6] пишут: «Действие “законов Паркинсона” — явная и реальная угроза. Работа по проекту практически неизбежно займет все даже дополнительно выделенное время». Выражаясь словами Голдратта, впустую тратится резервное время.

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

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

В главе 3 говорилось о студенческом синдроме (рис. 3.10). Многие склонны не браться за дело до тех пор, пока оно не станет по-настоящему срочным. Это особенно справедливо по отношению к постоянно занятым специалистам, на которых наблюдается большой спрос, — а это наиважнейший ресурс, в котором менеджеры проектов видят гарантию от срыва сроков на критическом пути. Если исполнители считают, что в плановую длительность заложен некий резерв, очень часто, когда приходит пора браться за выполнение задания, у исполнителей появляются другие, более приоритетные дела. Под эти дела тратится резерв на непредвиденные обстоятельства, и приходится затем выполнять большую долю плановых работ, когда срок уже почти истекает.

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

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

4.2.4.2. Улучшаем качество работ, устранив многозадачность

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

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

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

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

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

ССРМ стремится не допускать многозадачности, предусматривая 100%-ную занятость каждого ресурса только на одной операции в один момент времени. Таким образом, при планировании методом критической цепи первоочередной установкой является исключение «частичной занятости людей на проекте». ССРМ также предусматривает постоянное информирование исполнителей, чтобы каждый легко мог определить, над чем ему дальше работать.

Меня часто спрашивают: «Но разве работа над несколькими вопросами одновременно не является нормальной для менеджера?» или «А если так мы застрянем на одной операции?» Отвечая, я поясняю, что бывает и положительная многозадачность. Негативной является многозадачность, которая приводит к увеличению длительности проекта. Сумев поставить дело так, чтобы не допускать негативной многозадачности, вы окажете своей команде большую услугу.

4.2.5. РАННИЙ СТАРТ ИЛИ ПОЗДНИЙ ФИНИШ?

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

• снижает воздействие изменений на результаты уже выполненной работы;

• сдвигает на более поздние сроки денежные расходы по проекту;

• позволяет правильно сосредоточить усилия, поскольку одновременно запускается меньшее число работ, что позволяет команде как следует «разогнаться».

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

Данный текст является ознакомительным фрагментом.