Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство
Шрифт:
Выяснение, документальное оформление и управление требованиями заинтересованных сторон проходит в рамках процессов управления содержанием проекта. Тенденции и вновь возникающие практики в области управления содержанием проекта отличаются, среди прочего, особым вниманием к сотрудничеству со специалистами в области бизнес-анализа с целью:
определить проблемы и выяснить бизнес-потребности;
определить и рекомендовать осуществимые решения по удовлетворению указанных потребностей;
выяснить, документально оформить требования заинтересованных сторон и управлять ими для достижения целей бизнеса и проекта;
создать необходимые условия для успешного производства
Данный процесс завершается полным удовлетворением требований, что означает передачу продукта, услуги или результата получателю для измерения, мониторинга, реализации и поддержания выгод с течением времени.
Роль с ответственностью за проведение бизнес-анализа возлагается на ресурсы, обладающие достаточными навыками и экспертными знаниями в области бизнес-анализа. Если для участия в проекте назначен бизнес-аналитик, то относящиеся к требованиям операции входят в сферу ответственности этой роли. Ответственность за обеспечение учета относящейся к требованиям работы в плане управления проектом, а также своевременного исполнения относящихся к требованиям операций в пределах установленного бюджета и создание ценности несет руководитель проекта.
Отношения между руководителем проекта и бизнес-аналитиком должны носить характер доверительного партнерства. Вероятность успешного завершения проекта будет выше при условии, что руководитель проекта и бизнес-аналитик полностью понимают роли и сферы ответственности друг друга в деле успешного достижения целей проекта.
Поскольку каждый проект является уникальным, руководителю проекта необходимо адаптировать порядок применения процессов управления содержанием проекта. Соображения в отношении адаптации включают в себя, среди прочего, следующее:
Управление знаниями и требованиями. Имеются ли в организации формальные или неформальные системы управления знаниями и требованиями? Какие инструкции должен дать руководитель проекта в области требований для последующего использования в будущем?
Подтверждение и контроль. Имеются ли в организации действующие формальные или неформальные относящиеся к подтверждению и контролю политики, процедуры или инструкции?
Подход к разработке. Использует ли организация гибкие подходы при управлении проектами? Является ли подход к разработке итеративным или инкрементным? Используется ли предиктивный подход? Будет ли продуктивным гибридный подход?
Стабильность требований. Имеются ли в проекте области с нестабильными требованиями? Возникает ли необходимость из-за нестабильности требований использовать упрощенные (lean), гибкие или другие адаптивные методы в период, пока требования не станут стабильными и не будут хорошо определены?
Руководство. Имеются ли в организации формальные или неформальные политики, процедуры и руководящие принципы в области аудита и руководства?
В проектах с постоянно развивающимися требованиями, с высоким уровнем риска или большой степенью неопределенности во многих случаях на начальной стадии проекта его содержание остается неясным или развивается по мере осуществления. На ранней стадии проекта при использовании гибких методов на определение и согласование содержания целенаправленно выделяется меньше времени, чем на организацию процесса непрерывного раскрытия и уточнения требований. Во многих средах с вновь возникающими требованиями становится понятно, что между реальными бизнес-требованиями и бизнес-требованиями, которые были изначально заявлены, существует определенный разрыв. В этой связи при использовании гибких методов с целью уточнения требований целенаправленно создаются и анализируются прототипы и версии. В результате определение и уточнение содержания происходит на всем протяжении проекта. При применении гибких подходов требования формируют бэклог.
5.1. Планирование управления содержанием
Планирование управления содержанием – процесс создания плана управления содержанием, документирующего, каким образом содержание проекта и продукта будет определяться, подтверждаться и контролироваться. Ключевая выгода данного процесса состоит в том, что он предоставляет руководство и указания относительно управления содержанием проекта на протяжении всего проекта. Этот процесс выполняется единожды или в предопределенные моменты в проекте. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–2. На рис. 5–3 показана диаграмма потоков данных процесса.
Рис. 5–2. Планирование управления содержанием: входы, инструменты и методы, выходы
Рис. 5–3. Планирование управления содержанием: диаграмма потоков данных
План управления содержанием – компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и подтверждаться. Разработка плана управления содержанием и детализация содержания проекта начинается с анализа информации, содержащейся в уставе проекта (см. раздел 4.1.3.1), последних одобренных вспомогательных планов плана управления проектом (см. раздел 4.2.3.1), исторической информации, которая содержится в активах процессов организации (см. раздел 2.3) и других соответствующих факторов среды предприятия (см. раздел 2.2).
5.1.1. Планирование управления содержанием: входы
5.1.1.1. Устав проекта
Описан в разделе 4.1.3.1. В уставе проекта документально оформляются цель проекта, высокоуровневое описание проекта, допущения, ограничения и высокоуровневые требования, которые данный проект призван удовлетворить.
5.1.1.2. План управления проектом
Описан в разделе 4.2.3.1. Компоненты плана управления проектом включают в себя, среди прочего:
План управления качеством. Описан в разделе 8.1.3.1. На порядок управления содержанием проекта и продукта оказывает влияние то, как реализуются в ходе осуществления проекта политика, методологии и стандарты организации в области контроля качества.
Описание жизненного цикла проекта. Жизненный цикл проекта – это ряд фаз, через которые проходит проект с момента его начала до момента завершения.
Подход к разработке. Подход к разработке определяет, какой тип подхода, а именно: водопадный, итеративный, адаптивный, гибкий или гибридный, – будет использоваться.