Текст книги "Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство"

Контекстные диаграммы являются примером модели содержания. Контекстные диаграммы визуально отображают содержание продукта, показывая бизнес-систему (процесс, оборудование, компьютерную систему и т. д.) и то, как люди и другие системы (действующие лица) взаимодействуют с ней (см. рис. 5–6). Контекстные диаграммы демонстрируют входы бизнес-системы, действующих лиц, обеспечивающих вход, выходы бизнес-системы и действующих лиц, получающих выход.

Рис. 5–6. Контекстные диаграммы

Прототипирование представляет собой метод получения предварительных отзывов относительно требований путем предоставления модели ожидаемого продукта, прежде чем создавать продукт в действительности. Примерами прототипов являются продукты небольшого размера, модели, выполненные с помощью компьютерной двух– или трехмерной графики, макеты или имитации. Прототипы позволяют заинтересованным сторонам экспериментировать с моделью конечного продукта, а не ограничиваться обсуждением абстрактных представлений своих требований. Прототипы поддерживают концепцию последовательного уточнения в итеративных циклах создания макетов, проведения экспериментов пользователем, формирования отзывов и пересмотра прототипа. После проведения достаточного числа циклов обратной связи требования, полученные с помощью прототипа, оказываются в достаточной мере полными для перехода к фазе проектирования или создания.

Раскадровка (storyboarding) – это метод прототипирования, использующий последовательность или навигацию в рамках серии изображений или иллюстраций. Раскадровка используется в различных проектах во многих отраслях, например, при создании фильмов, в рекламе, педагогическом проектировании, в проектах гибкой разработки и других проектах разработки программного обеспечения. При разработке программного обеспечения в раскадровке используются макеты, чтобы продемонстрировать возможности навигации по веб-страницам, экранам или другим интерфейсам пользователей.

Документация по требованиям описывает, каким образом отдельные требования соответствуют бизнес-потребности в проекте. Требования могут быть сначала описаны высокоуровнево, а затем постепенно детализироваться по мере поступления новой информации о них. До включения в базовый план требования должны стать однозначными (измеримыми и проверяемыми), отслеживаемыми, полными, непротиворечивыми и приемлемыми для ключевых заинтересованных сторон. Формат документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинтересованным сторонам и приоритетам, до более тщательно проработанных форм, содержащих резюме для руководства, подробные описания и приложения.

Многие организации подразделяют требования на различные типы, например, бизнес-решения и технические решения, причем первые относятся к потребностям заинтересованных сторон, а последние – к способу реализации этих потребностей. Требования могут быть сгруппированы в классы, что обеспечивает их дальнейшее уточнение и детализацию в процессе их выработки. Данные классы включают в себя:

♦ Бизнес-требования. Бизнес-требования описывают высокоуровневые потребности организации в целом, например, проблемы или благоприятные возможности организации, а также причины, по которым проект был инициирован.

♦ Требования заинтересованных сторон. Требования заинтересованных сторон описывают потребности заинтересованной стороны или группы заинтересованных сторон.

♦ Требования к решению. Требования к решению описывают свойства, функции и характеристики продукта, услуги или результата, который удовлетворяет бизнес-требованиям и требованиям заинтересованных сторон. Требования к решению, в свою очередь, группируются в функциональные и нефункциональные требования:

• Функциональные требования. Функциональные требования описывают поведение продукта. Примеры включают в себя операции, процессы, данные и взаимодействия, которые должен исполнять продукт.

• Нефункциональные требования. Нефункциональные требования дополняют функциональные и описывают условия или качества среды, необходимые для обеспечения эффективности продукта. Примеры включают в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уничтожению и т. д.

♦ Требования на переходный период и по обеспечению готовности. Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в желаемое состояние в будущем.

♦ Требования к проекту. Требования к проекту описывают действия, процессы или другие условия, которым должен соответствовать проект. В качестве примеров можно назвать даты контрольных событий, договорные обязательства, ограничения и т. п.

♦ Требования к качеству. Требования к качеству, включающие в себя любое состояние или критерии, необходимые для подтверждения успешного получения поставляемого результата проекта или выполнения других требований к проекту. В качестве примеров можно назвать тестирование, сертификацию, подтверждения и т. п.

