УПРАВЛЕНИЕ ПРОЕКТАМИ

Самоучители ♦ Справочники по стандартам УП ♦ Имитатор экзамена PMP ♦ Обучение

Разработка календарного плана проекта: 3
Сергей Вратенков. Планирование работ проекта
First Prev 1 2 3 4 5 6 7 Next Last

2 Планирование работ проекта

Сердцевиной управления проектами являются два процесса – планирование и контроль проекта. По объему планирование составляет около половины всей области знаний управления проектами. Эту самую половину можно оценивать разными способами, например, по количеству процессов (~20 из ~40), или по количеству страниц в стандартах ISO или PMBOK. А по концептуальной значимости – может даже больше половины, так как суть концепции управления проектом – контроль исполнения плана, значит, план проекта – это основа, фундамент, база управления проектом, а разработка плана – это основа профессиональных умений менеджера проекта.

Основным объектом управления в проекте является работа. В этой главе мы рассмотрим основу основ управления проектами – планирование работ проекта. Планирование работ проекта еще называют разработкой календарного плана проекта.

Хотя современные методики управления проектами обычно не настаивают на некой строго определенной последовательности разработки плана работ, однако шаги планирования образуют строгую логическую цепочку, в которой результаты каждого шага являются необходимыми входными данными для последующего шага. И эта цепочка такова: потребности – результаты – структура работ – операции – ресурсы – сроки – стоимость. Тех читателей, которым цепочка показалась слишком длинной, возможно утешит то соображение, что эта цепочка – основа профессиональных знаний руководителя проектов и в таком качестве она может быть и не так уж длинна. Мы будем строго придерживаться этой последовательности не только и не столько потому, что так принято, или так говорит стандарт ISO или PMBOK, сколько потому, что именно такова внутренняя логика процесса разработки плана работ. Предвижу возражение такого типа, мол, в жизни все не так! Мол, любой профессионал без проблем начнет с конца цепочки – со стоимости, он не задумываясь и не выстраивая никаких цепочек, сразу оценит стоимость работы, да еще и со своим наваром. Не сомневаюсь! Сомневаюсь в другом – что он сможет убедить заказчика и тем более получить с него деньги без понятных пояснений. А единственное убедительное пояснение – это именно логика процесса.

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

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

 

2.1 Содержание проекта – структура работ и результатов

Стандарты управления проектами объединяют работы и результаты проекта одним термином: «содержание» проекта, или, по-английски, «scope». Вот, для примера, определение PMBOK:

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

Современное программное обеспечение для календарного планирования проектов исповедует такой же подход – результаты являются разновидностью работ и моделируются как квази-работы с нулевой длительностью. Такой подход является практичным, но он вольно или невольно скрывает принципиально разные роли, которые исполняют в проектах работы и результаты.  Мы же должны внести полную ясность в этот вопрос, и я вынужден озвучить пусть и очевидные, но принципиальные для адекватного понимания сути проектов, слова. Итак.

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

Для проекта первичными являются именно результаты, а не работы. Работы исполняются только те и только такие, которые обеспечат нужные результаты, а не наоборот – мы исполняем работы те и такие, которые нам нравятся, чисто из любви к искусству, а уж что получится – то и получится.

Я все это веду к тому, что планирование проекта производится от результатов к работам, то есть работы проекта определяются требуемыми результатами, а исполнение – наоборот, от работ – к результатам, или, работы создают результаты.

 

2.1.1 Иерархическая структура продукта

Общепринятым инструментом представления результатов является ИСП - Иерархическая структура продукта (PBS - Product Breakdown Structure), которая описывает состав и иерархию компонентов продукта.

Для небольшого домика Иерархическая структура продукта может выглядеть так:

  1. Домик
    1. Фундамент
    2. Коробка
      1. Стены
      2. Пол
      3. Потолок
    3. Крыша

 

Или так:

Иерархическая структура продукта

