Телефон: +1 800-888-4741
Факс: +1 312-337-5985
Эл. почта: [email protected] (только для заказов)
По всем остальным вопросам обращайтесь в PMI Book Service Center.
PMI Book Service Center
P.O. Box 932683, Atlanta, GA 31193-2683 USA
Телефон: 1-866-276-4764 (в США или Канаде) или +1-770-280-4129 (по всему миру)
Эл. почта: [email protected]
Напечатано в Соединенных Штатах Америки Запрещается воспроизведение или передача в любой форме или любыми средствами, электронными, ручными, путем фотокопирования, записи или с помощью любой системы хранения и извлечения информации любой части данного издания без предварительного разрешения издателя.
PMI, логотип PMI, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION и девиз MAKING PROJECT MANAGEMENT INDISPENSABLE FOR BUSINESS RESULTS. являются товарными знаками Project Management Institute, Inc. Для получения полного списка товарных знаков PMI обратитесь в юридический отдел PMI. Все остальные товарные марки, знаки обслуживания, торговые наименования, торговое оформление, названия продуктов и логотипы, появляющиеся в данном документе, являются собственностью их соответствующих владельцев. Любые права, не переданные в явной форме в настоящем документе, принадлежат владельцу авторского права.
Все права защищены. Воспроизведение всей книги или ее части в любом виде воспрещается без письменного разрешения издателя.
Руководство к Своду знаний по управлению проектами (Руководство PMBOK)
Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах.
PMI не несет ответственность за какие-либо травмы, повреждения, нанесенные собственности, или какие-либо другие убытки, будь то реальные, косвенные или компенсаторные, произошедшие непосредственно или косвенно вследствие издания, применения или использования данного документа. PMI не несет ответственность и не предоставляет гарантию, прямую или предполагаемую, относительно точности или полноты любого материала, содержащегося в данном документе, а также не несет ответственность и не предоставляет гарантию того, что содержащаяся в данном документе информация отвечает каким-либо вашим целям или нуждам. PMI не предоставляет гарантию относительно качества каких-либо продуктов или услуг отдельного производителя или продавца, проистекающего из использования данного стандарта или руководства.
Издавая и распространяя данный документ, PMI не оказывает профессиональные или иные услуги какому-либо лицу или организации или от имени какого-либо лица или организации; также PMI не выполняет обязательства какого-либо лица или организации по отношению к какой-либо третьей стороне. При использовании данного документа использующее его лицо должно самостоятельно определять действия, необходимые в конкретных обстоятельствах, полагаясь при этом исключительно на свое суждение или, при необходимости, на совет компетентного профессионала. Информация относительно темы, освещаемой данным документом, или относящиеся этой теме стандарты могут быть получены из других источников, к которым пользователь может при необходимости обратиться, чтобы получить дополнительную информацию, не содержащуюся в данном документе.
PMI не имеет полномочий и не берет на себя обязательства по контролю за соответствием существующих практик содержанию данного документа или приведению этих практик в соответствие с данным документом. PMI не занимается сертификацией, проведением контрольных испытаний или инспекций в отношении продуктов, проектов или конструкций на предмет безопасности их эксплуатации или безопасности для здоровья потребителей. Любой сертификат или иное утверждение соответствия какой-либо информации относительно безопасности эксплуатации или безопасности для здоровья, содержащейся в данном документе, не могут быть приписаны PMI; в таком случае ответственность лежит всецело на лице, выдавшем сертификат или высказавшем такое утверждение.
Часть 1. Руководство к Своду Знаний по Управлению Проектом (Руководство PMBOK®)
1.1. Обзор и назначение настоящего руководства
Управление проектами не является чем-то новым. Люди пользуются им на протяжении многих веков. Среди примеров осуществленных проектов можно назвать:
Источник: readli.net
Новости
В конце 2014 года Институт управления проектами (PMI) опубликовал Business Analysis for Practitioners: A Practice Guide (Бизнес-анализ для практиков: Практическое руководство). Сейчас данное издание можно скачать бесплатно. Business Analysis for Practitioners: A Practice Guide дает рекомендации по проведению бизнес-анализа на всем жизненном цикле проекта (программы), предоставляя руководство по оценке потребностей и планированию бизнес-анализа, по выявлению требований к продукту проекта (программы), по их отслеживанию и мониторингу, а также по оценке полученного в итоге решения. Business Analysis for Practitioners: A Practice Guide синхронизирован по терминологии с пятым изданием Руководства PMBOK, однако предоставляет с одной стороны более подробные разъяснения и примеры по представленным методам, а с другой стороны представляет целостную логику выполнения работ для бизнес-аналитиков.
Роль бизнес-аналитика далеко не всегда выполняется отдельным специалистом, поэтому данная публикация будет интересна и руководителям проектов, и архитекторам, и иным членам команды проекта (программы), в чьи обязанности входит организация и проведение работ по бизнес-анализу, необходимых для определения требований к продукту проекта (программы) и мониторинга выполнения данных требований.
Отмечу, что публикацией такой категории документов, как Практические руководства (а также Расширения к Руководству PMBOK и Практические стандарты), Институт управления проектами (PMI) значительно упростил практикам жизнь, все более и более раскрывая связь общих положений Руководства PMBOK со спецификой управления проектами для различных отраслей и различных ролей в проекте.
Скачать Business Analysis for Practitioners: A Practice Guide (на английском языке) можно на сайте pmi.org.
Источник: project2project.ru
Текст книги «Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство»
Описан в разделе 4.1.3.1. В уставе проекта документально оформляются цель проекта, высокоуровневое описание проекта, допущения, ограничения и высокоуровневые требования, которые данный проект призван удовлетворить.
5.1.1.2. План управления проектом
Описан в разделе 4.2.3.1. Компоненты плана управления проектом включают в себя, среди прочего:
♦ Описание жизненного цикла проекта. Жизненный цикл проекта – это ряд фаз, через которые проходит проект с момента его начала до момента завершения.
♦ Подход к разработке. Подход к разработке определяет, какой тип подхода, а именно: водопадный, итеративный, адаптивный, гибкий или гибридный, – будет использоваться.
5.1.1.3. Факторы среды предприятия
♦ ситуацию на рынке.
5.1.1.4. Активы процессов организации
♦ политики и процедуры,
♦ репозитории исторической информации и извлеченных уроков.
Следует учитывать описанные в разделе 4.1.2.1 экспертные заключения, полученные от лиц или групп, обладающих специальными знаниями или подготовкой по следующим вопросам:
♦ предшествующие подобные проекты;
♦ информация об отрасли, дисциплине и прикладной области.
5.1.2.2. Анализ данных
В качестве метода анализа данных, который может использоваться в данном процессе, можно назвать анализ альтернатив. Производится оценка различных способов сбора требований, детальной разработки проекта и содержания проекта, создания продукта, подтверждения и контроля содержания.
♦ процесс подготовки описания содержания проекта;
♦ процесс, который позволяет создавать ИСР из подробного описания содержания проекта;
♦ процесс, который устанавливает порядок одобрения и ведения базового плана по содержанию;
♦ процесс, который устанавливает, как будет производиться формальная приемка полученных поставляемых результатов проекта.
5.1.3.2. План управления требованиями
План управления требованиями – это компонент плана управления проектом, описывающий способы анализа, документирования требований по проекту и продукту и управления ими. Согласно документу Бизнес-анализ для специалистов-практиков: Практическое руководство (Analysis for Practitioners: A Practice Guide) [7], в некоторых организациях данный план называют еще «план бизнес-анализа». Компоненты плана управления требованиями могут включать в себя, среди прочего:
♦ порядок планирования, отслеживания и составления отчетов о действиях в отношении требований;
♦ действия по управлению конфигурацией, такие как порядок инициирования изменений, порядок анализа их воздействий, выявления, отслеживания и составления отчетов о них, а также уровни полномочий, необходимые для одобрения данных изменений;
♦ процесс приоритизации требований;
♦ используемые метрики и обоснование их использования;
♦ структуру отслеживания, которая отражает, какие параметры требований будут представлены в матрице отслеживания.
5.2. Сбор требований
Сбор требований – это процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения поставленных целей. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения содержания продукта и проекта. Этот процесс выполняется единожды или в предопределенные моменты в проекте.
Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–4. На рис. 5–5 показана диаграмма потоков данных процесса.
Рис. 5–4. Сбор требований: входы, инструменты и методы, выходы
Рис. 5–5. Сбор требований: диаграмма потоков данных
В Руководстве PMBOK® вопросы требований к продукту подробно не освещаются, поскольку эти требования разные в разных отраслях. Обратите внимание, что в документе Бизнес-анализ для специалистов-практиков: Практическое руководство (Analysis for Practitioners: Practice Guide) [7] можно найти более подробную информацию по требованиям к продукту.
На успех проекта напрямую влияет активная вовлеченность заинтересованных сторон в выявление и декомпозицию потребностей в требования к проекту и продукту, а также тщательность определения, документирования и управления требованиями к продукту, услуге или результату проекта. Требования включают в себя условия или характеристики, которые должен, согласно требованиям, иметь продукт, услуга или результат, чтобы удовлетворить условиям соглашения или другим официально установленным спецификациям.
Требования включают в себя количественно определенные и документированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон. Данные требования должны быть выявлены, проанализированы и записаны со степенью детализации, достаточной для их включения в базовый план по содержанию и измерения после начала исполнения проекта. Требования становятся базой для ИСР. Планирование стоимости, расписания, качества и закупок основывается на данных требованиях.
5.2.1. Сбор требований: входы 5.2.1.1. Устав проекта
Описан в разделе 4.1.3.1. В уставе проекта документируется высокоуровневое описание проекта и высокоуровневые требования, которые затем используются при детализации требований.
5.2.1.2. План управления проектом
Описан в разделе 4.2.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. Реестр заинтересованных сторон используется для определения заинтересованных сторон, которые могут предоставить информацию о требованиях. В нем также регистрируются требования и ожидания, которые есть у заинтересованных сторон по данному проекту.
Описаны в разделе 1.2.6. Документом, который может оказать влияние на процесс сбора требований, является бизнес-кейс, который может содержать описание обязательных, желательных и необязательных критериев для удовлетворения бизнес-потребностей.
Описаны в разделе 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. Мозговой штурм – это метод, применяемый для генерации и сбора различных идей, связанных с требованиями к проекту и продукту.
♦ Интервью. Интервью представляет собой формальный или неформальный подход, используемый для получения информации у заинтересованных сторон путем прямого разговора с ними. Обычно в ходе интервью задают подготовленные и непосредственно возникающие вопросы и записывают ответы.
Интервью часто проводятся на индивидуальной основе между интервьюером и интервьюируемым, но иногда в них могут участвовать несколько интервьюеров и/или интервьюируемых. Проведение интервью с опытными участниками проекта, спонсорами и другими представителями руководства, а также экспертами по предметной области может помочь в выявлении и определении характеристик и функций желаемых продуктов (поставляемых результатов). Интервью также помогают в получении конфиденциальной информации.
♦ Фокус-группы. Фокус-группы позволяют собрать вместе заранее выбранных заинтересованных сторон и экспертов по предметной области, чтобы узнать их ожидания и отношения к предложенному продукту, услуге или результату. Подготовленный модератор направляет интерактивное обсуждение в группе, построенное так, чтобы оно было более разговорным, чем индивидуальное интервью.
♦ Анкеты и опросы. Анкеты и опросы представляют собой письменные наборы вопросов, разработанные с целью быстрого сбора информации у большого числа респондентов. Опросы и/или анкеты лучше всего подходят для работы с различными по составу аудиториями в ситуациях, когда требуется быстрый сбор информации, когда респонденты территориально распределены и когда статистический анализ мог бы быть целесообразным.
♦ Бенчмаркинг. Описан в разделе 8.1.2.2. Бенчмаркинг – это сравнение фактических или запланированных продуктов, процессов и практик, с продуктами, процессами и практиками сопоставимых организаций для выявления лучших практик, генерирования идей в отношении улучшений и предоставления основы для измерения эффективности и результативности. Во время бенчмаркинга возможно сравнение как внутренних, так и внешних организаций.
5.2.2.3. Анализ данных
Описан в разделе 4.5.2.2. Методы анализа данных, которые можно использовать в данном процессе, включают, среди прочего, анализ документов. Анализ документов состоит в рассмотрении и оценке всей относящейся к делу документированной информации. В данном процессе анализ документов используется для выявления требований путем анализа существующей документации и выявления информации, которая имеет отношение к требованиям. Существует множество документов, которые можно проанализировать для выявления надлежащих требований. В качестве примеров документов, которые могут быть предметом анализа, можно привести, среди прочего, следующие:
♦ документация по бизнес-процессам и интерфейсам,
♦ текущие блок-схемы процессов,
♦ политики и процедуры,
♦ нормативно-правовые документы, такие как законы, кодексы, постановления и т. п.,
♦ запросы на предложения,
5.2.2.4. Принятие решений
Методы принятия решений, которые можно использовать в процессе сбора требований, включают в себя, среди прочего, следующие:
♦ Голосование. Голосование – это метод принятия коллективных решений и процесс оценки различных альтернатив с ожидаемым результатом в форме будущих действий. Данные методы могут быть использованы для создания, классификации и приоритизации требований к продукту. Примеры методов голосования включают:
• Единогласие. Принятие решения посредством согласия каждого с единым курсом действий.
• Большинство. Решение, которое принимается при поддержке более чем 50 % участников группы. Наличие в группе нечетного количества участников может обеспечить принятие решения и исключить ситуацию равного количества голосов.
• Относительное большинство. Выбирается решение самого большого блока в группе, даже если не достигнуто большинство голосов. Данный метод обычно используется, когда предлагается более двух вариантов для выбора.
♦ Единоличное принятие решений. Данный метод предполагает, что одно лицо принимает на себя ответственность за решение, обязательное для целой группы.
♦ Анализ решений на основе множества критериев. Метод, который использует матрицу решений для обеспечения систематического аналитического подхода к установлению критериев, таких как уровни рисков, неопределенность и определение ценности для оценивания и ранжирования многочисленных идей.
5.2.2.5. Отображение данных
Методы отображения данных, которые можно использовать в данном процессе, включают, среди прочего, следующие:
♦ Диаграммы сходства. Диаграммы сходства позволяют классифицировать большое количество идей по группам с целью обзора и анализа.
♦ Построение ассоциативных карт. Построение ассоциативных карт позволяет консолидировать идеи, возникшие во время отдельных мозговых штурмов, в одной карте с целью отражения общности и различий в понимании и для генерирования новых идей.
5.2.2.6. Навыки межличностных отношений и работы с командой
Описаны в разделе 4.1.2.3. Навыки межличностных отношений и работы с командой, которые можно использовать в данном процессе, включают в себя, среди прочего, следующие:
♦ Метод номинальных групп. Метод номинальных групп расширяет возможности мозгового штурма путем процесса голосования, используемого для ранжирования наиболее полезных идей для последующего мозгового штурма или приоритизации. Метод номинальных групп – это структурированная форма мозгового штурма, включающая в себя следующие шаги:
• постановка вопроса или проблемы перед группой; каждый человек молча обдумывает и записывает свои соображения;
• модератор выписывает идеи на лекционном плакате, пока не будут занесены все идеи;
• каждая выписанная идея обсуждается, пока у всех членов группы не сложится четкое понимание обсуждаемой идеи;
• участники закрытым голосованием определяют приоритетность идей, как правило с оценкой от 1 до 5 баллов, где 1 означает самый низкий приоритет, а 5 – самый высокий. Голосование может проводиться в несколько этапов с целью сокращения количества идей и сосредоточения внимания на наиболее важных из них. По окончании каждого этапа результаты голосования подсчитываются и выбираются получившие наивысшую оценку идеи.
♦ Наблюдение/обсуждение. Наблюдение и обсуждение дают возможность непосредственно следить за отдельными лицами в окружающей их обстановке, а также за тем, как они исполняют свои обязанности или решают задачи и выполняют процессы.
Наблюдения особенно полезны для детализированных процессов, когда люди, пользующиеся продуктом, не могут или не желают отчетливо изложить свои требования. Наблюдение также известно как «рабочая тень» (job shadowing). Оно обычно осуществляется внешним наблюдателем, следящим за тем, как бизнес-эксперт выполняет свою работу. Также наблюдения могут осуществляться «наблюдателем-участником», который фактически исполняет процесс или процедуру, чтобы узнать, как они выполняются, и выявить скрытые требования.
♦ Фасилитация. Описана в разделе 4.1.2.3. Фасилитация используется при обсуждениях на заданную тему, объединяющих ключевые заинтересованные стороны с целью определения требований к продукту. Такие семинары могут использоваться с целью быстро определить межфункциональные требования и согласовать различия между требованиями заинтересованных сторон.
В силу особенностей формата групповой работы, хорошо скоординированные сессии с участием модератора помогают развить доверие, выстроить отношения и наладить общение между участниками, что может привести к повышению уровня согласия между заинтересованными сторонами. Кроме этого, проблемы могут быть обнаружены и решены быстрее, чем при индивидуальных обсуждениях.
Навыки в области фасилитации используются, среди прочего, в следующих ситуациях:
• Совместное проектирование/разработка приложений (Joint application design/development, JAD). Сессии по JAD проводятся в отрасли разработки программного обеспечения. Данные сессии с участием модератора сконцентрированы на том, чтобы собрать вместе профильных бизнес-экспертов и команду разработчиков для сбора требований и улучшения процесса разработки программного продукта.
• Развертывание функции качества (Quality function deployment, QFD). В производственных отраслях QFD – это еще один метод фасилитации, который помогает определить критически важные характеристики для разработки нового продукта. QFD начинается со сбора потребностей заказчика, что также называется «мнением заказчика» (voice of the customer, VOC). Затем данные потребности объективно сортируются и приоритизируются, а также устанавливаются цели для их достижения.
• Пользовательские истории. Во время семинаров по требованиям зачастую разрабатываются пользовательские истории – краткие текстовые описания требуемой функциональности. Пользовательские истории описывают роль заинтересованной стороны, получающей пользу от свойства продукта (роль), которую заинтересованной стороне необходимо достичь (цель) и пользу для заинтересованной стороны (мотивация).
Источник: iknigi.net