Руководство к своду знаний по управлению проектами (Руководство pmbok) Пятое издание
 Скачать 11.68 Mb.
|
|
5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 108 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание План управления содержанием — компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться. Разработка плана управления содержанием и детализация содержания проекта начинается с анализа информации, содержащейся в уставе проекта (раздел 4.1.3.1), последних одобренных вспомогательных планов плана управления проектом (раздел 4.2.3.1), исторической информации, которая содержится в активах процессов организации (раздел 2.1.4) и других соответствующих факторов среды предприятия (раздел 2.1.5). Данный план помогает снизить риск расползания содержания проекта. 5.1.1 Планирование управления содержанием: входы 5.1.1.1 План управления проектом Описан в разделе 4.2.3.1. Одобренные вспомогательные планы плана управления проектом используются для создания плана управления содержанием и оказывают влияние на подход, применяемый для планирования содержания и управления содержанием проекта. 5.1.1.2 Устав проекта Описан в разделе 4.1.3.1. Устав проекта используется для предоставления контекста проекта, необходимого для планирования процессов управления содержанием. Он предоставляет высокоуровневое описание проекта и характеристики продукта из описания работ проекта. 5.1.1.3 Факторы среды предприятия Описаны в разделе 2.1.5. Факторы среды предприятия, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего: • организационную культуру, • инфраструктуру, • управление персоналом, • ситуацию на рынке. 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 5 109 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание 5.1.1.4 Активы процессов организации Описаны в разделе 2.1.4. Активы процессов организации, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего: • политики и процедуры, • историческую информацию и базу накопленных знаний. 5.1.2 Планирование управления содержанием: инструменты и методы 5.1.2.1 Экспертная оценка Экспертная оценка — это суждение, полученное от знающих и опытных сторон. Экспертное заключение могут давать как группы, так и отдельные лица, имеющие специальное образование, знания, навыки, опыт или подготовку в области разработки планов управления содержанием. 5.1.2.2 Совещания Команды проекта могут участвовать в совещаниях проекта по разработке плана управления проектом. Среди участников таких совещаний могут быть руководитель проекта, спонсор проекта, определенные участники команды проекта, определенные заинтересованные стороны, любые лица, отвечающие за какие-либо процессы управления содержанием, и, при необходимости, другие лица. 5.1.3 Планирование управления содержанием: выходы 5.1.3.1 План управления содержанием План управления содержанием — компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться. План управления содержанием — это основной вход процесса разработки плана управления проектом и остальных процессов управления содержанием. Компоненты плана управления содержанием включают в себя: 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 110 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание • процесс подготовки подробного описания содержания проекта; • процесс, который позволяет создавать ИСР из подробного описания содержания проекта; • процесс, который определяет, как ИСР будет поддерживаться и одобряться; • процесс, который устанавливает, как будет производиться формальная приемка полученных поставляемых результатов проекта; • процесс контроля обработки запросов на изменения в отношении подробного описания содержания проекта. Этот процесс напрямую связан с процессом интегрированного контроля изменений (раздел 4.5). План управления содержанием может быть формальным и неформальным, детализированным или задавать лишь общие рамки в зависимости от потребностей проекта. 5.1.3.2 План управления требованиями План управления требованиями — это компонент плана управления проектом, описывающий способы анализа, документирования требований и управления ими. Взаимосвязи между фазами, описанные в разделе 2.4.2.1, существенно влияют на порядок управления требованиями. Руководитель проекта выбирает наиболее эффективный тип взаимосвязей для проекта и документирует данный подход в плане управления требованиями. Многие компоненты плана управления требованиями основаны на этом типе взаимосвязей. Компоненты плана управления требованиями могут включать в себя, среди прочего: • порядок планирования, отслеживания и составления отчетов о действиях в отношении требований; • действия по управлению конфигурацией, такие как порядок инициирования изменений продукта, порядок анализа воздействий, их выявления, отслеживания и составления отчетов о них, а также уровни полномочий, необходимые для одобрения данных изменений; • процесс приоритезации требований; • используемые метрики продукта и обоснование их использования; • структуру отслеживания, т. е. какие параметры требований будут отражены в матрице отслеживания. 5.2 Сбор требований Сбор требований — процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения и управления содержанием проекта, включая содержание продукта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5-4. На рис. 5-5 показана диаграмма потоков данных процесса. 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 5 111 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание Входы Инструменты и методы Выходы .1 План управления содержанием .2 План управления требованиями .3 План управления заинтересованными сторонами .4 Устав проекта .5 Реестр заинтересованных сторон .1 Интервью .2 Фокус-группы .3 Семинары с участием модератора .4 Методы группового творчества .5 Методы группового принятия решений .6 Анкеты и опросы .7 Наблюдения .8 Прототипы .9 Бенчмаркинг .10 Контекстные диаграммы .11 Анализ документов .1 Документация по требованиям .2 Матрица отслеживания требований Рис. 5-4. Сбор требований: входы, инструменты и методы, а также выходы • Change log Управление содержанием проекта 5.2 Сбор требований 5.1 П а а а а 5.3 О а 5.4 С а ИСР 5.5 П а 5.6 К а • Устав проекта • Реестр заинтересованных сторон • План управления заинтересованными сторонами • Документация по требованиям • План управления требованиями • План управления содержанием • Матрица отслеживания требований 13.1 О а а 13.2 П а а а а а а 8.1 П а а а а 12.1 П а а а а а 4.1 Ра а а а а а Рис. 5-5. Диаграмма потоков данных сбора требований 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 112 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание На успех проекта напрямую влияет активная вовлеченность заинтересованных сторон в выявление и декомпозицию потребностей в требования, а также тщательность определения, документирования и управления требованиями к продукту, услуге или результату проекта. Требования включают в себя условия или возможности, которым должен соответствовать проект или которые должен иметь продукт, услуга или результат, чтобы удовлетворить соглашению или другой формальной предписанной спецификации. Требования включают в себя количественно определенные и документированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон. Данные требования должны быть выявлены, проанализированы и зарегистрированы со степенью детализации, достаточной для того, чтобы их включить в базовый план по содержанию и измерять после начала исполнения проекта. Требования становятся базой для ИСР. Планирование стоимости, расписания, качества и иногда закупок основывается на данных требованиях. Разработка требований начинается с анализа информации, содержащейся в уставе проекта (раздел 4.1.3.1), в реестре заинтересованных сторон (раздел 13.1.3.1) и в плане управления заинтересованными сторонами (раздел 13.2.3.1). Многие организации подразделяют требования на различные типы, например бизнес-решения и технические решения, причем первые относятся к потребностям заинтересованных сторон, а последние — к способу реализации этих потребностей. Требования могут быть сгруппированы в классы, что обеспечивает их дальнейшее уточнение и детализацию в процессе их выработки. Данные классы включают в себя: • Бизнес-требования, описывающие высокоуровневые потребности организации в целом, например проблемы или благоприятные возможности организации, а также причины, по которым проект был предпринят. • Требования заинтересованных сторон, описывающие потребности заинтересованной стороны или группы заинтересованных сторон. • Требования к решению, описывающие свойства, функции и характеристики продукта, услуги или результата, который удовлетворит бизнес-требованиям и требованиям заинтересованных сторон. Требования к решению, в свою очередь, группируются в функциональные и нефункциональные требования: ○ Функциональные требования описывают поведение продукта. Примеры включают в себя процессы, данные и взаимодействия с продуктом. ○ Нефункциональные требования дополняют функциональные и описывают условия или качества среды, необходимые для обеспечения эффективности продукта. Примеры включают в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уничтожению и т. д. • Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в состояние «как должно быть» в будущем. • Требования к проекту описывают действия, процессы или другие условия, которым должен соответствовать проект. • Требования к качеству, включающие в себя любое состояние или критерий, необходимые для подтверждения успешного получения поставляемого результата проекта или выполнения других требований к проекту. 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 5 113 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание 5.2.1 Сбор требований: входы 5.2.1.1 План управления содержанием Описан в разделе 5.1.3.1. План управления содержанием разъясняет то, как команда проекта будет определять, какой тип требований необходимо собрать для проекта. 5.2.1.2 План управления требованиями Описан в разделе 5.1.3.2. План управления требованиями задает процессы, используемые в рамках процесса сбора требований для определения и документирования потребностей заинтересованных сторон. 5.2.1.3 План управления заинтересованными сторонами Описан в разделе 13.2.3.1. План управления заинтересованными сторонами используется для понимания требований заинтересованных сторон к коммуникациям и уровня их вовлечения с целью оценки и адаптации к уровню участия заинтересованных сторон в действиях в отношении требований. 5.2.1.4 Устав проекта Описан в разделе 4.1.3.1. Устав проекта используется для предоставления высокоуровнего описания продукта, услуги или результата, позволяющего разработать детальные требования. 5.2.1.5 Реестр заинтересованных сторон Описан в разделе 13.1.3.1. Реестр заинтересованных сторон используется для определения заинтересованных сторон, которые могут предоставить информацию о требованиях. Реестр заинтересованных сторон также включает в себя важнейшие требования и основные ожидания заинтересованных сторон, которые они могут иметь в отношении проекта. 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 114 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание 5.2.2 Сбор требований: инструменты и методы 5.2.2.1 Интервью Интервью представляют собой формальный или неформальный подход, используемый для получения информации у заинтересованных сторон путем прямого разговора с ними. Обычно в ходе интервью задают подготовленные и непосредственно возникающие вопросы и записывают ответы. Интервью часто проводятся на индивидуальной основе между интервьюером и интервьюируемым, но иногда в них могут участвовать несколько интервьюеров и/или интервьюируемых. Проведение интервью с опытными участниками проекта, спонсорами и другими представителями руководства, а также экспертами по предметной области может помочь в выявлении и определении характеристик и функций желаемых продуктов (поставляемых результатов). Интервью также помогают в получении конфиденциальной информации. 5.2.2.2 Фокус-группы Фокус-группы позволяют собрать вместе заранее выбранных заинтересованных сторон и экспертов по предметной области, чтобы узнать их ожидания и отношения к предложенному продукту, услуге или результату. Подготовленный модератор направляет интерактивное обсуждение группы, построенное так, чтобы оно было более разговорным, чем индивидуальное интервью. 5.2.2.3 Семинары с участием модератора Семинары с участием модератора (facilitated workshops) представляют собой сфокусированные обсуждения, объединяющие ключевые заинтересованные стороны с целью определения требований к продукту. Семинары используются в качестве основного метода, позволяющего быстро определить межфункциональные требования и урегулировать различия между требованиями заинтересованных сторон. В силу особенностей формата групповой работы, хорошо скоординированные обсуждения помогают развить доверие, выстроить отношения и наладить общение между участниками, что может привести к повышению уровня согласия между заинтересованными сторонами. Кроме этого, проблемы могут быть обнаружены и решены быстрее, чем при индивидуальных обсуждениях. Например, в области разработки программного обеспечения используются семинары с участием модератора под названием «Совместная разработка/проектирование приложений» (joint application development/design, JAD). Данные обсуждения с участием модератора сконцентрированы на том, чтобы собрать вместе бизнес-экспертов по предметной области и команду разработчиков для улучшения процесса разработки программного продукта. В производственных отраслях существует «Развертывание функций качества» (quality function deployment, QFD) — это еще один пример семинара с участием модератора, который помогает определить критически важные характеристики для разработки нового продукта. QFD начинается со сбора потребностей заказчика, что также называется «мнением заказчика» (voice of the customer, VOC). Затем данные потребности объективно сортируются и приоритезируются, а также устанавливаются цели для их достижения. Во время семинаров по требованиям зачастую разрабатываются пользовательские истории — краткие текстовые описания требуемой функциональности. Пользовательские истории описывают заинтересованную сторону, которая получает пользу от свойства продукта (роль), что заинтересованной стороне необходимо достичь (цель) и пользу для заинтересованной стороны (мотивацию). Пользовательские истории широко используются в рамках гибких (agile) методов. 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 5 115 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание 5.2.2.4 Методы группового творчества Для выявления требований к проекту и продукту могут организовываться различные групповые мероприятия. Ниже представлены некоторые из методов группового творчества: • Мозговой штурм. Метод, применяемый для генерации и сбора разнообразных идей, связанных с требованиями к проекту и продукту. Хотя сам по себе мозговой штурм не включает голосование или приоритезацию, его часто используют с другими методами группового творчества, которые предусматривают данные процессы. • Метод номинальных групп. Метод, расширяющий мозговой штурм путем процесса голосования, используемого для ранжирования наиболее полезных идей для последующего мозгового штурма или приоритезации. • Построение ассоциативных карт. Метод, в котором идеи, возникшие во время отдельных сессий мозгового штурма, объединяются в одну карту с целью отражения общности и различий в понимании и для генерирования новых идей. • Диаграмма сходства. Метод, позволяющий классифицировать большое количество идей по группам с целью обзора и анализа. • Анализ решений на основе множества критериев. Метод, использующий матрицу решений для обеспечения систематического аналитического подхода к установлению критериев, таких как уровни рисков, неопределенность и определение ценности, для оценивания и ранжирования многочисленных идей. 5.2.2.5 Методы группового принятия решения Метод группового принятия решений — это процесс оценки различных альтернатив с ожидаемым результатом в форме будущих действий. Данные методы могут быть использованы для создания, классификации и приоритезации требований к продукту. Существуют различные методы принятия группового решения, например: • Единогласие. Принятие решения посредством согласия каждого с единым курсом действий. Один из способов достижения единогласия — это метод Дельфи, при котором группа выбранных экспертов отвечает на вопросы анкет, а также высказывает мнение относительно ответов, полученных в течение каждого раунда сбора требований. Для обеспечения анонимности доступ к ответам имеет только модератор. • |