Материал: Sb97307

(фазы), анализируют бизнес-необходимость, определяют начальные требова-

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

вают устав проекта, определяют заинтересованные стороны, разрабатывают стратегию управления заинтересованными сторонами, выполняют высоко-

уровневое планирование. Основные выходы инициации – устав проекта и реестр заинтересованных лиц.

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

расписание, бюджет, метрики качества, все роли и ответственности; планируют коммуникации. Затем идентифицируют и анализируют риски; плани-

руют реагирование на риски; уточняют все планы в соответствии с рисками (новая итерация) и составляют базовый план. Только после определения рисков могут быть окончательно определены сроки и бюджет. Риски могут повлиять также на все остальные составляющие плана управления проектом.

Основные выходы – базовый план (по содержанию, стоимости и расписанию)

и реестр рисков.

Исполнение: выполняют работы в соответствии с планом, производят продукт, запрашивают изменения, реализуют утвержденные изменения,

обеспечивают качество, проводят аудит качества, управляют командой, оценивают проект и команду, укрепляют команду, премируют и награждают,

разрешают конфликтные ситуации, освобождают ресурсы, если работа закончена, обмениваются информацией, проводят совещания, выбирают соис-

полнителей. Основные выходы – продукт и запросы на изменения. Мониторинг и управление: измеряют эффективность проекта, измеря-

ют отклонения и запрашивают корректирующие действия, отслеживают факторы, которые могут привести к изменениям, одобряют или отвергают изме-

нения, информируют заинтересованные стороны о результатах изменений, проводят приемку промежуточных результатов заказчиком, выполняют кон-

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

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

6

обновляют базу знаний о проектах. Основные выходы – принятые результа-

ты и обновленная база знаний о проектах.

Завершая вводный раздел, необходимо отметить, что в большинство пе-

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

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

димо только менеджерам, – это необходимо всей команде.

В следующих разделах приводятся методические указания по созданию некоторых из основных выходов процессов управления проектом.

1. РАЗРАБОТКА УСТАВА ПРОЕКТА И РЕЕСТРА

ЗАИНТЕРЕСОВАННЫХ ЛИЦ

Разработка устава проекта это один из двух процессов группы инициации. О втором процессе – определении заинтересованных лиц – также будет сказано в конце этого раздела. Две основные функции, которые выполняет устав проекта: во-первых, устав наделяет полномочиями руководителя про-

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

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

Не только руководитель проекта, но и вся команда максимально заинтересована в создании устава, поэтому логично, что основные его положе-

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

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

«тройственное ограничение» проекта, хотя на практике ограничений может

7

быть и больше. В свою очередь, из рисков вытекают допущения проекта: «Мы выполним проект с заданными ограничениями, если будут созданы сле-

дующие условия: <перечисляются условия>».

Устав проекта «______________________________________________»

Рис. 1.1

С ограничениями по срокам связаны основные вехи – промежуточные контрольные точки, которые помогают управлять расписанием проекта. Ос-

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

В уставе должны быть определены основные его результаты. Для программного проекта это – разработанный программный продукт и документа-

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

Критерии успешности проекта определяют, в каком случае проект можно считать успешным. Соблюдены ли ограничения проекта или допустимы отклонения? Если допустимы отклонения, каковы их возможные значения? Критерии успешности зависят от конкретного проекта, одно можно сказать точно – в соответствии с PMBoK, если недоволен заказчик, проект успешным считать нельзя! Поэтому обязательной целью любого проекта должно быть получение одобрения заказчика, которое не выражается исключительно в формальной приемке работ по контракту. Если заказчик никогда больше не воспользуется вашими услугами, цель проекта – «получение одобрения заказчика» – не будет достигнута. Считается, что цели должны быть поставле-

ны конкретно (specific), быть измеримыми (measurable), достижимыми

8

(achievable), обоснованными (reasonable), ограниченными по времени (timebound). Интересно, что совокупность этих требований в англоязычном варианте может быть обозначена аббревиатурой SMART, что в переводе с анг-

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

так: «получить от АО ”ЗАКАЗЧИК” благодарственное письмо и новый заказ на разработку в течение следующего года». Для проекта автоматизации биз-

нес-процессов компании может быть поставлена, например, такая цель: «сократить максимальное время ожидания клиента в очереди до 5 минут».

Участниками проекта в широком смысле являются все заинтересованные стороны, которые могут влиять на проект как положительно, так и отри-

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

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

что выявление новых заинтересованных сторон влечет выявление новых требований к проекту и продукту.

О значимости управления заинтересованными лицами говорит тот факт, что связанные с ним процессы выделены в PMBoK в отдельную область зна-

ний начиная с его пятой редакции.

После того как в результате разработки устава проекта выполнено вы-

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

нирования. Планирование начинается с процессов, которые относятся к области знаний «Управление содержанием проекта».

2. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

Процессы этой области знаний «Управление содержанием проекта» находятся в группах процессов планирования и процессов мониторинга и управ-

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

9

Сбор требований – это процесс определения и документирования по-

требностей заинтересованных сторон проекта для достижения его целей. Многие организации разделяют требования на категории «требования к про-

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

речню функций программного продукта и т. д. Результатом процесса сбора требований служит описание требований и их перечень в виде матрицы от-

слеживания требований.

Матрица отслеживания – перечень всех выявленных требований с ука-

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

жания продукта, и будет использоваться на протяжении всего жизненного цикла проекта.

На основании перечня выявленных требований определяется содержание проекта, которое включает в себя состав работ по проекту и описание со-

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

щью диаграмм случаев использования.

Иерархическая структура работ – ориентированная на результат иерар-

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

держание проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта. ИСР делит проект на подпроекты,

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

На рис. 2.1 приведен пример ИСР для абстрактного проекта по разработке автоматизированной системы заказа товаров. В терминах PMBoK ИСР – это структура пакетов работ; перечень наименований пакетов работ называется «словарь ИСР». Таким образом, правильнее сказать, что на рис. 2.1 изображе-

на ИСР и словарь ИСР.

10