Введение
Разбиение проекта на более мелкие компоненты, ориентированное на результаты. Структура декомпозиции работ (СДР) в управлении проектами и системной инженерии – это разбиение проекта на более мелкие компоненты, ориентированное на результаты. СДР является ключевым элементом управления проектами, который организует работу команды в управляемые разделы. Руководство по управлению проектами (PMBOK) определяет СДР как «иерархическое разложение общего объема работ, необходимого для выполнения командой проекта с целью достижения целей проекта и создания требуемых результатов». СДР предоставляет необходимую основу для детальной оценки и контроля затрат, а также служит руководством для разработки и контроля графика.
Обзор
WBS – это иерархическое и поэтапное разложение проекта на результаты (от крупных, таких как этапы, до самых мелких, иногда называемых пакетами работ). Это древовидная структура, демонстрирующая разделение усилий, необходимых для достижения цели, например, программы, проекта или контракта. Структура разбивки работ (СБР) обеспечивает общую основу для последовательного развития общего планирования и контроля контракта и является основой для разделения работы на четко определенные этапы, на основе которых разрабатывается техническое задание и устанавливается отчетность по техническим аспектам, срокам, стоимости и затратам рабочего времени. Этот метод (иногда называемый структурой разбивки системы) используется для определения и организации общего объема проекта. СБР организуется вокруг основных продуктов проекта (или запланированных результатов), а не работы, необходимой для создания этих продуктов (планируемых действий). Поскольку запланированные результаты являются желаемыми итогами проекта, они формируют относительно стабильный набор категорий, в которых можно аккумулировать затраты на планируемые действия, необходимые для их достижения. Хорошо спроектированная СБР позволяет легко отнести каждую проектную задачу к одному и только одному конечному элементу СБР. Помимо функции учета затрат, СБР также помогает сопоставлять требования между различными уровнями спецификаций системы, например, с помощью матрицы перекрестных ссылок, связывающей функциональные требования с проектной документацией высокого или низкого уровня. СБР может быть представлена горизонтально в виде структуры или вертикально в виде древовидной схемы (как организационная структура). Разработка СБР обычно происходит в начале проекта и предшествует детальному планированию проекта и задач. В ходе итеративного процесса управления проектами детали плана управления проектом и объем информации уточняются, а первоначальные оценки таких параметров, как описание объема проекта, планирование и бюджет, становятся более точными. Это также помогает проектной команде разработать более детальный план проекта.
Правило 100%
Важным принципом проектирования структур разбивки работ является правило 100%. Оно определяется следующим образом:
Правило 100% гласит, что СБР включает в себя 100% работы, определенной областью применения проекта, и охватывает все результаты – внутренние, внешние, промежуточные – с точки зрения работы, которую необходимо выполнить, включая управление проектом. Правило 100% является одним из важнейших принципов, определяющих разработку, декомпозицию и оценку СБР. Это правило применяется на всех уровнях иерархии: сумма работ на уровне "дочерних" элементов должна равняться 100% работы, представленной "родительским" элементом, и СБР не должна включать в себя работу, выходящую за рамки фактической области проекта, то есть не может включать более 100% работы. Важно помнить, что правило 100% также применимо к уровню задач. Объем работ, представленный задачами в каждом пакете работ, должен составлять 100% работы, необходимой для завершения этого пакета работ.
Взаимно исключающие элементы
Взаимно исключающие: помимо правила 100%, определения объемов работ различных элементов структуры разбивки работ не должны пересекаться. Такая неоднозначность может привести к дублированию работы или недопониманию в отношении ответственности и полномочий. Подобное пересечение также может затруднить учет затрат по проекту.
Планируйте результаты, а не действия
Если разработчик структуры декомпозиции работ (СДР) попытается включить в СДР детали, ориентированные на действия, он, скорее всего, либо включит слишком много действий, либо слишком мало. Слишком большое количество действий приведет к превышению 100% объема родительского элемента, а слишком малое – к неполному охвату 100% объема родительского элемента. Лучший способ соблюдать правило 100% – определять элементы СДР с точки зрения результатов, а не действий. Это также гарантирует, что СДР не будет излишне предписывать методы, предоставляя участникам проекта больше возможностей для проявления изобретательности и творческого подхода. При реализации проекта, связанного с предоставлением профессиональных услуг, распространенной практикой является фиксация всех запланированных результатов для создания СДР, ориентированной на результаты. Структуры декомпозиции работ, которые разделяют работу по фазам проекта (например, фаза предварительного проектирования, фаза критического проектирования), должны обеспечивать четкое разделение фаз посредством результатов, которые также используются для определения критериев входа и выхода (например, утвержденный предварительный или критический обзор проекта).
Структура распределения по продуктам (PBS)
Для проектов по разработке новых продуктов наиболее распространенным способом обеспечения ориентированности WBS на результат является использование структуры разбивки продукта (PBS).
Разработка с учетом особенностей
В проектах, ориентированных на функциональность, может использоваться схожий подход с WBS – структура декомпозиции функциональных возможностей.
Уровень детализации
Нужно решить, когда прекратить делить работу на более мелкие элементы. Для большинства проектов достаточно иерархии из двух-четырех уровней. Это поможет определить продолжительность задач, необходимых для создания результата, определенного в СБУ. Существует несколько эвристик или "эмпирических правил", используемых при определении подходящей продолжительности задачи или группы задач, необходимых для создания конкретного результата, определенного в СБУ. Первое – это "правило 80 часов", которое означает, что ни одна задача или группа задач на самом низком уровне детализации СБУ для создания единого результата не должна требовать более 80 часов работы. Второе эмпирическое правило заключается в том, что ни одна задача или группа задач на самом низком уровне детализации СБУ не должна быть длиннее одного отчетного периода. Таким образом, если команда проекта отчитывается о прогрессе ежемесячно, то ни одна задача или серия задач не должна длиться более одного месяца. Последняя эвристика – правило "если это логично". Применяя это эмпирическое правило, можно использовать "здравый смысл" при определении продолжительности задачи или группы задач, необходимых для создания результата, определенного в СБУ.
Словарь WBS
Если названия элементов WBS неоднозначны, словарь WBS может помочь уточнить различия между этими элементами. Словарь WBS описывает каждый компонент WBS, включая вехи, результаты, работы, объем и, иногда, даты, ресурсы, стоимость и требования к качеству. Согласно Институту управления проектами, словарь WBS определяется как «документ, содержащий подробную информацию о результатах, работах и графике для каждого компонента структуры разбивки работ».
Крайний элемент
Самый нижний элемент в древовидной структуре, терминальный элемент, – это элемент, который не подлежит дальнейшему делению. В структуре разбиения работ (СРР) такие элементы (работы или результаты), также известные как пакеты работ, являются объектами, для которых оцениваются потребности в ресурсах, бюджет и продолжительность; они связаны зависимостями и включены в график. На пересечении элемента СРР и организационной единицы устанавливаются контрольные счета и пакеты работ, а также планируется, измеряется, регистрируется и контролируется исполнение. СРР может быть детализирована до любого необходимого уровня. Рекомендуется как минимум три уровня, с добавлением дополнительных уровней только для элементов с высокой стоимостью или высоким риском. В некоторых случаях, таких как системная инженерия или управление программами, может потребоваться два уровня детализации. Стандарт содержит примеры СРР различной глубины, например, для разработки программного обеспечения – до 5 уровней, а для системы управления огнем – до 7 уровней.
Соответствует нормам
Высший уровень структуры WBS должен соответствовать существующим в организации или отрасли нормам и шаблонам. Например, при строительстве кораблей для ВМС США необходимо учитывать, что морская терминология и ее иерархическая структура, зафиксированные в стандарте MIL STD, являются неотъемлемой частью кораблестроения, а организационная структура и процедуры ВМС разработаны в соответствии с этой структурой. Поэтому любые существенные изменения в нумерации или наименовании элементов WBS в иерархии будут недопустимы.
Пример
На прилегающем рисунке показана техника построения структуры декомпозиции работ (СДР), демонстрирующая правило 100% и технику "прогрессивной детализации". На первом уровне СДР (WBS Level 1) показано 100 единиц работы, представляющих общий объем проекта по разработке и изготовлению велосипеда на заказ. На втором уровне СДР (WBS Level 2) эти 100 единиц разделены на семь элементов. Количество единиц, выделяемых каждому элементу работы, может основываться на трудозатратах или стоимости; это не является оценкой длительности задачи. Три наиболее крупных элемента второго уровня СДР (WBS Level 2) дополнительно детализированы на третьем уровне (Level 3). Два крупнейших элемента на третьем уровне (Level 3) составляют лишь 17% от общего объема проекта. Эти более крупные элементы могут быть далее разделены с использованием техники прогрессивной детализации, описанной выше. Это пример подхода, основанного на продукте (который может быть конечным продуктом, результатом или работой), в отличие от поэтапного подхода (который может представлять собой контролируемые этапы в формальном жизненном цикле разработки систем), подходов, основанных на вынужденных событиях (например, ежеквартальных отчетах или пересмотрах бюджета по итогам финансового года), или подходов, основанных на навыках/ролях. Проектирование СДР может поддерживаться программным обеспечением (например, табличным процессором), позволяющим автоматически суммировать значения. Оценки трудозатрат или стоимости могут быть разработаны в ходе обсуждений между членами проектной команды. Эта совместная техника способствует более глубокому пониманию определения объема работ, лежащих в его основе предположений и достижению консенсуса относительно необходимого уровня детализации для управления проектами.