Глава 5. Запуск нового проекта

We use cookies. Read the Privacy and Cookie Policy

Глава 5. Запуск нового проекта

5.1. Процесс инициации проекта

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

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

РМВОК [1] разделяет процессы инициации и процессы планирования. В данной главе мы оба типа процессов рассматриваем как части процесса запуска-инициации проекта. При таком подходе результатами на выходе процесса будут устав проекта, назначение менеджера проекта, описание ограничений, исходных установок и допущений, а также другие компоненты полного плана управления проектом, включая график работ и бюджет.

5.2. Устав проекта

Устав проекта — краткое письменное заявление о запуске проекта, дающее основание для создания соответствующей проектной команды и начала планирования. Это определение намного шире приведенного в РМВОК и предполагает также, что в устав включаются ответы на шесть вопросов, необходимых для создания плана проекта, — кто делает, что делает, когда, где, как и зачем. Как правило, в уставе должны быть освещены все перечисленные ниже пункты, обозначенные авторами из CH2MHILL [2] как обязательные:

Главное различие между уставом и планом проекта в том, что устав уполномочивает команду приступать к планированию.

5.3. Определение участников проекта

В РМВОК дается следующее определение участников проекта:

«...Лица или организации, активно вовлеченные в проект, или те, чьи интересы могут быть затронуты — в положительном или отрицательном смысле — в ходе или по результатам выполнения проекта; они также могут оказывать влияние на проект и его результаты» (с. 16)14.

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

5.4. Иерархическая структура работ (ИСР)

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

Хотя идея ИСР проста, я обнаружил, что многие испытывают трудности при составлении этого дерева работ. Думаю, проблема отчасти заключается в склонности человека мыслить в категориях конкретных операций, а не результатов этих операций. Результаты проекта — это все товары и услуги, производимые/появляющиеся в ходе проекта. Чрезвычайно важно, чтобы с самого начала был ясен перечень объектов, оборудования и услуг, которые будут созданы в рамках проекта. (Также очень важно указать, что именно не будет получено в этом проекте, а что появится в результате других, но об этом мы еще поговорим в разделе 5.7.) ИСР — ваш инструмент для систематизации содержания проекта и назначения ответственных за каждый из ожидаемых результатов.

5.4.1. ПОДХОД ТЕОРИИ ОГРАНИЧЕНИЙ

Сторонники ТОС предлагают два способа построения сетевой диаграммы проекта. Большинство опускают этап разработки иерархической структуры работ. Один из способов — дерево перехода (ДП) — можно условно назвать ИСР. Идея заключается в том, чтобы взять конечный или промежуточный результат и спросить участников команды: «Что мешает нам получить этот результат?» Как только составлен список препятствий, вы просите команду перечислить условия преодоления этих препятствий. Затем эти условия выстраиваются в логическую цепочку. Такой метод представляет последовательную стратегию и согласованную тактику преодоления проблем, выявленных командой. Для больших проектов можно создавать ДП разных уровней — по аналогии с уровнями иерархии в ИСР.

К сожалению, упрощенный метод построения ДП, описанный Голдраттом в романе «Дело не в везенье!» [3], не подходит для разработки ИСР проектов. Дело в том, что ДП позволяет только обеспечить выполнение условий преодоления препятствий, выявленных командой. Этот метод не отслеживает достижение всех промежуточных результатов, необходимых для получения конечного продукта проекта. Детмер [4] модифицировал метод так, чтобы он охватывал и необходимые, и достаточные условия успешного завершения проекта.

Второй подход, предлагаемый в ТОС, основан на обратном планировании. Рассматриваем последовательно все планируемые результаты проекта и к каждому задаем вопрос: «А какие исходные нам нужны, чтобы получить на выходе этот результат?» Так продолжается до тех пор, пока не достигается уровень операций, для которых уже не нужны никакие особые входные данные.

У обратного планирования есть несколько недостатков:

• не всем удобно думать «задом наперед», из конца в начало;

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

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

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

5.4.2. ТРАДИЦИОННАЯ ИСР

Есть ряд полезных стандартов, которые помогут вам с разработкой ИСР. Один из них сравнительно недавно выпущен PMI [5], а наиболее полный предложен министерством обороны США [6]. Харольд Керцер приводит следующие критерии хорошей ИСР [7]: «Менеджер проекта должен разбить работу на мелкие элементы, которые:

