Sb97307

МИНОБРНАУКИ РОССИИ

––––––––––––––––––––––––––––––––––––––––––––––––––––

Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» им. В. И. Ульянова (Ленина)

–––––––––––––––––––––––––––––––––––––––––––

К. В. КРИНКИН А. А. ЛИСС

УПРАВЛЕНИЕ ПРОГРАММНЫМ ПРОЕКТОМ

Учебно-методическое пособие

Санкт-Петербург Издательство СПбГЭТУ «ЛЭТИ»

2017

УДК 004.413(07)

ББК З973.2-018-02я7 + У9(2)29-21я7 К82

Кринкин К. В., Лисс А. А.

К82 Управление программным проектом: учеб.-метод. пособие. СПб.: Изд-во СПбГЭТУ «ЛЭТИ», 2017. 32 с.

ISBN 978-5-7629-2383-5

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

Предназначено для студентов 4-го курса направлений 09.03.04 – «Программная инженерия» (учебный план № 032) и 01.03.02 – «Прикладная математика и информатика» (учебный план № 038).

УДК 004.413(07)

ББК З973.2-018-02я7 + У9(2)29-21я7

Рецензент: руководитель проекта, канд. техн. наук, доцент С. В. Родионов (АО «НИЦ СПб ЭТУ»).

Утверждено редакционно-издательским советом университета

в качестве учебно-методического пособия

2

ВВЕДЕНИЕ

На сегодняшний день в области управления проектами по разработке программного обеспечения (ПО) используется множество различных подхо-

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

ления любыми проектами. В рамках курса «Управление разработкой и экономика программных проектов» следует опираться на подход, разработан-

ный Международным некоммерческим институтом управления проектами

PMI ( Project Management Institute) и изложенный в [1]. Говоря об этом под-

ходе, будем называть его PMBoK. PMBoK – это аббревиатура от Project Management Body of Knowledge, что в переводе означает «Свод знаний по управ-

лению проектом». Относительно недавно PMI разработал расширение PMBoK для управления проектами разработки программного обеспечения –

The Software Extension to the PMBoK (SWX), которое фактически определяет гибкий подход к разработке программного обеспечения как «лучший подход». Также SWX отказалось от противопоставления прогнозируемой и адаптивной моделей жизненного цикла программного проекта, установив, что адаптивные проекты также планируются, а прогнозируемые проекты также управляются изменениями. О гибком подходе речь пойдет в разд. 5 настоящего пособия.

Согласно PMBoK существует 10 областей знания об управлении:

1)интеграцией проекта;

2)содержанием;

3)расписанием;

4)стоимостью;

5)качеством;

6)коммуникациями;

7)закупками;

8)заинтересованными лицами;

9)рисками;

10)человеческими ресурсами.

В перечисленных областях знаний выделяют процессы управления про-

ектом, которые объединяются в 5 групп: процессы инициации (I); планирования (P); исполнения (E); мониторинга и управления (M&C); завершения

3

(C). Между группами процессов существуют переходы, которые происходят при определенных условиях.

В группе инициации находятся процессы, в результате которых произ-

водится «запуск» проекта. Это официальное признание проекта, высокоуровневое планирование и определение заинтересованных лиц. Результаты фик-

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

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

инициации поступают на вход группы

Рис. В1

процессов планирования (переход 1).

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

ход 2). Процессы группы исполнения – это процессы, применяемые для выполнения работ, определенных в плане управления проектом, с целью удов-

летворения требованиям проекта.

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

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

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

ществляется обратный переход к группе процессов исполнения для реализации корректирующего воздействия (переход 4). Если требуются более серь-

езные корректирующие воздействия, происходит переход к группе планирования для пересмотра плана управления проектом (переход 5), и т. д. Если требуются корректирующие воздействия, сильно меняющие базовые планы,

производится переход к группе инициации для определения целесообразно-

сти продолжения проекта (переход 6). На рис. В1 переход 6 отмечен штрихо-

4

вой линией, как крайне нежелательный. Результатом перехода к группе ини-

циации в этом случае может стать решение о прекращении работ по проекту.

Когда все работы выполнены либо принято решение о прекращении проекта, происходит переход к группе процессов завершения (переход 7), выполняемых для завершения всех действий в рамках всех групп процессов и формального завершения проекта или его фазы. Группа процессов завершения очень важна для организации, поскольку именно на этом этапе форми-

руются документы, которые на языке оригинала называются «lessons learned» и представляют собой анализ, что в этом проекте было сделано хо-

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

ство проектов были успешными.

На рис. В2 показано, как в PMBoK связаны области знаний и группы процессов управления проектом. Видно, что область знаний «Управление интеграцией проекта» включает в себя процессы всех пяти групп, а процессы группы планирования применяются для всех областей знания.

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

Инициация: назначают руководителя проекта (РП), анализируют информацию о предыдущих проектах, разделяют большие проекты на этапы

5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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