Матрица отслеживания требований – это таблица, связывающая требования к продукту, начиная от их создания и заканчивая предоставлением соответствующих им поставляемых результатов. Применение матрицы отслеживания требований помогает удостовериться, что каждое требование добавляет бизнес-ценность, связывая требование с целями организации и проекта. Это позволяет отслеживать требования на протяжении жизненного цикла проекта, что помогает удостовериться в том, что требования, одобренные в документации по требованиям, выполнены в конце проекта. Наконец, матрица отслеживания требований обеспечивает структуру для управления изменениями содержания продукта.

Требования к отслеживанию включают в себя, среди прочего:

♦ бизнес-потребности, а также благоприятные возможности, цели и задачи организации;

♦ цели проекта;

♦ содержание проекта и поставляемые результаты ИСР;

♦ проектирование продукта;

♦ разработку продукта;

♦ стратегию и сценарии тестирования;

♦ детализацию от высокоуровневых до более детальных требований.

Параметры, связанные с каждым требованием, могут быть зафиксированы в матрице отслеживания требований. Данные параметры помогают определить ключевую информацию относительно требований. Типичные параметры, используемые в матрице отслеживания требований, могут включать в себя: уникальный идентификатор, текстовое описание требования, обоснование включения в список требований, владельца требования, источник, приоритет, версию, текущий статус (например, активно, отменено, отложено, добавлено, одобрено, назначено, выполнено) и дату статуса. Дополнительные параметры, позволяющие удостовериться, что требование удовлетворяет заинтересованные стороны проекта, могут включать в себя также стабильность, сложность и критерии приемки. На рис. 5–7 представлен пример матрицы отслеживания требований с включенными в нее параметрами требований.

Рис. 5–7. Пример матрицы отслеживания требований

Определение содержания – процесс разработки подробного описания проекта и продукта. Ключевая выгода данного процесса состоит в том, что он позволяет описать границы и критерии приемки продукта, услуги или результата. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–8. На рис. 5–9 показана диаграмма потоков данных процесса.

Рис. 5–8. Определение содержания: входы, инструменты и методы, выходы

Рис. 5–9. Определение содержания: диаграмма потоков данных

Поскольку в проект невозможно включить все требования, выявленные в процессе сбора требований, окончательные требования к проекту выбираются в ходе процесса определения содержания из документации по требованиям, разработанной в рамках процесса сбора требований. Затем создается подробное описание проекта, а также продукта, услуги или результата.

Подготовка подробного описания содержания проекта основывается на главных поставляемых результатах, допущениях и ограничениях, документированных во время инициации проекта. Содержание проекта определяется во время планирования и описывается более подробно по мере поступления информации о проекте. Существующие риски, допущения и ограничения анализируются на предмет полноты и добавляются или актуализируются по мере необходимости. Процесс определения содержания может быть в высокой степени итеративным. В проектах с итеративным жизненным циклом высокоуровневое видение разрабатывается для всего проекта, но подробное содержание определяется последовательно в процессе каждой итерации, а детализированное планирование следующей итерации осуществляется по мере выполнения работ в отношении текущего содержания и поставляемых результатов проекта.

Описан в разделе 4.1.3.1. Устав проекта предоставляет высокоуровневое описание проекта и высокоуровневые характеристики продукта, а также требования к одобрению.

Описан в разделе 4.2.3.1. Компонент плана управления проектом включает в себя, среди прочего, план управления содержанием, как описано в разделе 5.1.3.1, который документирует порядок определения, подтверждения и контроля содержания проекта.

В качестве примеров документов проекта, которые можно считать входами в данный процесс, можно назвать, среди прочего:

♦ Журнал допущений. Описан в разделе 4.1.3.2. В журнале допущений определяются допущения и ограничения в отношении продукта, проекта, среды, заинтересованных сторон и других факторов, которые могут повлиять на проект и содержание продукта.

♦ Документацию по требованиям. Описана в разделе 5.2.3.1. Документация по требованиям определяет требования, которые будут включены в состав содержания.

