Пм бук. Руководство pmbok ОлимпБизнес
Скачать 4.06 Mb.
|
5.1.1 Планирование управления содержанием: входы 5.1.1.1 Устав проекта Описан в разделе 4.1.3.1. В уставе проекта документально оформляются цель проекта, высокоуровневое описание проекта, допущения, ограничения и высокоуровневые требования, которые данный проект призван удовлетворить. 5.1.1.2 План управления проектом Описан в разделе 4.2.3.1. Компоненты плана управления проектом включают в себя, среди прочего: ♦ План управления качеством. Описан в разделе 8.1.3.1. На порядок управления содержанием проекта и продукта оказывает влияние то, как реализуются в ходе осуществления проекта политика, методологии и стандарты организации в области контроля качества. ♦ Описание жизненного цикла проекта. Жизненный цикл проекта – это ряд фаз, через которые проходит проект с момента его начала до момента завершения. ♦ Подход к разработке. Подход к разработке определяет, какой тип подхода, а именно: водопадный, итеративный, адаптивный, гибкий или гибридный, – будет использоваться. . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 123 5.1.1.3 Факторы среды предприятия Факторы среды предприятия, которые могут оказывать влияние на процесс планирова- ния управления содержанием, включают в себя, среди прочего: ♦ организационную культуру, ♦ инфраструктуру, ♦ управление персоналом, ♦ ситуацию на рынке. 5.1.1.4 Активы процессов организации Активы процессов организации, которые могут оказывать влияние на процесс планиро- вания управления содержанием, включают в себя, среди прочего: ♦ политики и процедуры, ♦ репозитории исторической информации и извлеченных уроков. 5.1.2 Планирование управления содержанием: инструменты и методы 5.1.2.1 Экспертная оценка Следует учитывать описанные в разделе 4.1.2.1 экспертные заключения, полученные от лиц или групп, обладающих специальными знаниями или подготовкой по следующим вопро- сам: ♦ предшествующие подобные проекты; ♦ информация об отрасли, дисциплине и прикладной области. 5.1.2.2 Анализ данных В качестве метода анализа данных, который может использоваться в данном процессе, можно назвать анализ альтернатив. Производится оценка различных способов сбора требова- ний, детальной разработки проекта и содержания проекта, создания продукта, подтверждения и контроля содержания. 5.1.2.3 Совещания Команды проекта могут участвовать в совещаниях проекта по разработке плана управ- ления проектом. Среди участников могут быть руководитель проекта, спонсор проекта, опре- деленные участники команды проекта, определенные заинтересованные стороны, любые лица, отвечающие за те или иные процессы управления содержанием, и, при необходимости, другие лица. 5.1.3 Планирование управления содержанием: выходы 5.1.3.1 План управления содержанием План управления содержанием – компонент плана управления проектом, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролиро- ваться и подтверждаться. Компоненты плана управления содержанием включают в себя: ♦ процесс подготовки описания содержания проекта; . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 124 ♦ процесс, который позволяет создавать ИСР из подробного описания содержания про- екта; ♦ процесс, который устанавливает порядок одобрения и ведения базового плана по содержанию; ♦ процесс, который устанавливает, как будет производиться формальная приемка полу- ченных поставляемых результатов проекта. План управления содержанием может быть формальным и неформальным, детализиро- ванным или задавать лишь общие рамки в зависимости от потребностей проекта. 5.1.3.2 План управления требованиями План управления требованиями – это компонент плана управления проектом, описыва- ющий способы анализа, документирования требований по проекту и продукту и управления ими. Согласно документу Бизнес-анализ для специалистов-практиков: Практическое руковод- ство (Analysis for Practitioners: A Practice Guide) [7], в некоторых организациях данный план называют еще «план бизнес-анализа». Компоненты плана управления требованиями могут включать в себя, среди прочего: ♦ порядок планирования, отслеживания и составления отчетов о действиях в отношении требований; ♦ действия по управлению конфигурацией, такие как порядок инициирования измене- ний, порядок анализа их воздействий, выявления, отслеживания и составления отчетов о них, а также уровни полномочий, необходимые для одобрения данных изменений; ♦ процесс приоритизации требований; ♦ используемые метрики и обоснование их использования; ♦ структуру отслеживания, которая отражает, какие параметры требований будут пред- ставлены в матрице отслеживания. 5.2 Сбор требований Сбор требований – это процесс определения, документирования и управления потреб- ностями и требованиями заинтересованных сторон для достижения поставленных целей. Клю- чевая выгода данного процесса состоит в том, что он предоставляет основу для определения содержания продукта и проекта. Этот процесс выполняется единожды или в предопределенные моменты в проекте. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–4. На рис. 5–5 показана диаграмма потоков данных процесса. . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 125 Рис. 5–4. Сбор требований: входы, инструменты и методы, выходы . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 126 Рис. 5–5. Сбор требований: диаграмма потоков данных В Руководстве PMBOK® вопросы требований к продукту подробно не освещаются, поскольку эти требования разные в разных отраслях. Обратите внимание, что в документе Биз- нес-анализ для специалистов-практиков: Практическое руководство (Analysis for Practitioners: Practice Guide) [7] можно найти более подробную информацию по требованиям к продукту. На успех проекта напрямую влияет активная вовлеченность заинтересованных сторон в выявле- ние и декомпозицию потребностей в требования к проекту и продукту, а также тщательность определения, документирования и управления требованиями к продукту, услуге или резуль- тату проекта. Требования включают в себя условия или характеристики, которые должен, согласно требованиям, иметь продукт, услуга или результат, чтобы удовлетворить условиям соглашения или другим официально установленным спецификациям. Требования включают в себя количественно определенные и документированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон. Данные требования должны быть выявлены, проанализированы и записаны со степенью детализации, достаточной для их включения в базо- . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 127 вый план по содержанию и измерения после начала исполнения проекта. Требования стано- вятся базой для ИСР. Планирование стоимости, расписания, качества и закупок основывается на данных требованиях. 5.2.1 Сбор требований: входы 5.2.1.1 Устав проекта Описан в разделе 4.1.3.1. В уставе проекта документируется высокоуровневое описание проекта и высокоуровневые требования, которые затем используются при детализации требо- ваний. 5.2.1.2 План управления проектом Описан в разделе 4.2.3.1. Компоненты плана управления проектом включают в себя, среди прочего: ♦ План управления содержанием. Описан в разделе 5.1.3.1. План управления содер- жанием содержит информацию о порядке определения и разработки содержания проекта. ♦ План управления требованиями. Описан в разделе 5.1.3.2. План управления тре- бованиями содержит информацию о порядке сбора, анализа и документального оформления требований по проекту. ♦ План вовлечения заинтересованных сторон. Описан в разделе 13.2.3.1. План вовлечения заинтересованных сторон используется для понимания требований заинтересован- ных сторон к коммуникациям и уровня их вовлеченности с целью оценки и адаптации к уровню участия заинтересованных сторон в действиях в отношении требований. 5.2.1.3 Документы проекта В качестве примеров документов проекта, которые можно считать входами в данный про- цесс, можно назвать, среди прочего: ♦ Журнал допущений. Описан в разделе 4.1.3.2. В журнале допущений определены допущения в отношении продукта, проекта, среды, заинтересованных сторон и других факто- ров, которые влияют на требования. ♦ Реестр извлеченных уроков. Описан в разделе 4.4.3.1. Реестр извлеченных уроков используется для предоставления информации об результативных методах сбора требований, особенно для проектов, в которых применяется итеративная или адаптивная методология раз- работки продукта. ♦ Реестр заинтересованных сторон. Описан в разделе 13.1.3.1. Реестр заинтересо- ванных сторон используется для определения заинтересованных сторон, которые могут предо- ставить информацию о требованиях. В нем также регистрируются требования и ожидания, которые есть у заинтересованных сторон по данному проекту. 5.2.1.4 Бизнес-документы Описаны в разделе 1.2.6. Документом, который может оказать влияние на процесс сбора требований, является бизнес-кейс, который может содержать описание обязательных, жела- тельных и необязательных критериев для удовлетворения бизнес-потребностей. . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 128 5.2.1.5 Соглашения Описаны в разделе 12.2.3.2. Соглашения могут предусматривать требования к проекту и продукту. 5.2.1.6 Факторы среды предприятия Факторы среды предприятия, которые могут оказывать влияние на процесс сбора инфор- мации, включают в себя, среди прочего: ♦ организационную культуру, ♦ инфраструктуру, ♦ управление персоналом, ♦ ситуацию на рынке. 5.2.1.7 Активы процессов организации Активы процессов организации, которые могут оказывать влияние на процесс сбора тре- бований, включают в себя, среди прочего: ♦ политики и процедуры, ♦ репозиторий исторической информации и извлеченных уроков, содержащий инфор- мацию о прошлых проектах. 5.2.2 Сбор требований: инструменты и методы 5.2.2.1 Экспертная оценка Описана в разделе 4.1.2.1. Следует учитывать экспертные заключения, полученные от лиц или групп, обладающих специальными знаниями или подготовкой по следующим вопро- сам: ♦ бизнес-анализ, ♦ выяснение требований, ♦ анализ требований, ♦ документация по требованиям, ♦ требования к проекту в прошлых подобных проектах, ♦ методы диаграмм, ♦ фасилитация, ♦ управление конфликтами. 5.2.2.2 Сбор данных В качестве методов сбора данных, которые могут использоваться в данном процессе, можно назвать, среди прочего, следующие: ♦ Мозговой штурм. Описан в разделе 4.1.2.2. Мозговой штурм – это метод, применяе- мый для генерации и сбора различных идей, связанных с требованиями к проекту и продукту. ♦ Интервью. Интервью представляет собой формальный или неформальный подход, используемый для получения информации у заинтересованных сторон путем прямого разго- вора с ними. Обычно в ходе интервью задают подготовленные и непосредственно возникаю- щие вопросы и записывают ответы. Интервью часто проводятся на индивидуальной основе между интервьюером и интервьюируемым, но иногда в них могут участвовать несколько интер- вьюеров и/или интервьюируемых. Проведение интервью с опытными участниками проекта, . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 129 спонсорами и другими представителями руководства, а также экспертами по предметной обла- сти может помочь в выявлении и определении характеристик и функций желаемых продук- тов (поставляемых результатов). Интервью также помогают в получении конфиденциальной информации. ♦ Фокус-группы. Фокус-группы позволяют собрать вместе заранее выбранных заинте- ресованных сторон и экспертов по предметной области, чтобы узнать их ожидания и отноше- ния к предложенному продукту, услуге или результату. Подготовленный модератор направляет интерактивное обсуждение в группе, построенное так, чтобы оно было более разговорным, чем индивидуальное интервью. ♦ Анкеты и опросы. Анкеты и опросы представляют собой письменные наборы вопро- сов, разработанные с целью быстрого сбора информации у большого числа респондентов. Опросы и/или анкеты лучше всего подходят для работы с различными по составу аудиториями в ситуациях, когда требуется быстрый сбор информации, когда респонденты территориально распределены и когда статистический анализ мог бы быть целесообразным. ♦ Бенчмаркинг. Описан в разделе 8.1.2.2. Бенчмаркинг – это сравнение фактических или запланированных продуктов, процессов и практик, с продуктами, процессами и практи- ками сопоставимых организаций для выявления лучших практик, генерирования идей в отно- шении улучшений и предоставления основы для измерения эффективности и результативно- сти. Во время бенчмаркинга возможно сравнение как внутренних, так и внешних организаций. 5.2.2.3 Анализ данных Описан в разделе 4.5.2.2. Методы анализа данных, которые можно использовать в дан- ном процессе, включают, среди прочего, анализ документов. Анализ документов состоит в рассмотрении и оценке всей относящейся к делу документированной информации. В данном процессе анализ документов используется для выявления требований путем анализа суще- ствующей документации и выявления информации, которая имеет отношение к требованиям. Существует множество документов, которые можно проанализировать для выявления надле- жащих требований. В качестве примеров документов, которые могут быть предметом анализа, можно привести, среди прочего, следующие: ♦ соглашения, ♦ бизнес-планы, ♦ документация по бизнес-процессам и интерфейсам, ♦ репозитории бизнес-правил, ♦ текущие блок-схемы процессов, ♦ маркетинговая литература, ♦ журналы проблем/трудностей, ♦ политики и процедуры, ♦ нормативно-правовые документы, такие как законы, кодексы, постановления и т. п., ♦ запросы на предложения, ♦ сценарии использования. 5.2.2.4 Принятие решений Методы принятия решений, которые можно использовать в процессе сбора требований, включают в себя, среди прочего, следующие: ♦ Голосование. Голосование – это метод принятия коллективных решений и процесс оценки различных альтернатив с ожидаемым результатом в форме будущих действий. Данные методы могут быть использованы для создания, классификации и приоритизации требований к продукту. Примеры методов голосования включают: . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 130 • Единогласие. Принятие решения посредством согласия каждого с единым курсом дей- ствий. • Большинство. Решение, которое принимается при поддержке более чем 50 % участни- ков группы. Наличие в группе нечетного количества участников может обеспечить принятие решения и исключить ситуацию равного количества голосов. • Относительное большинство. Выбирается решение самого большого блока в группе, даже если не достигнуто большинство голосов. Данный метод обычно используется, когда предлагается более двух вариантов для выбора. ♦ Единоличное принятие решений. Данный метод предполагает, что одно лицо при- нимает на себя ответственность за решение, обязательное для целой группы. ♦ Анализ решений на основе множества критериев. Метод, который использует матрицу решений для обеспечения систематического аналитического подхода к установлению критериев, таких как уровни рисков, неопределенность и определение ценности для оценива- ния и ранжирования многочисленных идей. 5.2.2.5 Отображение данных Методы отображения данных, которые можно использовать в данном процессе, вклю- чают, среди прочего, следующие: ♦ Диаграммы сходства. Диаграммы сходства позволяют классифицировать большое количество идей по группам с целью обзора и анализа. ♦ Построение ассоциативных карт. Построение ассоциативных карт позволяет кон- солидировать идеи, возникшие во время отдельных мозговых штурмов, в одной карте с целью отражения общности и различий в понимании и для генерирования новых идей. 5.2.2.6 Навыки межличностных отношений и работы с командой Описаны в разделе 4.1.2.3. Навыки межличностных отношений и работы с командой, которые можно использовать в данном процессе, включают в себя, среди прочего, следующие: ♦ Метод номинальных групп. Метод номинальных групп расширяет возможности мозгового штурма путем процесса голосования, используемого для ранжирования наиболее полезных идей для последующего мозгового штурма или приоритизации. Метод номиналь- ных групп – это структурированная форма мозгового штурма, включающая в себя следующие шаги: • постановка вопроса или проблемы перед группой; каждый человек молча обдумывает и записывает свои соображения; • модератор выписывает идеи на лекционном плакате, пока не будут занесены все идеи; • каждая выписанная идея обсуждается, пока у всех членов группы не сложится четкое понимание обсуждаемой идеи; • участники закрытым голосованием определяют приоритетность идей, как правило с оценкой от 1 до 5 баллов, где 1 означает самый низкий приоритет, а 5 – самый высокий. Голосо- вание может проводиться в несколько этапов с целью сокращения количества идей и сосредо- точения внимания на наиболее важных из них. По окончании каждого этапа результаты голо- сования подсчитываются и выбираются получившие наивысшую оценку идеи. ♦ Наблюдение/обсуждение. Наблюдение и обсуждение дают возможность непосред- ственно следить за отдельными лицами в окружающей их обстановке, а также за тем, как они исполняют свои обязанности или решают задачи и выполняют процессы. Наблюдения осо- бенно полезны для детализированных процессов, когда люди, пользующиеся продуктом, не могут или не желают отчетливо изложить свои требования. Наблюдение также известно как «рабочая тень» (job shadowing). Оно обычно осуществляется внешним наблюдателем, следя- . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 131 щим за тем, как бизнес-эксперт выполняет свою работу. Также наблюдения могут осуществ- ляться «наблюдателем-участником», который фактически исполняет процесс или процедуру, чтобы узнать, как они выполняются, и выявить скрытые требования. ♦ |