Руководство pmbok ® Шестое издание
Yüklə 12,83 Mb. Pdf görüntüsü
|
|
Часть 1 - Руководство
u u цели расписания, включая сведения о том, принесли ли полученные результаты те выгоды, ради которых был предпринят проект. Если выгоды не получены к моменту закрытия проекта, следует указать, в какой мере они были получены, и дать оценку перспектив реализации выгод в будущем. u u сводная информация о том, как конечный продукт, услуга или результат обеспечили бизнес-потребности, предусмотренные в бизнес-плане; Если бизнес-потребности к моменту закрытия проекта не удовлетворены, следует указать, в какой мере они были удовлетворены, и дать оценку сроков, когда бизнес-потребности будут удовлетворены в будущем. u u
какие меры были приняты для их устранения. 4.7.3.4 ОБНОВЛЕНИЯ АКТИВОВ ПРОЦЕССОВ ОРГАНИЗАЦИИ Обновляемые активы процессов организации включают в себя, среди прочего, следующие: u u
управления проектом, документы о содержании, стоимости, расписании и календари проекта, а также документы по управлению изменениями. u u
обслуживания, эксплуатации и технической поддержки продукта или услуги, поставленных в результате проекта. Это могут быть новые документы или обновленные существующие документы. u u
документации, подтверждающей завершение проекта или фазы и передачу поставляемых результатов завершенного проекта или фазы другим сторонам, например в группу операционной деятельности или в следующую фазу. Во время закрытия проекта руководитель проекта проводит обзор документов предыдущей фазы, обзор документации по приемке заказчиком из процесса подтверждения содержания (раздел 5.5) и соглашения (если применимо), чтобы убедиться, что все требования проекта были выполнены до окончательного закрытия проекта. Если проект был прекращен до его завершения, то формальная документация содержит объяснения, почему проект был прекращен, и устанавливает процедуры передачи завершенных и незавершенных поставляемых результатов отмененного проекта другим сторонам. u u
передаются в репозиторий извлеченных уроков для использования в последующих проектах. 129 5 УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА Управление содержанием проекта включает в себя процессы, требуемые для обеспечения того, чтобы проект содержал все и только те работы, которые требуются для успешного выполнения проекта. Управление содержанием проекта непосредственно связано с определением и контролем того, что включено и что не включено в проект. Управление содержанием проекта включает в себя следующие процессы:
документирующего, каким образом содержание и продукта будет определяться, подтверждаться и контролироваться. 5.2 Сбор требований — процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. 5.3. Определение содержания — процесс разработки подробного описания проекта и продукта. 5.4 Создание иерархической структуры работ (ИСР) — процесс разделения поставляемых результатов проекта и работ проекта на меньшие компоненты, которыми легче управлять. 5.5 Подтверждение содержания — процесс формализованной приемки полученных поставляемых результатов проекта. 5.6 Контроль содержания — процесс мониторинга состояния содержания проекта и продукта, а также управления изменениями базового плана по содержанию. На рис. 5-1 представлена общая схема процессов управления содержанием проекта. Процессы управления содержанием проекта представляются в виде дискретных процессов с определенными границами, хотя на практике они накладываются и взаимодействуют такими способами, которые не могут быть в полной мере детализированы в Руководстве PMBOK®.
130 Часть 1 - Руководство .1 Входы .1 Устав проекта .2 План управления проектом .3 Факторы среды предприятия .4 Активы процессов организации .2 Инструменты и методы .1 Экспертная оценка .2 Анализ данных .3 Совещания .3 Выходы .1 План управления содержанием .2 План управления требованиями .1 Входы .1 Устав проекта .2 План управления проектом .3 Документы проекта .4 Бизнес-документы .5 Соглашения .6 Факторы среды предприятия .7 Активы процессов организации .2 Инструменты и методы .1 Экспертная оценка .2 Сбор данных .3 Анализ данных .4 Принятие решений .5 Отображение данных .6 Навыки межличностных отношений и работы с командой .7 Контекстная диаграмма .8 Прототипы .3 Выходы .1 Документация по требованиям .2 Матрица отслеживания требований .1 Входы .1 Устав проекта .2 План управления проектом .3 Документы проекта .4 Факторы среды предприятия .5 Активы процессов организации .2 Инструменты и методы .1 Экспертная оценка .2 Анализ данных .3 Принятие решений .4 Навыки межличностных отношений и работы с командой .5 Анализ продукта .3 Выходы .1 Описание содержания проекта .2 Обновления документов проекта .1 Входы .1 План управления проектом .2 Документы проекта .3 Факторы среды предприятия .4 Активы процессов организации .2 Инструменты и методы .1 Экспертная оценка .2 Декомпозиция .3 Выходы .1 Базовый план по содержанию .2 Обновления документов проекта .1 Входы .1 План управления проектом .2 Документы проекта .3 Проверенные поставляемые результаты .4 Данные об исполнении работ .2 Инструменты и методы .1 Инспекция .2 Принятие решений .3 Выходы .1 Принятые поставляемые результаты .2 Информация об исполнении работ .3 Запросы на изменения .4 Обновления документов проекта .1 Входы .1 План управления проектом .2 Документы проекта .3 Данные об исполнении работ .4 Активы процессов организации .2 Инструменты и методы .1 Анализ данных .3 Выходы .1 Информация об исполнении работ .2 Запросы на изменения .3 Обновления плана управления проектом .4 Обновления документов проекта Общая схема управления содержанием проекта 5.2 Сбор требований 5.1 Планирование управления содержанием 5.3 Определение содержания 5.4 Создание ИСР 5.5 Подтверждение содержания 5.6 Контроль содержания Рис. 5-1. Общая схема управления содержанием проекта 131 КЛЮЧЕВЫЕ КОНЦЕПЦИИ УПРАВЛЕНИЯ СОДЕРЖАНИЕМ ПРОЕКТА В контексте проекта термин «содержание» может обозначать: u u
u u
с заданными свойствами и функциями. Термин «содержание проекта» иногда включает в себя содержание продукта. Жизненные циклы проекта могут варьироваться в широком диапазоне от предиктивных подходов с одной стороны, и до адаптивного или гибкого подхода с другой. В предиктивном жизненном цикле поставляемые результаты проекта определяются в начале проекта, а управление всеми изменениями в содержании осуществляется последовательно в ходе осуществления проекта. В адаптивном или гибком (agile) жизненном цикле поставляемые результаты проходят разработку в ходе нескольких итераций, подробное содержание которых определяется и утверждается по отдельности в начале каждой их них. Проекты с адаптивными жизненными циклами предназначены для реагирования на высокий уровень изменений и требуют постоянной вовлеченности заинтересованных сторон. Общее содержание адаптивного проекта разбивается на набор требований, а работа, которая должна быть выполнена, иногда называется бэклогом продукта (журналом незавершенных работ продукта). В начале итерации команда определяет, сколько высокоприоритетных элементов из бэклога могут быть получены во время следующей итерации. Три процесса (сбор требований, определение содержания и создание ИСР) осуществляются для каждой итерации. С другой стороны, в предиктивном проекте указанные процессы исполняются перед началом проекта и обновляются по мере необходимости с использованием интегрированного процесса контроля изменений. В адаптивном или гибком жизненном цикле представители спонсора и заказчика должны быть постоянно вовлечены в проект для предоставления обратной связи о поставляемых результатах по мере их создания и обеспечения того, что бэклог (план незавершенных работ) отражает их текущие потребности. Два процесса (подтверждение содержания и контроль содержания) повторяются для каждой итерации. С другой стороны, в предиктивном проекте процесс подтверждения содержания осуществляется при поставке каждого поставляемого результата или рассмотрении результатов фазы, а процесс контроля содержания является непрерывным процессом. В предиктивных проектах базовым планом проекта по содержанию является одобренная версия описания содержания проекта, иерархическая структура работ (ИСР) и соответствующий словарь ИСР. Базовый план может быть изменен только с помощью формальных процедур контроля изменений и используется как база для сравнения при исполнении процессов подтверждения содержания и контроля содержания, а также других процессов контроля. В проектах с адаптивным жизненным циклом для отражения их текущих потребностей используются бэклоги (включая требования к продукту и спецификации пользователя). Реализация содержания проекта измеряется в сопоставлении с планом управления проектом, в то время как реализация содержания продукта измеряется в сопоставлении с требованиями к продукту. Понятие «требование» означает по определению условие или характеристику, которую должен, согласно требованиям, иметь продукт, услуга или результат, чтобы удовлетворить условия соглашения или другие официально установленные спецификации. Подтверждение содержания — процесс формализованной приемки полученных поставляемых результатов проекта. Проверенные поставляемые результаты, полученные по результатам процесса контроля качества, являются входом процесса подтверждения содержания. Одним из выходов процесса подтверждения содержания являются принятые поставляемые результаты, приемка которых официально оформлена и одобрена уполномоченной заинтересованной стороной. Соответственно, заинтересованной стороне нужно включиться в работу на ранних стадиях планирования (в некоторых случаях еще при инициации проекта) и предоставить пожелания в отношении качества поставляемых результатов так, чтобы контроль качества мог дать оценку исполнения и рекомендации необходимых изменений. 132 Часть 1 - Руководство ТЕНДЕНЦИИ И ВНОВЬ ВОЗНИКАЮЩИЕ ПРАКТИКИ В ОБЛАСТИ УПРАВЛЕНИЯ СОДЕРЖАНИЕМ ПРОЕКТА Требования всегда были предметом особого интереса при управлении проектом и продолжают привлекать все большее внимание специалистов. По мере того как глобальная среда приобретает все более сложный характер, организации начинают понимать, как следует использовать бизнес-анализ для получения конкурентных преимуществ за счет операций определения, управления и контроля требований. Мероприятия по бизнес-анализу могут быть начаты до инициации проекта и назначения руководителя проекта. В соответствии с документом Управление требованиями: практическое руководство (Requirements Management: A Practice Guide) [14], процесс управления требованиями начинается с оценки потребностей, к которой можно приступить в ходе планирования портфеля, планирования программы или в рамках организации отдельного проекта. Выяснение, документальное оформление и управление требованиями заинтересованных сторон проходит в рамках процессов управления содержанием проекта. Тенденции и вновь возникающие практики в области управления содержанием проекта отличаются, среди прочего, особым вниманием к сотрудничеству со специалистами в области бизнес-анализа с целью: u u определить проблемы и выяснить бизнес-потребности; u u определить и рекомендовать осуществимые решения по удовлетворению указанных потребностей; u u выяснить, документально оформить требования заинтересованных сторон и управлять ими для достижения целей бизнеса и проекта; u u
или проекта [7]. Данный процесс завершается полным удовлетворением требований, что означает передачу продукта, услуги или результата получателю для измерения, мониторинга, реализации и поддержания выгод с течением времени. Роль с ответственностью за проведение бизнес-анализа возлагается на ресурсы, обладающие достаточными навыками и экспертными знаниями в области бизнес-анализа. Если для участия в проекте назначен бизнес-аналитик, то относящиеся к требованиям операции входят в сферу ответственности этой роли. Ответственность за обеспечение учета относящейся к требованиям работы в плане управления проектом, а также своевременного исполнения относящихся к требованиям операций в пределах установленного бюджета и создание ценности несет руководитель проекта. Отношения между руководителем проекта и бизнес-аналитиком должны носить характер доверительного партнерства. Вероятность успешного завершения проекта будет выше при условии, что руководитель проекта и бизнес-аналитик полностью понимают роли и сферы ответственности друг друга в деле успешного достижения целей проекта.
133 СООБРАЖЕНИЯ ПО АДАПТАЦИИ Поскольку каждый проект является уникальным, руководителю проекта необходимо адаптировать порядок применения процессов управления содержанием проекта. Соображения в отношении адаптации включают в себя, среди прочего, следующее: u u
управления знаниями и требованиями? Какие инструкции должен дать руководитель проекта в области требований для последующего использования в будущем? u u
относящиеся к подтверждению и контролю политики, процедуры или инструкции? u u Подход к разработке. Использует ли организация гибкие подходы при управлении проектами? Является ли подход к разработке итеративным или инкрементным? Используется ли предиктивный подход? Будет ли продуктивным гибридный подход ? u u Стабильность требований. Имеются ли в проекте области с нестабильными требованиями? Возникает ли необходимость из-за нестабильности требований использовать упрощенные (lean), гибкие или другие адаптивные методы в период, пока требования не станут стабильными и не будут хорошо определены? u u Руководство. Имеются ли в организации формальные или неформальные политики, процедуры и руководящие принципы в области аудита и руководства? СООБРАЖЕНИЯ ДЛЯ ГИБКИХ/АДАПТИВНЫХ СРЕД В проектах с постоянно развивающимися требованиями, с высоким уровнем риска или большой степенью неопределенности во многих случаях на начальной стадии проекта его содержание остается неясным или развивается по мере осуществления. На ранней стадии проекта при использовании гибких методов на определение и согласование содержания целенаправленно выделяется меньше времени, чем на организацию процесса непрерывного раскрытия и уточнения требований. Во многих средах с вновь возникающими требованиями становится понятно, что между реальными бизнес- требованиями и бизнес-требованиями, которые были изначально заявлены, существует определенный разрыв. В этой связи при использовании гибких методов с целью уточнения требований целенаправленно создаются и анализируются прототипы и версии. В результате определение и уточнение содержания происходит на всем протяжении проекта. При применении гибких подходов требования формируют бэклог. 134 Часть 1 - Руководство 5.1 ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ СОДЕРЖАНИЕМ Планирование управления содержанием — процесс создания плана управления содержанием, документирующего, каким образом содержание проекта и продукта будет определяться, подтверждаться и контролироваться. Ключевая выгода данного процесса состоит в том, что он предоставляет руководство и указания относительно управления содержанием проекта на протяжении всего проекта. Этот процесс выполняется единожды или в предопределенные моменты в проекте. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5-2. На рис. 5-3 показана диаграмма потоков данных процесса.
.1 Экспертная оценка .2 Анализ данных • Анализ альтернатив .3 Совещания .1 Устав проекта .2 План управления проектом • План управления качеством • Описание жизненного цикла проекта
• Подход к разработке .3 Факторы среды предприятия .4 Активы процессов организации .1 План управления содержанием .2 План управления требованиями
Предприятие/ организация 4.1
Разработка устава проекта • План управления содержанием • План управления требованиями • Устав проекта • План управления качеством • Описание жизненного цикла проекта • Подход к разработке • Факторы среды предприятия • Активы процессов организации План
управления проектом
План управления проектом
135 План управления содержанием — компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и подтверждаться. Разработка плана управления содержанием и детализация содержания проекта начинается с анализа информации, содержащейся в уставе проекта (см. раздел 4.1.3.1), последних одобренных вспомогательных планов плана управления проектом (см. раздел 4.2.3.1), исторической информации, которая содержится в активах процессов организации (см. раздел 2.3) и других соответствующих факторов среды предприятия (см. раздел 2.2).
Описан в разделе 4.1.3.1. В уставе проекта документально оформляются цель проекта, высокоуровневое описание проекта, допущения, ограничения и высокоуровневые требования, которые данный проект призван удовлетворить.
Описан в разделе 4.2.3.1. Компоненты плана управления проектом включают в себя, среди прочего: u u
оказывает влияние то, как реализуются в ходе осуществления проекта политика, методологии и стандарты организации в области контроля качества. u u
с момента его начала до момента завершения. u u Подход к разработке. Подход к разработке определяет, какой тип подхода, а именно: водопадный, итеративный, адаптивный, гибкий или гибридный, — будет использоваться. 5.1.1.3 ФАКТОРЫ СРЕДЫ ПРЕДПРИЯТИЯ Факторы среды предприятия, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего: u u организационную культуру, u u инфраструктуру, u u управление персоналом, u u ситуацию на рынке. 136 Часть 1 - Руководство 5.1.1.4 АКТИВЫ ПРОЦЕССОВ ОРГАНИЗАЦИИ Активы процессов организации, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего: u u политики и процедуры, u u репозитории исторической информации и извлеченных уроков. 5.1.2 ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ СОДЕРЖАНИЕМ: ИНСТРУМЕНТЫ И МЕТОДЫ 5.1.2.1 ЭКСПЕРТНАЯ ОЦЕНКА Следует учитывать описанные в разделе 4.1.2.1 экспертные заключения, полученные от лиц или групп, обладающих специальными знаниями или подготовкой по следующим вопросам: u u предшествующие подобные проекты; u u информация об отрасли, дисциплине и прикладной области. 5.1.2.2 АНАЛИЗ ДАННЫХ В качестве метода анализа данных, который может использоваться в данном процессе, можно назвать анализ альтернатив. Производится оценка различных способов сбора требований, детальной разработки проекта и содержания проекта, создания продукта, подтверждения и контроля содержания. 5.1.2.3 СОВЕЩАНИЯ Команды проекта могут участвовать в совещаниях проекта по разработке плана управления проектом. Среди участников могут быть руководитель проекта, спонсор проекта, определенные участники команды проекта, определенные заинтересованные стороны, любые лица, отвечающие за те или иные процессы управления содержанием, и, при необходимости, другие лица.
137 5.1.3 ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ СОДЕРЖАНИЕМ: ВЫХОДЫ 5.1.3.1 ПЛАН УПРАВЛЕНИЯ СОДЕРЖАНИЕМ План управления содержанием — компонент плана управления проектом, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и подтверждаться. Компоненты плана управления содержанием включают в себя: u u
u u процесс, который позволяет создавать ИСР из подробного описания содержания проекта; u u процесс, который устанавливает порядок одобрения и ведения базового плана по содержанию; u u процесс, который устанавливает, как будет производиться формальная приемка полученных поставляемых результатов проекта. План управления содержанием может быть формальным и неформальным, детализированным или задавать лишь общие рамки в зависимости от потребностей проекта.
План управления требованиями — это компонент плана управления проектом, описывающий способы анализа, документирования требований по проекту и продукту и управления ими. Согласно документу Бизнес-анализ для
данный план называют еще «план бизнес-анализа». Компоненты плана управления требованиями могут включать в себя, среди прочего: u u порядок планирования, отслеживания и составления отчетов о действиях в отношении требований; u u действия по управлению конфигурацией, такие как порядок инициирования изменений, порядок анализа их воздействий, выявления, отслеживания и составления отчетов о них, а также уровни полномочий, необходимые для одобрения данных изменений; u u процесс приоритизации требований; u u используемые метрики и обоснование их использования; u u структуру отслеживания, которая отражает, какие параметры требований будут представлены в матрице отслеживания. |