♦ Реестр рисков. Описан в разделе 11.2.3.1. Реестр рисков содержит стратегии реагирования, которые могут влиять на содержание проекта, например, сокращение или изменение содержания проекта и продукта, чтобы уклониться от риска или снизить риск.

Факторы среды предприятия, которые могут оказывать влияние на процесс определения содержания, включают в себя, среди прочего:

♦ организационную культуру,

♦ инфраструктуру,

♦ управление персоналом,

♦ ситуацию на рынке.

Активы процессов организации, которые могут оказывать влияние на процесс определения содержания, включают в себя, среди прочего:

♦ политики, процедуры и шаблоны описания содержания проекта;

♦ архивы предыдущих проектов;

♦ извлеченные уроки из предыдущих фаз или проектов.

Описана в разделе 4.1.2.1. Следует учитывать экспертные заключения, полученные от лиц или групп, обладающих специальными знаниями или опытом работы над аналогичными проектами.

В качестве примера метода анализа данных, который можно использовать в данном процессе, можно привести, среди прочего, анализ альтернатив. Анализ альтернатив можно использовать для оценки способов исполнения требований и достижения целей, предусмотренных в уставе.

Описано в разделе 5.1.2.2. Методы принятия решений, которые можно использовать в данном процессе, включают в себя, среди прочего, анализ решений на основе множества критериев. Описанный в разделе 8.1.2.4 анализ решений на основе множества критериев – это метод, в котором используется матрица решений для обеспечения систематического аналитического подхода к установлению критериев, таких как требования, расписание, бюджет и ресурсы, для уточнения содержания проекта и продукта для данного проекта.

Описаны в разделе 4.1.2.3. Примером метода применения навыков межличностных отношений и работы с командой является фасилитация. Фасилитация используется при проведении семинаров и рабочих сессий с участием ключевых заинтересованных сторон, которые имеют разнообразные ожидания и опыт в различных областях. Цель состоит в достижении межфункционального и общего понимания поставляемых результатов и проекта, а также границ продукта.

Анализ продукта может использоваться для определения продуктов и услуг. Он состоит в постановке вопросов о продукте или услуге и формировании ответов для описания использования, характеристик и других релевантных аспектов того, что должно входить в поставку.

В каждой прикладной области существует один или несколько общепринятых методов перевода высокоуровневых описаний продукта или услуги в значимые поставляемые результаты. Требования регистрируются на высоком уровне и раскладываются до уровня детализации, необходимого для проектирования конечного продукта. Примеры методов анализа продукта включают в себя, среди прочего:

♦ разбиение продукта на составные части,

♦ анализ требований,

♦ анализ систем,

♦ системную инженерию,

♦ анализ ценности,

♦ функционально-стоимостный анализ.

Описание содержания проекта – это изложение содержания проекта, основных поставляемых результатов, допущений и ограничений. Описание содержания проекта документирует все содержание, включая содержание проекта и продукта. Оно содержит детальное описание поставляемых результатов проекта. Описание содержания проекта также формулирует общее понимание содержания проекта заинтересованными сторонами. Оно может содержать явные исключения из содержания, что может помочь в управлении ожиданиями заинтересованных сторон. Оно позволяет команде проекта осуществлять более детальное планирование, направляет работу команды проекта во время исполнения и предоставляет базовый план для оценки того, попадают ли запросы на изменения или дополнительная работа в границы проекта.

Степень и уровень детализации, с которой описание содержания проекта определяет работу, которая будет выполнена, и работу, которая исключена, могут помочь определить, насколько хорошо команда управления проектом может контролировать содержание всего проекта. Подробное описание содержания проекта либо непосредственно, либо в виде ссылок на другие документы включает в себя:

♦ Описание содержания продукта. Последовательно уточняет характеристики продукта, услуги или результата, описанного в уставе проекта или в документации по требованиям.

♦ Поставляемые результаты. Любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта. Поставляемые результаты также включают в себя вспомогательные результаты, такие как отчеты и документы по управлению проектом. Данные поставляемые результаты могут быть описаны обобщенно или с высокой степенью детализации.

♦ Критерии приемки. Набор условий, которые должны быть выполнены до того, как поставляемые результаты будут приняты.

