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

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

Breakdown (Декомпозиция) — разделение на части или категории, выделение простых составляющих.

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

Эти определения означают, что иерархическая структура работ имеет следующие характеристики:

  • Описывает с необходимой точностью содержание работ по проекту.
  • Определяет весь объем работ по проекту.
  • Формируется в виде иерархической структуры (проект декомпозируется на пакеты/субпакеты и т. д. работ).
  • Представляет объем работ по пакету как перечень работ, имеющих измеримый или сравнимый результат.
  • Имеет объективный или измеримый результат, который рассматривается как результат работы по пакету или совокупность результатов работ.

Содержание

Литература

По оценкам экспертов [10] , путем декомпозиции определяется примерно 90% от общего объема работ. Системный подход позволяет увеличить точность декомпозиции.

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

Иерархическая структура работ Стадии управления проектом Инициация

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

Рис. 4.7.Пример иерархической структуры работ, организованной по фазам [9]

Выходные документы процесса создания ИСР

Описание содержания проекта (обновления)

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

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

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

Словарь ИСР

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

Базовый план по содержанию

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

Базовый план по содержанию проекта является основой для составления двух других базовых планов проекта: базового плана по стоимости и базового расписания.

План управления содержанием проекта (обновления)

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

Запрошенные изменения

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

Подтверждение содержания

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

Входной информацией процесса являются:

· описание содержания проекта;

· словарь ИСР;

· план управления содержанием проекта;

· результаты поставки.

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

Процесс подтверждения содержания имеет нижеследующие результаты.

Принятые результаты поставки. Процесс подтверждения содержания документирует результаты поставки, которые прошли приемку.

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

Запрошенные изменения. Запрошенные изменения могут появиться в ходе процесса подтверждения содержания и рассматриваются в ходе процесса общего управления изменениями.

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

⇐ Предыдущая9101112131415161718Следующая ⇒



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

  • в английском языке – Work Breakdown Structure (или WBS-структура)
  • в русском – структурная декомпозиция работ проекта (СДР) или иерархическая структура работ (ИСР).

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

Содержание статьи

Определение и характеристики WBS

Структурной декомпозицией работ (Work Breakdown Structure) называют представление проекта, исполненное в виде иерархической структуры работ, что достигается посредством последовательной декомпозиции. Инструмент направлен на детальное планирование, оценку стоимости, определение и распределение персональной ответственности исполнителей и т. д. – то есть, на основные работы и результаты, определяющие содержание проекта.

В Work Breakdown Structure элементами проекта могу быть услуга, продукт, работа или группа работ (wbs group). Каждый нижестоящий уровень в иерархии детализирует какой-либо элемент вышестоящего уровня, но при этом должны быть соблюдены следующие принципы:

  1. Принцип «Правильного дерева». Идея в том, чтобы у каждого зависимого элемента (у каждой «ветки» или, при ещё более дробном разделении, – у каждого «листа») был только один родительский элемент.
  2. Принцип полноты и логической стройности. В СДР должны учитываться все элементы проекта, однако ничего не должно дублироваться.
  3. Принцип единства критерия. Процесс декомпозиции должен происходить по одному критерию, поэтому, например, нельзя вперемежку работать сразу и с продуктом, и с функциональными задачами.
  4. Принцип глубины СДР. Разделение должно производиться до тех пор, пока получившаяся структура не будет легко управляемой и контролируемой. Чаще всего этот процесс заканчивается при структурировании до уровня элементарной работы – такой, которую способен выполнить один сотрудник, или которую можно контролировать как отдельную единицу.

Воплощение данных принципов в проекте приводит к тому, что иерархическая структура работ приобретает определённые характеристики, а именно:

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

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

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

Алгоритм построения иерархической структуры работ

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

Пример № 1:

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

Пример № 2 с использованием стикеров и флипчарта:

  • У участников проекта, работающих в команде, нужно узнать, что, по их мнению, необходимо для реализации проекта.
  • Все ответы на этот вопрос участники проекта записывают на стикерах.
  • Близкие и совпадающие ответы о наиболее значимых задачах группируются в стопки или вывешиваются на демонстрационной доске в тематических колонках.
  • Те задачи, которые не попали ни в какую колонку, клеятся отдельно.
  • Колонкам или стопкам со сгруппированными задачами даётся наименования, которые записываются на флипчарт (с соответствующим набором стикеров под каждой категорией).

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

Если в создании Work Breakdown Structure используются программы управления проектами – например, самая распространённая MS Project или её аналоги – то:

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

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

  • Продолжительность, или полное время выполнения каждой задачи.
  • Зависимость и взаимосвязь между задачами, которую можно установить с помощью сетевой диаграммы.
  • Ограничения для каждой задачи (если есть).
  • Даты начала и конца выполнения задачи (при указании параметра длительности программа эти даты вычисляет автоматически).
  • Наименования ресурсов.

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

Технология иерархической структуры работ

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

