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

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

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

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

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

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

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

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

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

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

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

Или так:

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

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

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

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

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

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

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

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

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

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

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

Или такой:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И вообще, в иерархии работ «истинные работы» находятся в листьях дерева, то есть в низу каждой ветки, а все узлы дерева работ – это группы работ.

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

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

Иерархия «стены-пол-потолок»

Иерархия «стены-пол-потолок»

Иерархия «сборка-отделка»

Иерархия «сборка-отделка»

Первая иерархия группирует работы по категориям «стены-пол-потолок», вторая – по категориям «сборка-отделка».

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

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

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

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

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

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

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

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

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

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

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

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

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

Декомпозиция: главное – вовремя остановиться!

Декомпозировать можно до бесконечности и вопросы типа: «До какого уровня декомпозировать?», «Есть ли оптимальная глубина декомпозиции?», и так далее, оказываются не просто любопытными, а определяющими.

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

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

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

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