Руководство к своду знаний по управлению проектами (Руководство pmbok) Пятое издание
 Скачать 11.68 Mb.
|
|
Большинство. Решение, которое принимается при поддержке более чем 50 % участников группы. Наличие в группе нечетного количества участников может обеспечить принятие решения и исключить ситуацию равного количества голосов. • Относительное большинство. Выбирается решение самого большого блока в группе, даже если не достигнуто большинство голосов. Данный метод обычно используется, когда предлагается более двух вариантов для выбора. • Диктатура. Данный метод предполагает, что одно лицо принимает решение за всю группу. 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 116 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание Все данные методы группового принятия решений можно применять в рамках методов группового творчества, которые используются в процессе сбора требований. 5.2.2.6 Анкеты и опросы Анкеты и опросы представляют собой письменные наборы вопросов, разработанные с целью быстрого сбора информации у большого числа респондентов. Опросы и/или анкеты лучше всего подходят для работы с различными по составу аудиториями, когда требуется быстрый сбор информации, когда респонденты территориально распределены и где допускается применение статистического анализа. 5.2.2.7 Наблюдения Наблюдения предоставляют непосредственный способ рассмотрения отдельных лиц в окружающей их обстановке, а также того, как они исполняют свои обязанности или задачи и выполняют процессы. Наблюдения особенно полезны для детализированных процессов, когда люди, пользующиеся продуктом, не могут или не желают отчетливо изложить свои требования. Наблюдение также известно как «рабочая тень» (job shadowing). Оно обычно осуществляется внешним наблюдателем, следящим за тем, как бизнес-эксперт выполняет свою работу. Также наблюдения могут осуществляться «наблюдателем-участником», который фактически исполняет процесс или процедуру, чтобы узнать, как они выполняются, и выявить скрытые требования. 5.2.2.8 Прототипы Прототипирование представляет собой метод получения предварительных отзывов относительно требований путем предоставления рабочей модели ожидаемого продукта, прежде чем создавать продукт в действительности. Поскольку прототипы реальны, это позволяет заинтересованным сторонам экспериментировать с моделью конечного продукта, а не ограничиваться обсуждением абстрактных представлений своих требований. Прототипы поддерживают концепцию последовательного уточнения в итеративных циклах создания экспериментальных моделей, проведения экспериментов пользователем, формирования отзывов и пересмотра прототипа. После проведения достаточного числа циклов обратной связи, требования, полученные с помощью прототипа, оказываются в достаточной мере полными для перехода к фазе проектирования или создания. Раскадровка (storyboarding) — это метод прототипирования, использующий последовательность или навигацию в рамках серии изображений или иллюстраций. Раскадровка используется в различных проектах во многих отраслях, например при создании фильмов, в рекламе, педагогическом проектировании, в проектах гибкой (agile) разработки и других проектах разработки программного обеспечения. При разработке программного обеспечения в раскадровке используются экспериментальные модели, чтобы продемонстрировать возможности навигации по веб-страницам, экранам или другим интерфейсам пользователей. 5.2.2.9 Бенчмаркинг Бенчмаркинг — это сравнение используемых или запланированных к использованию практик, таких как процессы и операции, с практиками сопоставимых организаций для выявления лучших практик, генерирования идей в отношении улучшений и предоставления основы для измерения эффективности и результативности. Во время бенчмаркинга возможно сравнение как внутренних, так и внешних организаций. 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 5 117 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание 5.2.2.10 Контекстные диаграммы Контекстные диаграммы являются примером модели содержания. Контекстные диаграммы визуально отображают содержание продукта, показывая бизнес-систему (процесс, оборудование, компьютерную систему и т. д.) и то, как люди и другие системы (действующие лица) взаимодействуют с ней. Контекстные диаграммы демонстрируют входы бизнес- системы, действующих лиц, обеспечивающих вход, выходы бизнес-системы и действующих лиц, получающих выход. 5.2.2.11 Анализ документов Анализ документов используется для выявления требований путем анализа существующей документации и идентификации информации, которая имеет отношение к требованиям. Существует множество документов, которые можно проанализировать для выявления надлежащих требований. Примеры документов, подлежащих анализу, включают в себя, среди прочего: бизнес-планы, маркетинговые материалы, соглашения, запросы предложений, действующий порядок процессов, логические модели данных, репозитории бизнес-правил, документацию по прикладному программному обеспечению, документацию по бизнес-процессам или интерфейсам, сценарии использования, другую документацию по требованиям, журналы проблем, политики, процедуры и нормативную документацию, такую как законы, кодексы или предписания и т. д. 5.2.3 Сбор требований: выходы 5.2.3.1 Документация по требованиям Документация по требованиям описывает, каким образом отдельные требования соответствуют бизнес-потребности в проекте. Требования могут быть сначала описаны высокоуровнево, а затем постепенно детализироваться по мере поступления новой информации о них. До включения в базовый план требования должны стать однозначными (измеримыми и проверяемыми), отслеживаемыми, полными, непротиворечивыми и приемлемыми для ключевых заинтересованных сторон. Формат документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинтересованным сторонам и приоритетам, до более тщательно проработанных форм, содержащих резюме для руководства, подробные описания и приложения. Компоненты документации по требованиям могут включать в себя, среди прочего: • Бизнес-требования, включая: ○ цели организации и проекта для возможности отслеживания; ○ бизнес-правила для исполняющей организации; ○ руководящие принципы организации. 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 118 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание • Требования заинтересованных сторон, включая: ○ воздействие на другие области организации; ○ воздействие на другие субъекты внутри или за пределами исполняющей организации; ○ требования к коммуникациям и отчетности для заинтересованных сторон. • Требования к решению, включая: ○ функциональные и нефункциональные требования; ○ требования соответствия технологиям и стандартам; ○ требования к поддержке и обучению; ○ требования к качеству; ○ требования к отчетности и т. д. (требования к решению могут быть документированы в виде текста, моделей или используя оба метода). • Требования к проекту, такие как: ○ уровни обслуживания, производительности, безопасности, соответствия и т. д.; ○ критерии приемки. • Требования к переходу. • Допущения, зависимости и ограничения в отношении требований. 5.2.3.2 Матрица отслеживания требований Матрица отслеживания требований — это таблица, связывающая требования к продукту, начиная от их создания и заканчивая предоставлением соответствующих им поставляемых результатов. Применение матрицы отслеживания требований помогает удостовериться, что каждое требование добавляет бизнес-ценность, связывая требование с целями организации и проекта. Это позволяет отслеживать требования на протяжении жизненного цикла проекта, что помогает удостовериться в том, что требования, одобренные в документации по требованиям, выполнены в конце проекта. Наконец, матрица отслеживания требований обеспечивает структуру для управления изменениями содержания продукта. Отслеживание включает в себя, среди прочего, отслеживание требований в следующих аспектах: 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 5 119 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание • бизнес-потребности, а также благоприятные возможности, цели и задачи организации; • цели проекта; • содержание проекта/поставляемые результаты ИСР; • проектирование продукта; • разработка продукта; • стратегия и сценарии тестирования; • детализация от высокоуровневых до более детальных требований. Параметры, связанные с каждым требованием, могут быть зафиксированы в матрице отслеживания требований. Данные параметры помогают определить ключевую информацию относительно требований. Типичные параметры, используемые в матрице отслеживания требований, могут включать в себя: уникальный идентификатор, текстовое описание требования, обоснование включения в список требований, владельца требования, источник, приоритет, версию, текущий статус (например, активно, отменено, отложено, добавлено, одобрено, назначено, выполнено) и дату статуса. Дополнительные параметры, позволяющие удостовериться, что требование удовлетворяет заинтересованные стороны проекта, могут включать в себя также стабильность, сложность и критерии приемки. На рис. 5-6 представлен пример матрицы отслеживания требований с включенными в нее параметрами требований. Матрица отслеживания требований Описание требований ID Бизнес-потребности, благоприятные возможности, цели и задачи организации Цели проекта Связанный ID Поставляемые результаты ИСР Проектирование продукта Разработка продукта Контрольные примеры Programs Portfolios Название проекта: Центр затрат: Описание проекта: 1.0 1.1 1.2 1.2.1 2.0 2.1 2.1.1 3.0 3.1 3.2 4.0 5.0 001 002 003 004 005 Рис. 5-6. Пример матрицы отслеживания требований 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 120 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание 5.3 Определение содержания Определение содержания — процесс разработки подробного описания проекта и продукта. Ключевая выгода данного процесса состоит в том, что он описывает границы продукта, услуги или результата путем определения того, какие из собранных требований будут включены в содержание проекта и какие исключены из него. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5-7. На рис. 5-8 показана диаграмма потоков данных процесса. Входы Инструменты и методы Выходы .1 План управления содержанием .2 Устав проекта .3 Документация по требованиям .4 Активы процессов организации .1 Экспертная оценка .2 Анализ продукта .3 Формирование альтернатив .4 Семинары с участием модератора .1 Описание содержания проекта .2 Обновления документов проекта Рис. 5-7. Определение содержания: входы, инструменты и методы, а также выходы Управление содержанием проекта 5.3 Определение содержания 5.1 П а а а а 5.2 С а 5.4 С а ИСР • Активы процессов организации • Устав проекта • Документация по требованиям • План управления содержанием • Описание содержания проекта • Обновления документов проекта 4.1 Ра а а а а а 6.3 О а а 6.5 О а а 6.6 Ра а а а а Д а П / а а Рис. 5-8. Диаграмма потоков данных определения содержания 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 5 121 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание Поскольку в проект невозможно включить все требования, выявленные в процессе сбора требований, в ходе процесса определения содержания из документации по требованиям, полученной в рамках процесса сбора требований, отбираются окончательные требования к проекту. Затем создается подробное описание проекта, а также продукта, услуги или результата. Подготовка подробного описания содержания проекта чрезвычайно важна для успеха проекта и основывается на основных поставляемых результатах, допущениях и ограничениях, документированных во время инициации проекта. Содержание проекта определяется во время планирования и описывается более подробно по мере поступления информации о проекте. Существующие риски, допущения и ограничения анализируются на предмет полноты и добавляются или актуализируются по мере необходимости. Процесс определения содержания может быть в высокой степени итеративным. В проектах с итеративным жизненным циклом высокоуровневое видение разрабатывается для всего проекта, но подробное содержание определяется последовательно в процессе каждой итерации, а детализированное планирование следующей итерации осуществляется по мере выполнения работ в отношении текущего содержания и поставляемых результатов проекта. 5.3.1 Определение содержания: входы 5.3.1.1 План управления содержанием Описан в разделе 5.1.3.1. План управления содержанием — это компонент плана управления проектом, задающий действия по разработке, мониторингу и контролю содержания проекта. 5.3.1.2 Устав проекта Описан в разделе 4.1.3.1. Устав проекта предоставляет высокоуровневое описание проекта и высокоуровневые характеристики продукта. Кроме того, он содержит требования к одобрению проекта. Если в исполняющей организации не применяется устав проекта, необходимо получить или подготовить аналогичную информацию, которую следует использовать в качестве основы для подробного описания содержания проекта. Организации, которые не разрабатывают формальный устав проекта, обычно проводят неформальный анализ для выявления информации, необходимой для дальнейшего планирования содержания. 5.3.1.3 Документация по требованиям Описана в разделе 5.2.3.1. Документация используется для отбора требований, которые будут включены в проект. 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 122 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание 5.3.1.4 Активы процессов организации Описаны в разделе 2.1.4. Активы процессов организации могут воздействовать на определение содержания. Примеры включают в себя, среди прочего: • политики, процедуры и шаблоны описания содержания проекта; • архивы предыдущих проектов; • извлеченные уроки из предыдущих фаз или проектов. 5.3.2 Определение содержания: инструменты и методы 5.3.2.1 Экспертная оценка Экспертная оценка часто используется для анализа информации, необходимой для разработки описания содержания проекта. Подобная оценка и экспертиза применяются в отношении любых технических деталей. Такая экспертиза предоставляется любым лицом или группой лиц, обладающими специальными знаниями или подготовкой, и доступна из множества источников, включающих в себя, среди прочего, следующие: • другие подразделения в рамках организации; • консультанты; • заинтересованные стороны, в том числе заказчики или спонсоры; • профессиональные и технические ассоциации; • промышленные группы; • эксперты по предметной области. 5.3.2.2 Анализ продукта Анализ продукта может стать результативным инструментом для проектов, поставляемым результатом которых является продукт, в отличие от услуги или результата. В каждой прикладной области существует один или несколько общепринятых методов перевода высокоуровневых описаний продукта в описание осязаемых поставляемых результатов. Анализ продукта включает в себя методы, такие как иерархическое разбиение продукта, системный анализ, анализ требований, системная инженерия, функционально-стоимостной анализ и анализ ценности. 5 – УПРАВЛЕНИЕ СОДЕРЖ АНИЕМ ПРОЕК ТА 5 123 ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание 5.3.2.3 Формирование альтернатив Формирование альтернатив — это метод, используемый для разработки как можно большего количества возможных вариантов для определения различных подходов к выполнению работ проекта. Может применяться множество методов общего менеджмента, таких как мозговой штурм, латеральное мышление, анализ альтернатив и т. д. 5.3.2.4 Семинары с участием модератора Описаны в разделе 5.2.2.3. Участие в данных интенсивных рабочих обсуждениях ключевых сторон с различными ожиданиями и/или специализирующихся в различных областях помогает достичь межфункционального и общего понимания целей и границ проекта. 5.3.3 Определение содержания: выходы 5.3.3.1 Описание содержания проекта Описание содержания проекта — это изложение содержания проекта, основных поставляемых результатов, допущений и ограничений. Описание содержания проекта документирует все содержание, включая содержание проекта и продукта. В нем детально описаны поставляемые результаты проекта и работы, которые необходимо выполнить для получения этих поставляемых результатов. Описание содержания проекта также формулирует общее понимание содержания проекта заинтересованными сторонами. Оно может содержать явные исключения из содержания, что может помочь в управлении ожиданиями заинтересованных сторон. Оно позволяет команде проекта осуществлять более детальное планирование, направляет работу команды проекта во время исполнения и предоставляет базовый план для оценки того, попадают ли запросы на изменения или дополнительная работа в границы проекта. Степень и уровень детализации, с которой описание содержания проекта определяет работу, которая будет выполнена, и работу, которая исключена, могут помочь определить, насколько хорошо команда управления проектом может контролировать содержание всего проекта. Подробное описание содержания проекта либо непосредственно, либо в виде ссылок на другие документы включает в себя: • |