WBS как инструмент управления в различных проектных проявлениях

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

  • Для определения проектных результатов.
  • Для организации коммуникаций. WBS помогает осуществлять направленную передачу информации с учётом задачи и ответственности участника за её исполнение.
  • Для документирования и отчётности. Документальное отражение WBS проявляется в общей терминологии, в формировании бюджета «сверху-вниз», в составлении отдельной отчётности, соответствующей структуре WBS.
  • Для оптимизации управления и типизации уровней. Так в тематической литературе рекомендуют использовать не более 6 уровней, где верхние 3 предназначены для информации уровня заказчика, а нижние 3 – уровня исполнителя. Но, в первую очередь, глубина детализации должна быть ориентирована на сложность и размер проекта.

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

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

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

·Повышения точности оценок по стоимости, времени, ресурсам;

·Определения основы для измерения и контроля хода выполнения;

·Распределения ответственности.

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

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

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


При «Уточнении содержания» применяются: шаблоны иерархических структур работ и декомпозиция.

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

При формировании ИСР целесообразно пользоваться рядом правил:

·Работы, не включенные в ИСР, не являются работами настоящего проекта.

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

·Нижний уровень ИСР включает в себя пакеты работ.

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

Что такое WBS структура проекта?

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

В качестве примера рассмотрим конкретный проект внедрения программного обеспечения в бизнесе, распределенном по территории округа. Работы по подготовке велись уже не один месяц. Проект, казалось, вышел на финальную стадию – оставалось установить ПО и оборудование, закончить незначительные доработки и произнести известную фразу Юрия Гагарина. Был разработан план работ финальной стадии. Заказчик проекта для дополнительной проверки плана перед утверждением, пригласил консультанта по управлению проектами. На совещании команде проекта было предложено составить ИСР, опираясь на подготовленный план. В процессе составления выяснилось, что имеющиеся серверные мощности достаточны для запуска системы. Но для полноценной эксплуатации необходимо приобретать новое оборудование – как минимум неучтенное удорожание проекта. Поскольку пользователи новой системы удалены от центрального офиса, должны в совершенстве владеть программным обеспечением необходимо подготовить учебные видеоматериалы и системы проверки знаний. Наконец, один из ключевых разработчиков задумчиво произнес «А как мы собираемся запускать систему, если у нас нет даже перечня бизнес-процессов блока такого-то…?».

Через несколько месяцев проект был приостановлен для доработки регламентов и программы в этом разделе.

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

=  Перейти к содержанию  =

Для чего нужен файловый формат .WBS?

Основная ассоциация файлового расширения .wbs принадлежит типу и формату файлов «Сайт WYSIWYG Web Builder» (.wbs). WYSIWYG Web Builder — это коммерческий визуальный редактор веб-сайтов в стиле WYSIWYG («Что видишь, то и получишь») для Майкрософт Windows от Pablo Software Solutions.

Файл .wbs представляет собой проект веб-сайт, созданный при помощи WYSIWYG Web Builder. Это единый сжатый файл-контейнер, в котором хранятся все страницы сайта, вся графика, настройки, шаблоны и прочие имеющие отношение к данному сайту данные. WBS является закрытым частным форматом, чтение и запись которого возможно лишь в среде WYSIWYG Web Builder. Подобные файлы .wbs относятся к файлам этапа разработки, а любой готовый сайт публикуется уже в виде набора файлов .htm(l), .css, .php и других в рамках соответствующей структуры каталогов.



Проекты сайтов WBS, созданные и сохраненные с помощью пиратской копии WYSIWYG Web Builder, могут оказаться поврежденными и не открываться в лицензионном экземпляре редактора.

Иерархическая структура работ — важный инструмент коммуникации участников проекта

Проекты веб-сайтов (.wbs) по умолчанию сохраняются в каталог «Документы\WYSIWYG Web Builder».


Помимо этого, расширение .wbs обозначает тип/формат файлов «Файл схемы WBS Chart Pro» (.wbs), используемые в рамках коммерческого средства управления проектами WBS Chart Pro от Critical Tools, Inc. для среды Майкрософт Windows. Применяемая в сочетании с Майкрософт Project программа WBS Chart Pro позволяет создавать и отображать схемы структурной разбивки работ (Work Breakdown Structure, WBS). Файл .wbs и представляет собой такую WBS-схему, созданную с помощью WBS Chart Pro. Файлы .wbs используют текстовый XML-формат.


Другой случай применения расширения .wbs связан с типом и форматом файлов «Проект Content Matrix Console – Web Edition» (.wbs). Content Matrix Console – Web Edition (CMC-WE) от Metalogix представляет собой средство по управлению содержимым, ориентированное на перенос веб-сайтов на системы уровня предприятия на базе Майкрософт SharePoint. Здесь файл .wbs — это сохраненный в закрытом частном формате проект CMC-WE. В среде CMC-WE файлы проектов WBS не «открываются», а служат точкой подключения и предполагают использование рабочих областей.


Кроме того, расширение .wbs также служит обозначением типа/формата файлов «Файл весовых и центровочных данных Voyager» (.wbs), используемых в рамках комплексной системы планирования и сопровождения полетов гражданской авиации Voyager от Seattle Avionics. Применительно к Voyager в файле .wbs хранятся данные массы и центровки летательного аппарата, учитываемые во время подготовки полета.

Программы для открытия или конвертации WBS файлов

Вы можете открыть файлы WBS с помощью следующих программ: 

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 Как назовешь, так и поплывешь

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

 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *