Главная Все Маркетинг Я — менеджер проекта! Глава 2

Я — менеджер проекта! Глава 2

ГЛАВА 2.1: «СОДЕРЖАНИЕ ПРОЕКТА, СТРУКТУРА РАБОТ И РЕЗУЛЬТАТОВ» 2.2 И 2.3: ВЗАИМОСВЯЗИ ОПЕРАЦИЙ И ПЛАНИРОВАНИЕ РЕСУРСОВ

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

2 ГЛАВА.
ПЛАНИРОВАНИЕ РАБОТ ПРОЕКТА

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

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

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

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

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

2.1 СОДЕРЖАНИЕ ПРОЕКТА — СТРУКТУРА РАБОТ И РЕЗУЛЬТАТОВ

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

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

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

 

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

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

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

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

2.1.1 ИЕРАРХИЧЕСКАЯ СТРУКТУРА ПРОДУКТА

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

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

  1. Домик
    • 1.1 Фундамент
    • 1.2 Коробка
      • 1.2.1 Стены
      • 1.2.2 Пол
      • 1.2.3 Потолок
    • 1.3 Крыша

Или так:

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

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

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

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

2.1.2 ИЕРАРХИЧЕСКАЯ СТРУКТУРА РАБОТ

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

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

  1. Строительство домика
    • 1.1 Управление проектом
    • 1.2 Проектирование
    • 1.3 Получение разрешений
    • 1.4 Строительство
      • 1.4.1 Устройство фундамента
      • 1.4.2 Устройство коробки
        • 1.4.2.1 Кладка стен
        • 1.4.2.2 Настилка полов
        • 1.4.2.3 Устройство потолков
      • 1.4.3 Устройство крыши
    • 1.5 Сдача/Приемка

 

Или такой:

 

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

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

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

2.1.3    ДВА УРОВНЯ СОДЕРЖАНИЯ ПРОЕКТА

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

 

2.1.4    ПРОЕКТ – ПРОИЗВОДСТВО ПРОДУКТА? И ДА, И НЕТ

 

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

2.1.5 ДЕКОМПОЗИРОВАННАЯ РАБОТА СТАНОВИТСЯ ГРУППОЙ РАБОТ

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

2.1.6   МНОЖЕСТВЕННОСТЬ ИЕРАРХИЙ

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

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

2.1.7   ОРИЕНТАЦИЯ НА РЕЗУЛЬТАТЫ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.8 ИСР – ГРУППИРОВКИ РАБОТ, ОПЕРАЦИИ – РЕАЛЬНЫЕ РАБОТЫ

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

2.1.9   КОНТРОЛЬНЫЕ СОБЫТИЯ И ВЕХИ

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

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

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

2.1.10 КАК НАЗОВЕШЬ, ТАК И ПОПЛЫВЕШЬ

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

 

2.2      ВЗАИМОСВЯЗИ ОПЕРАЦИЙ

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

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

2.2.1     ТИПЫ ЗАВИСИМОСТЕЙ

Есть три типа зависимостей между операциями:

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

2.2.2     ВИДЫ ЗАВИСИМОСТЕЙ

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

  • Финиш-Старт – финиш предшествующей связан со стартом последующей, т.е. последующая начинается после завершения предшествующей
  • Старт-Старт – старт предшествующей связан со стартом последующей, т.е. последующая начинается одновременно со стартом предшествующей
  • Финиш-Финиш – финиш предшествующей связан с финишом последующей, т.е. последующая завершается одновременно с завершением предшествующей
  • Старт-Финиш – старт предшествующей связан с финишом последующей, т.е. последующая завершается до начала предшествующей

Все разновидности зависимостей представлены на рисунке:

 

2.2.3     ОПЕРЕЖЕНИЯ И ЗАДЕРЖКИ

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

2.2.4     ДИАГРАММА ПРЕДШЕСТВОВАНИЯ – МОДЕЛЬ ЗАВИСИМОСТЕЙ ОПЕРАЦИЙ

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

Сетевая диаграмма проекта показывает набор операций и логику их последовательностей – кто за кем. Заметьте, что в этой диаграмме нет никаких характеристик самих операций, например, сроков или длительностей – только логика: что и в какой последовательности должно делаться в проекте. Эта диаграмма является важнейшим промежуточным шагом на пути к значимой цели – расписание проекта, для получения которого не хватает только одного – длительности операций. Но про это поговорим ниже.

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

Проще пояснить это на примере:

Планирование для себя и для других.

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

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

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

Почему так? Непонятно…

Пример, конечно, утрирован, но это – правда жизни. И вполне понятно, почему так получается: в обоих случаях мы вносим в процесс планирования весьма существенные привходящие обстоятельства – свои личные интересы. И искажаем планы работ.

2.3      ПЛАНИРОВАНИЕ РЕСУРСОВ

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

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

2.3.1     ВИДЫ РЕСУРСОВ ПРОЕКТОВ

Ресурсы делятся на:

  • Возобновляемые – люди и оборудование
  • Не возобновляемые – материалы

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

2.3.2     ДЕНЬГИ – ЭТО МАТЕРИАЛЫ!  

Для управления проектами деньги – это разновидность материалов, они, как и кирпичи, безвозвратно расходуются в процессе деятельности. Особенно смущает то, что любые работы можно купить, их не обязательно производить самому. Тут можно сказать только одно: деньги — это универсальный ресурс, это тот же кирпич, разве что золотой, который можно легко обменять на любой другой ресурс. Хуже того, деньги, как и кирпичи, очень многообразны – разные валюты, акции, кредиты, …, — продолжайте дальше сами. Ну и уж если у кого-то еще остались сомнения по поводу денег, то сообщаю, что все проекты, кроме тех, которые оформлены как юридические лица, денег вообще не имеют! Просто потому, что их негде хранить – нет расчетного счета. Что же они имеют? Да очень просто – они имеют не деньги, а обещания своей родной исполняющей организации оплатить услуги поставщиков и подрядчиков.

2.3.3     ИЕРАРХИЧЕСКАЯ СТРУКТУРА РЕСУРСОВ

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

2.3.4     РЕСУРСЫ НЕ ТОЛЬКО РАСХОДУЮТСЯ, НО И ПРОИЗВОДЯТСЯ

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

2.3.5 КАЛЕНДАРИ РЕСУРСОВ И ОПЕРАЦИЙ

Еще один существенный момент такой: ресурсы, особенно человеческие, доступны не всегда. Есть трудовое законодательство, есть трудовые договора, есть рабочее и нерабочее время, есть выходные, отпуска и болезни, и все это существенно ограничивает доступность людских ресурсов для производства. И все это необходимо учитывать при разработке расписания проекта. Общепринятый подход такой: для ресурсов определяются календари доступности, которые с точностью до секунды показывают, когда ресурс доступен для использования в проекте, а когда – нет. Так как материалы и оборудование могут использоваться в проекте только вместе с людьми, то основным календарем ресурсов оказывается календарь человеческих ресурсов. А основным календарем проекта, его еще называют календарем по умолчанию, оказывается календарь доступности основной массы исполнителей проекта. Обычно это 40-ка часовая пятидневка с праздничными днями.

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

2.3.6     ПОТРЕБНОСТЬ ОПЕРАЦИЙ В РЕСУРСАХ

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