• управляемы, на них можно назначить исполнителя либо ответственного;

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

• интегрируемы, то есть представляют часть общего пакета работ;

• измеримы, то есть можно оценить степень их выполнения.

Правильная ИСР обеспечивает следующее:

• лучшее понимание объема работ;

• планирование всех работ;

• выявление конечных продуктов и результатов;

• последовательную детализацию работ;

• соотнесение отдельных рабочих заданий с общими задачами проекта;

• назначение ответственных за весь объем работ;

• оценку сроков и затрат;

• планирование и распределение ресурсов компании;

• интеграцию содержания, графика и бюджета;

• отслеживание расходов, графика и качества выполнения технических требований;

• систематизацию и обобщение информации для руководства и отчетности, возможность проследить картину по разным уровням детализации;

• управление изменениями.

В ИСР обычно выделяются определенные уровни, например:

Уровень 1: программа в целом.

Уровень 2: суммарные статьи расходов.

Уровень п-1: пакет работ.

Уровень п: операция».

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

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

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

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

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

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

5.4.3. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА

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

Есть разные способы организации управления проектами в компании. Поскольку мало какому проджект-менеджеру выпадает счастливая возможность перестроить под свой проект всю организацию, данный способ мы рассматривать не будем. Как правило, руководителю дается определенная свобода действий в создании ИСР, подборе команды и распределении полномочий и обязанностей.

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

5.5. Назначение ответственных

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

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

Более удобный вид матрицы — линейная. В первой колонке перечислены компоненты ИСР, во второй — лицо (а не подразделение), ответственное за каждый компонент, и в остальных можно писать все, что нужно. Создавать и вести такую матрицу легко. Ее удобно смотреть на компьютере, а можно распечатать и подшить к остальным планам, чтобы все могли пользоваться. Матрица может содержать и гораздо больше информации. Табл. 5.1 — пример такой простой матрицы.

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

5.6. Последовательность контрольных событий

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

Эффективный способ выстроить логичную картину — определить основные фазы проекта, или ключевые события. На рис. 5.2 дан пример схемы контрольных точек. У каждого ключевого события должен быть свой определенный результат. В диаграмме контрольных событий даты не указываются. Ведь даты вычисляются в результате составления графика, а не задаются как исходные условия для его создания (исключение — проекты с жестко установленной датой окончания, такие как подготовка коммерческого предложения, проведение мероприятия, Олимпийские игры-2004 в Афинах).

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

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

5.7. Пакеты работ

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

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

Для удобства планирования и управления по каждому элементу ИСР должен быть назначен ответственный — конкретный человек. Иногда можно обойтись указанием роли, например менеджер пакета работ, член рабочей группы, менеджер по учету затрат. Как правило, это должен быть специалист в предметной сфере, к которой относится элемент ИСР. Ему предстоит составить детальный перечень работ, установить их последовательность и оценить потребность в ресурсах. Также в обязанности ответственного входит определение взаимосвязей с другими пакетами работ и, кроме того, обоснование своей оценки количества необходимых ресурсов.

5.7.1. ИСХОДНЫЕ УСТАНОВКИ

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

5.7.2. ДИАГРАММА ПРОЕКТА

Самой важной составляющей описания пакета работ является схема расположения операций. Обратите внимание, в этой диаграмме нет точных дат. Даны длительность операции, ее место в структуре работ и перечень требований по ресурсам для выполнения этих работ. Одна из причин отсутствия дат в диаграмме заключается в том, что мы не можем определить даты, пока не будет готова полная картина проекта и найдена критическая цепь. Указание дат может помешать программе правильно вычислить критическую цепь или путь. Кроме того, вероятность точного соблюдения дат, назначенных для отдельной операции, равна нулю, поскольку при реализации всех операций бывают отклонения, а предсказать величину статистических колебаний по одному событию невозможно. Компьютерная программа посчитает даты раннего и позднего начала и окончания каждой операции. Но вы не должны обращать внимания на эти даты. Я вообще не использую колонки «Начало» и «Окончание» для отдельных операций.

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

5.7.2.1. Логика проекта

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

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

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

