Пм бук. Руководство pmbok ОлимпБизнес
 Скачать 4.06 Mb.
|
|
Фасилитация. Описана в разделе 4.1.2.3. Фасилитация используется при обсужде- ниях на заданную тему, объединяющих ключевые заинтересованные стороны с целью опре- деления требований к продукту. Такие семинары могут использоваться с целью быстро определить межфункциональные требования и согласовать различия между требованиями заинтересованных сторон. В силу особенностей формата групповой работы, хорошо скоор- динированные сессии с участием модератора помогают развить доверие, выстроить отноше- ния и наладить общение между участниками, что может привести к повышению уровня согла- сия между заинтересованными сторонами. Кроме этого, проблемы могут быть обнаружены и решены быстрее, чем при индивидуальных обсуждениях. Навыки в области фасилитации используются, среди прочего, в следующих ситуациях: • Совместное проектирование/разработка приложений (Joint application design/ development, JAD) . Сессии по JAD проводятся в отрасли разработки программного обеспече- ния. Данные сессии с участием модератора сконцентрированы на том, чтобы собрать вместе профильных бизнес-экспертов и команду разработчиков для сбора требований и улучшения процесса разработки программного продукта. • Развертывание функции качества (Quality function deployment, QFD). В производствен- ных отраслях QFD – это еще один метод фасилитации, который помогает определить кри- тически важные характеристики для разработки нового продукта. QFD начинается со сбора потребностей заказчика, что также называется «мнением заказчика» (voice of the customer, VOC). Затем данные потребности объективно сортируются и приоритизируются, а также уста- навливаются цели для их достижения. • Пользовательские истории. Во время семинаров по требованиям зачастую разраба- тываются пользовательские истории – краткие текстовые описания требуемой функциональ- ности. Пользовательские истории описывают роль заинтересованной стороны, получающей пользу от свойства продукта (роль), которую заинтересованной стороне необходимо достичь (цель) и пользу для заинтересованной стороны (мотивация). 5.2.2.7 Контекстные диаграммы Контекстные диаграммы являются примером модели содержания. Контекстные диа- граммы визуально отображают содержание продукта, показывая бизнес-систему (процесс, обо- рудование, компьютерную систему и т. д.) и то, как люди и другие системы (действующие лица) взаимодействуют с ней (см. рис. 5–6). Контекстные диаграммы демонстрируют входы бизнес-системы, действующих лиц, обеспечивающих вход, выходы бизнес-системы и действу- ющих лиц, получающих выход. . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 132 Рис. 5–6. Контекстные диаграммы. 5.2.2.8 Прототипы Прототипирование представляет собой метод получения предварительных отзывов отно- сительно требований путем предоставления модели ожидаемого продукта, прежде чем созда- вать продукт в действительности. Примерами прототипов являются продукты небольшого размера, модели, выполненные с помощью компьютерной двух- или трехмерной графики, макеты или имитации. Прототипы позволяют заинтересованным сторонам экспериментиро- вать с моделью конечного продукта, а не ограничиваться обсуждением абстрактных представ- лений своих требований. Прототипы поддерживают концепцию последовательного уточнения в итеративных циклах создания макетов, проведения экспериментов пользователем, формиро- вания отзывов и пересмотра прототипа. После проведения достаточного числа циклов обрат- ной связи требования, полученные с помощью прототипа, оказываются в достаточной мере полными для перехода к фазе проектирования или создания. Раскадровка (storyboarding) – это метод прототипирования, использующий последова- тельность или навигацию в рамках серии изображений или иллюстраций. Раскадровка исполь- зуется в различных проектах во многих отраслях, например, при создании фильмов, в рекламе, педагогическом проектировании, в проектах гибкой разработки и других проектах разработки программного обеспечения. При разработке программного обеспечения в раскадровке исполь- зуются макеты, чтобы продемонстрировать возможности навигации по веб-страницам, экра- нам или другим интерфейсам пользователей. . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 133 5.2.3 Сбор требований: выходы 5.2.3.1 Документация по требованиям Документация по требованиям описывает, каким образом отдельные требования соот- ветствуют бизнес-потребности в проекте. Требования могут быть сначала описаны высоко- уровнево, а затем постепенно детализироваться по мере поступления новой информации о них. До включения в базовый план требования должны стать однозначными (измеримыми и проверяемыми), отслеживаемыми, полными, непротиворечивыми и приемлемыми для клю- чевых заинтересованных сторон. Формат документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинте- ресованным сторонам и приоритетам, до более тщательно проработанных форм, содержащих резюме для руководства, подробные описания и приложения. Многие организации подразделяют требования на различные типы, например, биз- нес-решения и технические решения, причем первые относятся к потребностям заинтересо- ванных сторон, а последние – к способу реализации этих потребностей. Требования могут быть сгруппированы в классы, что обеспечивает их дальнейшее уточнение и детализацию в процессе их выработки. Данные классы включают в себя: ♦ Бизнес-требования. Бизнес-требования описывают высокоуровневые потребности организации в целом, например, проблемы или благоприятные возможности организации, а также причины, по которым проект был инициирован. ♦ Требования заинтересованных сторон . Требования заинтересованных сторон опи- сывают потребности заинтересованной стороны или группы заинтересованных сторон. ♦ Требования к решению. Требования к решению описывают свойства, функции и характеристики продукта, услуги или результата, который удовлетворяет бизнес-требованиям и требованиям заинтересованных сторон. Требования к решению, в свою очередь, группиру- ются в функциональные и нефункциональные требования: • Функциональные требования. Функциональные требования описывают поведение про- дукта. Примеры включают в себя операции, процессы, данные и взаимодействия, которые дол- жен исполнять продукт. • Нефункциональные требования. Нефункциональные требования дополняют функцио- нальные и описывают условия или качества среды, необходимые для обеспечения эффектив- ности продукта. Примеры включают в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уни- чтожению и т. д. ♦ Требования на переходный период и по обеспечению готовности . Требования к переходу описывают временные возможности, такие как требования к преобразованию дан- ных и обучению, необходимые для перехода из текущего состояния «как есть» в желаемое состояние в будущем. ♦ Требования к проекту. Требования к проекту описывают действия, процессы или другие условия, которым должен соответствовать проект. В качестве примеров можно назвать даты контрольных событий, договорные обязательства, ограничения и т. п. ♦ Требования к качеству. Требования к качеству, включающие в себя любое состо- яние или критерии, необходимые для подтверждения успешного получения поставляемого результата проекта или выполнения других требований к проекту. В качестве примеров можно назвать тестирование, сертификацию, подтверждения и т. п. . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 134 5.2.3.2 Матрица отслеживания требований Матрица отслеживания требований – это таблица, связывающая требования к продукту, начиная от их создания и заканчивая предоставлением соответствующих им поставляемых результатов. Применение матрицы отслеживания требований помогает удостовериться, что каждое требование добавляет бизнес-ценность, связывая требование с целями организации и проекта. Это позволяет отслеживать требования на протяжении жизненного цикла проекта, что помогает удостовериться в том, что требования, одобренные в документации по требова- ниям, выполнены в конце проекта. Наконец, матрица отслеживания требований обеспечивает структуру для управления изменениями содержания продукта. Требования к отслеживанию включают в себя, среди прочего: ♦ бизнес-потребности, а также благоприятные возможности, цели и задачи организации; ♦ цели проекта; ♦ содержание проекта и поставляемые результаты ИСР; ♦ проектирование продукта; ♦ разработку продукта; ♦ стратегию и сценарии тестирования; ♦ детализацию от высокоуровневых до более детальных требований. Параметры, связанные с каждым требованием, могут быть зафиксированы в матрице отслеживания требований. Данные параметры помогают определить ключевую информацию относительно требований. Типичные параметры, используемые в матрице отслеживания тре- бований, могут включать в себя: уникальный идентификатор, текстовое описание требова- ния, обоснование включения в список требований, владельца требования, источник, приори- тет, версию, текущий статус (например, активно, отменено, отложено, добавлено, одобрено, назначено, выполнено) и дату статуса. Дополнительные параметры, позволяющие удостове- риться, что требование удовлетворяет заинтересованные стороны проекта, могут включать в себя также стабильность, сложность и критерии приемки. На рис. 5–7 представлен пример мат- рицы отслеживания требований с включенными в нее параметрами требований. Рис. 5–7. Пример матрицы отслеживания требований . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 135 5.3 Определение содержания Определение содержания – процесс разработки подробного описания проекта и про- дукта. Ключевая выгода данного процесса состоит в том, что он позволяет описать границы и критерии приемки продукта, услуги или результата. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–8. На рис. 5–9 показана диаграмма потоков данных процесса. Рис. 5–8. Определение содержания: входы, инструменты и методы, выходы Рис. 5–9. Определение содержания: диаграмма потоков данных . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 136 Поскольку в проект невозможно включить все требования, выявленные в процессе сбора требований, окончательные требования к проекту выбираются в ходе процесса определения содержания из документации по требованиям, разработанной в рамках процесса сбора требо- ваний. Затем создается подробное описание проекта, а также продукта, услуги или результата. Подготовка подробного описания содержания проекта основывается на главных постав- ляемых результатах, допущениях и ограничениях, документированных во время инициации проекта. Содержание проекта определяется во время планирования и описывается более подробно по мере поступления информации о проекте. Существующие риски, допущения и ограничения анализируются на предмет полноты и добавляются или актуализируются по мере необходимости. Процесс определения содержания может быть в высокой степени итератив- ным. В проектах с итеративным жизненным циклом высокоуровневое видение разрабатыва- ется для всего проекта, но подробное содержание определяется последовательно в процессе каждой итерации, а детализированное планирование следующей итерации осуществляется по мере выполнения работ в отношении текущего содержания и поставляемых результатов про- екта. 5.3.1 Определение содержания: входы 5.3.1.1 Устав проекта Описан в разделе 4.1.3.1. Устав проекта предоставляет высокоуровневое описание про- екта и высокоуровневые характеристики продукта, а также требования к одобрению. 5.3.1.2 План управления проектом Описан в разделе 4.2.3.1. Компонент плана управления проектом включает в себя, среди прочего, план управления содержанием, как описано в разделе 5.1.3.1, который документирует порядок определения, подтверждения и контроля содержания проекта. 5.3.1.3 Документы проекта В качестве примеров документов проекта, которые можно считать входами в данный про- цесс, можно назвать, среди прочего: ♦ Журнал допущений. Описан в разделе 4.1.3.2. В журнале допущений определяются допущения и ограничения в отношении продукта, проекта, среды, заинтересованных сторон и других факторов, которые могут повлиять на проект и содержание продукта. ♦ Документацию по требованиям. Описана в разделе 5.2.3.1. Документация по тре- бованиям определяет требования, которые будут включены в состав содержания. ♦ Реестр рисков. Описан в разделе 11.2.3.1. Реестр рисков содержит стратегии реаги- рования, которые могут влиять на содержание проекта, например, сокращение или изменение содержания проекта и продукта, чтобы уклониться от риска или снизить риск. 5.3.1.4 Факторы среды предприятия Факторы среды предприятия, которые могут оказывать влияние на процесс определения содержания, включают в себя, среди прочего: ♦ организационную культуру, ♦ инфраструктуру, ♦ управление персоналом, ♦ ситуацию на рынке. . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 137 5.3.1.5 Активы процессов организации Активы процессов организации, которые могут оказывать влияние на процесс определе- ния содержания, включают в себя, среди прочего: ♦ политики, процедуры и шаблоны описания содержания проекта; ♦ архивы предыдущих проектов; ♦ извлеченные уроки из предыдущих фаз или проектов. 5.3.2 Определение содержания: инструменты и методы 5.3.2.1 Экспертная оценка Описана в разделе 4.1.2.1. Следует учитывать экспертные заключения, полученные от лиц или групп, обладающих специальными знаниями или опытом работы над аналогичными проектами. 5.3.2.2 Анализ данных В качестве примера метода анализа данных, который можно использовать в данном про- цессе, можно привести, среди прочего, анализ альтернатив. Анализ альтернатив можно исполь- зовать для оценки способов исполнения требований и достижения целей, предусмотренных в уставе. 5.3.2.3 Принятие решений Описано в разделе 5.1.2.2. Методы принятия решений, которые можно использовать в данном процессе, включают в себя, среди прочего, анализ решений на основе множества кри- териев. Описанный в разделе 8.1.2.4 анализ решений на основе множества критериев – это метод, в котором используется матрица решений для обеспечения систематического анали- тического подхода к установлению критериев, таких как требования, расписание, бюджет и ресурсы, для уточнения содержания проекта и продукта для данного проекта. 5.3.2.4 Навыки межличностных отношений и работы с командой Описаны в разделе 4.1.2.3. Примером метода применения навыков межличностных отно- шений и работы с командой является фасилитация. Фасилитация используется при проведении семинаров и рабочих сессий с участием ключевых заинтересованных сторон, которые имеют разнообразные ожидания и опыт в различных областях. Цель состоит в достижении межфунк- ционального и общего понимания поставляемых результатов и проекта, а также границ про- дукта. 5.3.2.5 Анализ продукта Анализ продукта может использоваться для определения продуктов и услуг. Он состоит в постановке вопросов о продукте или услуге и формировании ответов для описания исполь- зования, характеристик и других релевантных аспектов того, что должно входить в поставку. В каждой прикладной области существует один или несколько общепринятых методов перевода высокоуровневых описаний продукта или услуги в значимые поставляемые резуль- таты. Требования регистрируются на высоком уровне и раскладываются до уровня детализа- ции, необходимого для проектирования конечного продукта. Примеры методов анализа про- дукта включают в себя, среди прочего: . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 138 ♦ разбиение продукта на составные части, ♦ анализ требований, ♦ анализ систем, ♦ системную инженерию, ♦ анализ ценности, ♦ функционально-стоимостный анализ. 5.3.3 Определение содержания: выходы 5.3.3.1 Описание содержания проекта Описание содержания проекта – это изложение содержания проекта, основных постав- ляемых результатов, допущений и ограничений. Описание содержания проекта документирует все содержание, включая содержание проекта и продукта. Оно содержит детальное описание поставляемых результатов проекта. Описание содержания проекта также формулирует общее понимание содержания проекта заинтересованными сторонами. Оно может содержать явные исключения из содержания, что может помочь в управлении ожиданиями заинтересованных сторон. Оно позволяет команде проекта осуществлять более детальное планирование, направ- ляет работу команды проекта во время исполнения и предоставляет базовый план для оценки того, попадают ли запросы на изменения или дополнительная работа в границы проекта. Степень и уровень детализации, с которой описание содержания проекта определяет работу, которая будет выполнена, и работу, которая исключена, могут помочь определить, насколько хорошо команда управления проектом может контролировать содержание всего проекта. Подробное описание содержания проекта либо непосредственно, либо в виде ссылок на другие документы включает в себя: ♦ Описание содержания продукта. Последовательно уточняет характеристики про- дукта, услуги или результата, описанного в уставе проекта или в документации по требова- ниям. ♦ Поставляемые результаты. Любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта. Поставляемые результаты также включают в себя вспомогатель- ные результаты, такие как отчеты и документы по управлению проектом. Данные поставляе- мые результаты могут быть описаны обобщенно или с высокой степенью детализации. ♦ |