♦ Исключения из проекта. Определяет, что исключено из проекта. Явная формулировка того, что именно находится вне содержания проекта, помогает управлять ожиданиями заинтересованных сторон и может сократить расползание содержания.

Хотя устав проекта и описание содержания проекта иногда воспринимаются как документы, в определенной степени дублирующие друг друга, они различаются уровнем детализации. Устав проекта содержит высокоуровневую информацию, а описание содержания проекта – подробное описание компонентов содержания. Данные компоненты последовательно уточняются в течение проекта. В таблице 5–1 описаны некоторые из ключевых элементов каждого документа.

Таблица 5–1. Элементы устава проекта и описания содержания проекта

В качестве документов проекта, которые могут быть обновлены в результате осуществления данного процесса, можно назвать, среди прочего:

♦ Журнал допущений. Описан в разделе 4.1.3.2. Журнал допущений обновляется путем внесения дополнительных допущений или ограничений, которые были определены в ходе этого процесса.

♦ Документацию по требованиям. Описана в разделе 5.2.3.1. Документация по требованиям может обновляться путем внесения в нее дополнительных или измененных требований.

♦ Матрицу отслеживания требований. Описана в разделе 5.2.3.2. Матрица отслеживания требований может обновляться с целью отражения обновлений, внесенных в документацию по требованиям.

♦ Реестр заинтересованных сторон. Описан в разделе 13.1.3.1. Дополнительная информация о существующих или новых заинтересованных сторонах вносится в реестр заинтересованных сторон по мере ее поступления.

Создание иерархической структуры работ (ИСР) – это процесс разделения поставляемых результатов проекта и работ проекта на меньшие компоненты, которыми легче управлять. Ключевая выгода данного процесса состоит в том, что он определяет структуру того, что необходимо поставить. Этот процесс выполняется единожды или в предопределенные моменты в проекте. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5-10. На рис. 5-11 показана диаграмма потоков данных процесса.

Рис. 5-10. Создание ИСР: входы, инструменты и методы, выходы

Рис. 5-11. Создание ИСР: диаграмма потоков данных

ИСР – это иерархическая декомпозиция полного содержания работ, выполняемых командой проекта для достижения целей проекта и создания требуемых поставляемых результатов. ИСР организует и определяет общее содержание проекта и отображает работы, указанные в текущем одобренном описании содержания проекта.

Запланированные работы содержатся в элементах ИСР самого нижнего уровня, которые называются пакетами работ. Пакет работ может использоваться для группировки операций, на уровне которых составляется расписание работ и проводится их оценка, осуществляется мониторинг и контроль. В контексте ИСР «работы» означают продукты или поставляемые результаты, являющиеся результатами операций, но не сами операции.

Компонент плана управления проектом включает в себя, среди прочего, план управления содержанием: Описанный в разделе 5.1.3.1 план управления содержанием документально оформляет порядок создания ИСР на основе положений описания содержания проекта.

В качестве примеров документов проекта, которые можно считать входами в данный процесс, можно назвать, среди прочего:

♦ Описание содержания проекта. Описано в разделе 5.3.3.1. Описание содержания проекта описывает работы, которые будут исполнены, и исключенные работы.

♦ Документацию по требованиям. Описана в разделе 5.2.3.1. Детальное описание требований содержит описание того, каким образом отдельные требования соответствуют определенной бизнес-потребности для данного проекта.

Факторы среды предприятия, которые могут влиять на процесс создания ИСР, включают в себя, среди прочего, стандарты ИСР конкретной отрасли, соответствующие характеру данного проекта. Указанные стандарты ИСР конкретной отрасли могут служить внешним источником справочных материалов для создания ИСР.

Активы процессов организации, которые могут оказывать влияние на процесс создания ИСР, включают в себя, среди прочего:

♦ политики, процедуры и шаблоны для ИСР;

♦ архивы предыдущих проектов;

♦ извлеченные уроки из предыдущих проектов.

Описана в разделе 4.1.2.1. Следует учитывать экспертные заключения, полученные от лиц или групп, обладающих специальными знаниями или опытом работы над аналогичными проектами.