• Старт-старт (с запаздыванием) — эта связь устанавливается, когда две операции могут выполняться одновременно. При этом сначала в ходе первой производится некий объем продукта, который может далее обрабатываться на второй. Например, вам нужно пропустить множество экземпляров продукции через три последовательных этапа. Вместо того чтобы запланировать три этапа для каждого экземпляра отдельно, мы делаем всего три операции типа «операция 1 для 100 экземпляров», «операция 2 для 100 экземпляров» и так далее, намечая начало каждой с отставанием на срок, равный обработке одного экземпляра на предыдущем этапе.

• Финиш-финиш — этот вид связи используется, когда операции должны завершиться одновременно, хотя начинаться могли в разное время. Например, одновременно должна завершиться выверка перекрестных ссылок в разных главах книги.

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

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

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

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

• Определены ли результаты каждой операции?

• Действительно ли предшествующая операция необходима для начала последующей?

• Достаточно ли предшествующей операции для начала последующей?

• Обеспечивают ли указанные операции достижение запланированных результатов проекта (по сравнению с заданными в ИСР)?

• Указаны ли ресурсы, необходимые для выполнения каждой операции?

• Не введены ли ненужные ограничения (даты) операций?

• Все ли контрольные точки (из схемы ключевых событий) попали в план?

• Если длительность операции зависит от исполнителя, предусмотрена ли 100%-ная занятость данного исполнителя на данной операции?

• Все ли последовательности работ сходятся воедино к концу проекта? Если нет, объедините их хотя бы в контрольной точке «проект завершен».

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

5.7.2.2. Назначение ресурсов в диаграмме проекта

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

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

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

Метод эстафеты, используемый в ССРМ, подразумевает, что тех, от кого зависит длительность операции, вы назначаете только на выполнение данных работ. Занятость остальных можно расписать в разных долях, однако помните, что при выравнивании ресурсов результат может оказаться неожиданным. Компьютерная программа производит выравнивание по определенному алгоритму. Некоторые параметры этого алгоритма можно изменять, но затем программа будет неуклонно следовать заданным вами правилам. Так, если у вас есть исполнитель, временем которого вы можете распоряжаться на 100%, и вы назначаете его на две операции по 49% времени на каждую, при составлении графика компьютер может заложить параллельное выполнение этих операций. А если установите занятость 51%, программа вообще может спланировать начало второй операции только после завершения первой. (В некоторых программах можно производить выравнивание по задаваемым пользователем единицам времени, например дням, неделям или месяцам. Таким образом, сдвинется ли операция после выравнивания, будет зависеть от ее длительности, места в графике и загрузки исполнителя.) На рис. 5.5 приведен пример потенциальных неожиданных последствий выравнивания ресурсов. Что-то подобное наблюдалось на одном из проектов, где использовался метод критической цепи. Технари заявили, что ошибка в логике. Нет, с логикой все в порядке. Компьютер работает так, как его запрограммируют. В этом случае, вероятно, не следовало назначать ресурсы на операцию «проверка документа», если не предусматривалась полная занятость исполнителей на данной операции. В большинстве программ существует возможность вставлять примечания по каждой операции, где и можно было бы указать, кто будет проводить проверку. Обычно, экспериментируя в ходе работы, можно определить оптимальный способ моделирования загрузки по ресурсам в конкретных планах ваших проектов.

5.7.2.3. Степень детализации плана

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

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

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

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

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

Чем больше операций вы включаете, тем больше усилий тратится на составление плана. Если определенное количество усилий тратится на большее количество операций, значит, на каждую из них уйдет усилий меньше. А значит, и план будет менее точным, а не наоборот. Раз вы можете позволить себе потратить на составление плана больше усилий, стоит направить их на связки между операциями, проверить, все ли «входы-выходы» учтены правильно, посмотреть данные по исполнителям и рабочим процессам выполнения операций, а не добавлять в план новые записи.

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

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

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

5.7.3. ОЦЕНКА ДЛИТЕЛЬНОСТИ ОПЕРАЦИИ

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

Важно удостовериться, что оценка производилась, исходя из 100%-ной загрузки исполнителя. Если это не так, сократите длительность, не меняя при этом объем работ в человеко-часах или человеко-днях. Иными словами, если на выполнение операции требуется 50% времени одного инженера в течение 10 дней, спланируйте работы на 5 дней при полной занятости на них этого инженера.

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

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

5.7.4. И СНОВА ПРО НЕОПРЕДЕЛЕННОСТЬ