Рисунок 2.1. Иерархическая структура продукта

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

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

Не очевидно следующее: где предел декомпозиции? До какого уровня декомпозировать? Ведь если вовремя не остановиться, то можно добраться до молекул и атомов! Ответ может быть таким. Глубина декомпозиции определяется потребностями управления созданием объекта. А именно, если создателям результата все ясно и понятно про очередную составляющую, то дальше делить ее не имеет смысла. Если же есть неясности, то значит, надо декомпозировать, причем именно для того, чтобы снять неясности. Остается вопрос насчет «ясно и понятно» - как определить, ясно или неясно? Тут ответ может быть таким. Ясно и понятно должно быть всем лицам, принимающим решения по результату и его составляющим. Управленческие решения, типа: «будем производить результат именно такой, из именно таких составляющих». А раз решение управленческое, то надо обратиться к троице управленческих показателей: сроки, стоимость, качество. Так как мы говорим сейчас не о работах, а о результатах, то в первую очередь нас интересуют не сроки и стоимость, а качество, то есть характеристики и спецификации составляющих. И тогда можно сказать так:

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

 

2.1.2 Иерархическая структура работ

Общепринятым инструментом представления работ проекта является ИСР - Иерархическая структура работ (WBS - Work Breakdown Structure), которая описывает состав и иерархию работ проекта.

Иерархия работ для нашего домика может быть такой:

  1. Строительство домика
    1. Управление проектом
    2. Проектирование
    3. Получение разрешений
    4. Строительство
      1. Устройство фундамента
      2. Устройство коробки
        1. Кладка стен
        2. Настилка полов
        3. Устройство потолков
      3. Устройство крыши
    5. Сдача/Приемка

 

Или такой:

Иерархическая структура работ

Рисунок 2.2. Иерархическая структура работ

Здесь опять существенен не способ представления, а иерархичность, то есть разбиение работ на под-работы и вызванные этим группировки работ.

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

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

 

2.1.3 Два уровня содержания проекта

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

 

2.1.4 Проект – производство продукта? И да, и нет

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

 

2.1.5 Декомпозированная работа становится группой работ

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

 

2.1.6 Множественность иерархий

Посмотрите на две разные иерархии одних и тех же работ:

Иерархическая структура работ

Рисунок 2.3. Первая иерархия работ

Иерархическая структура работ

Рисунок 2.4. Вторая иерархия работ

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

 

2.1.7 Ориентация на результаты

С точки зрения планирования, работы являются следствием результатов, а с точки зрения исполнения, все наоборот – результаты являются следствием работ.  Вы можете спросить – на что же опираться? Я отвечу вопросом на вопрос: что важнее – правильные работы или правильные результаты? Кто-то может возмутиться: - так вопрос ставить нельзя, важно и то, и другое. Согласен, важно и то и другое. Но в нашем мире одно все же важнее другого. Позвольте небольшое философское отступление.

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

С другой стороны, согласитесь, результаты всегда виднее и ощутимее, чем работы. Результат, я уж не говорю про конечный продукт, можно пощупать, примерить, проверить. А работа? – Когда не делаешь ее сам, остается только смотреть, как работают другие – весьма интересное занятие.

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

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

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

Вот определение PMBOK:

Иерархическая структура работ (ИСР)ориентированная на результаты иерархия работ.

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

В примере с двумя разными иерархиями «стены-полы-потолок» и «сборка-отделка» - которая лучше ориентирована на результаты?

 

2.1.8 ИСР – группировки работ, операции – реальные работы

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

 

2.1.9 Контрольные события и вехи

Контрольные события и вехи – это важные моменты и события проекта. Они соотносятся с операциями так же как результаты с работами: контрольные события - это «результаты» операций. В программном обеспечении управления проектами контрольное событие – это квази-операция с нулевой длительностью.

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

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

 

2.1.10 Как назовешь, так и поплывешь

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

 

First Prev 1 2 3 4 5 6 7 Next Last