Декомпозиция – это метод, предполагающий разбиение содержания и поставляемых результатов проекта на более мелкие и более управляемые элементы. Пакет работ – это работа, расположенная на самом низком уровне иерархической структуры работ, для которой возможна оценка стоимости и длительности, а также управление ими. На уровень декомпозиции зачастую влияет степень контроля, необходимого для результативного управления проектом. Уровень детализации пакетов работ различается в зависимости от масштаба и сложности проекта. Декомпозиция всей совокупности работ проекта до пакетов работ обычно включает в себя следующие операции:

♦ определение и анализ поставляемых результатов и соответствующих работ;

♦ структурирование и организацию ИСР;

♦ декомпозицию верхних уровней ИСР на детализированные компоненты более низких уровней;

♦ разработку и присвоение идентификационных кодов компонентам ИСР;

♦ проверку приемлемости степени декомпозиции поставляемых результатов.

На рис. 5-12 показана часть ИСР с некоторыми ответвлениями ИСР, декомпозированными до уровня пакетов работ.

Рис. 5-12. Пример декомпозиции ИСР до пакетов работ

ИСР может создаваться с помощью различных подходов. Некоторые популярные методы включают в себя подход сверху-вниз, использование руководящих указаний конкретных организаций и применение шаблонов ИСР. Для группировки подкомпонентов можно использовать подход снизу-вверх. ИСР может быть создана в различных формах, например:

♦ в качестве второго уровня декомпозиции используются фазы жизненного цикла проекта, на третьем уровне расположены поставляемые результаты, относящиеся к проекту и продукту, как показано на рис. 5-13;

♦ в качестве второго уровня декомпозиции используются основные поставляемые результаты, как показано на рис. 5-14;

♦ используются подкомпоненты, которые могут разрабатываться организациями, не входящими в команду проекта, например, работающими по договору. В таких случаях продавец разрабатывает поддерживающую договор ИСР как часть работы по договору.

Рис. 5-13. Пример ИСР, организованной по фазам

Рис. 5-14. Пример ИСР с основными поставляемыми результатами

Для декомпозиции компонентов ИСР верхнего уровня требуется разделение работ по каждому поставляемому результату или подкомпонентам на основополагающие компоненты, где компоненты ИСР представляют собой поддающиеся проверке продукты, услуги или результаты. Если используется гибкий подход, обобщенные проектные документы можно разбить на пользовательские истории. ИСР может быть структурирована в виде схемы, организационной диаграммы или другим методом, отражающим иерархическое разбиение. Проверка правильности декомпозиции требует удостоверения в том, что компоненты ИСР низкого уровня – это именно те компоненты, которые необходимы и достаточны для создания соответствующих поставляемых результатов более высокого уровня. Различные поставляемые результаты могут иметь различные уровни декомпозиции. Работы по некоторым поставляемым результатам достаточно декомпозировать всего лишь до следующего уровня, чтобы достичь уровня пакетов работ, однако для других могут потребоваться дополнительные уровни декомпозиции. По мере декомпозиции работ до более глубоких уровней детализации возможность планирования, управления и контроля работ расширяется. Однако чрезмерная декомпозиция может привести к непродуктивным управленческим трудозатратам, неэффективному использованию ресурсов, снижению эффективности выполнения работ и сложности консолидации данных различных уровней ИСР.

Декомпозиция может оказаться невозможной для поставляемых результатов или подкомпонентов, которые будут выполняться в далеком будущем. Команда управления проектом обычно дожидается согласования поставляемого результата или подкомпонента, чтобы иметь возможность разработать соответствующие детали ИСР. Этот метод иногда называют планированием методом набегающей волны.

ИСР отображает все работы, связанные с продуктом и проектом, включая работы по управлению проектом. Все содержание работ на самых нижних уровнях должно сворачиваться в более высокие уровни, чтобы ничего не было пропущено и не выполнялась лишняя работа. Иногда это называют правилом 100 %.

Для получения дополнительной информации по ИСР обратитесь к Практическому стандарту иерархических структур работ – Второму изданию (Practice Standard for Work Breakdown Structures – Second Edition) [15]. Этот стандарт содержит конкретные отраслевые примеры шаблонов ИСР, которые могут быть адаптированы к конкретным проектам в определенных прикладных областях.