Проблема неопределенности в оценках ставит менеджеров проектов перед дилеммой. Руководство и заказчики гнут свою линию, заявляя: «Если точность показателей ниже х%, значит, вы плохо провели оценку!» Людям свойственно иметь неоправданно высокое мнение о своих прогнозах.

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

Проект по определению своему — нечто уникальное. Поэтому зачастую не хватает статистических данных, чтобы оценить степень неопределенности наших представлений о параметрах проектных операций. Подумайте, что нам известно о неопределенности. Попросите, чтобы кто-нибудь оценил постройку нового дома. У вас сразу же попросят спецификации. В Соединенных Штатах сегодня дом может потребовать вложений как в 80 000, так и в миллионы долларов. Определяющая характеристика — месторасположение дома. Второй по важности параметр — размер. И даже когда эти показатели определены, в ценах за квадратный фут может быть значительный разброс в зависимости от метода возведения, типа внутренней отделки и так далее. Разумеется, и у домов, одинаковых по расположению и другим характеристикам, цена может расходиться на 10%, в соответствии с тем, сколько продавец вложил в этот дом, насколько покупатель хорош в ведении переговоров, какова средняя рыночная стоимость жилья в данной местности, каковы мотивы продавца и пр.

Поэтому однозначно оценить дом мы не можем. А сколько стоит машина? Ситуация та же. Даже две абсолютно одинаковые машины у двух дистрибьюторов в одном и том же городе могут различаться в цене на 10%.

В одном бестселлере по управлению проектами (о названии которого из соображений гуманности умолчу) говорится: «Сначала прикидываем лишь порядок величин, для такой оценки — в первом приближении — не нужны никакие технические подробности. Точность анализа в целом может составлять плюс-минус 35%». (Я думал, под «порядком величины» подразумеваются десятки. Увы.) Через несколько предложений идет следующий текст: «Определенная оценка, также называемая детальной, имеет степень вероятности плюс-минус 5%». Минуточку! Мы же только что видели с вами, что фактические затраты на реальный автомобиль известной марки серийного, так сказать, производства, то есть на идентичные объекты могут в одном и том же месте в одно и то же время расходиться на величину, вдвое большую. Как можно ожидать, что оценка чего-то малоизведанного будет вдвое более точной?

Другой источник утверждает, что в проектах, где риски невелики, оценки пакетов работ имеют неопределенность 2%, операции — 5%, группы операций — 10%, проект в целом — 20%, а программа — 35%. Иными словами, утверждается, что при сложении отдельных оценок с низкой степенью неопределенности мы в итоге получаем большую неопределенность. Автор просто перечеркнул законы статистики! (Может быть, по ошибке данные привели в обратном порядке?)

Интересно отметить, что во многих трудах по управлению проектами повторяются одни и те же данные о степени точности оценок затрат. Однако никто нигде не указывает источник этих данных. Единственная ссылка — на руководство по оценке затрат в строительстве, где приводятся показатели вероятности оценок, не вполне соответствующие упомянутым выше положениям о точности оценки проектов и программ. Так, «Государственное руководство к составлению смет в строительстве» (National Construction Estimator) [8] утверждает:

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

Естественно, в других проектах, таких как научно-исследовательские разработки или создание ИТ-систем, степень неопределенности намного выше, чем при строительстве с подробнейшими спецификациями.

И наконец, мне не удалось найти ни одной книги, где бы давалось операциональное определение понятию «точность» именно с использованием амплитуды «плюс-минус 35%». Можно было бы предположить, что это величина стандартного отклонения, что это «граничная точка» или число с вероятностью 99%, если брать нормальное распределение, что, вероятно, будет неправомерно по отношению к оценке затрат. (Если не ошибаюсь, по данному определению точность составит плюс-минус 115%. Нет, ну минус-то уж точно быть не может!) Одинаковый ли смысл мы вкладываем в слово «точность»?

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

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

Если для участников проекта характерны модели поведения, описанные в главе 2, положительные колебания проявить себя не смогут. Одна задержка на критической цепи — и сорван срок всего проекта. Кроме того, поскольку расходование средств идет по принципу «все или ничего», увеличение длительности работ приведет к превышению бюджета. Учитывая все вышесказанное, превышение будет значительным. Такие перерасходы не являются частью новой парадигмы управления проектами методом критической цепи, поскольку ССРМ искореняет причины превышения плановых показателей.

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

5.8. Буфер на затраты

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