План управления проектом

Привет всем.

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

Введение 2

Краткое описание проекта 2

Контекст, цели и задачи проекта 2

Список артефактов, которые будут получены в процессе работы над проектом 2

Организационная структура проекта 3

Участники проекта и их ответственность 3

Процесс управления проектом 3

Стартовые активности 3

Оценка 3

Выбор персонала 3

Ресурсы 4

Обучение персонала 4

Планирование работ 4

Предварительное расписание 4

Распределение персонала и ресурсов 4

Планируемый бюджет 4

Контроль проекта 4

Управление требованиями 4

Управление расписанием и бюджетом 5

Управление качеством 5

Управление коммуникациями 5

Управление метриками 7

Управление рисками 7

Закрытие проекта 8

Процесс разработки 8

Жизненный цикл проекта 8

Технические средства разработки 8

Инфраструктура 8

Процесс приемки продукта 9

Служебные процессы 9

Управление конфигурациями 9

План тестирования 9

Документирование 9

Процессы обеспечения качества 10

Процесс аудита кода проекта 10

Процесс работы с проблемами 10

Процесс управления контрактами 11

Процесс улучшения процессов 11

Версии документа 12



Введение

ООО «Заказчик», именуемое в дальнейшем «Заказчик», в лице директора Иванова Ивана Ивановича, действующего на основании Устава, с одной стороны, и ООО «Софтария» в лице директора, Кузьмина Романа Михайловича действующего на основании Устава, именуемое в дальнейшем « Исполнитель», с другой стороны, - в дальнейшем по отдельности или вместе именуемые «Сторона», «Стороны», -согласовали следующий план работы над проектом «Мегапроект».

Данный документ описывает план управления проектом «Мегапроект». Оперативное управление проектом осуществляется менеджерами Исполнителя.

Краткое описание проекта

Контекст, цели и задачи проекта

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

Список артефактов, которые будут получены в процессе работы над проектом

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

• Исходные коды программного обеспечения «Мегапроект» (Должны находиться в системе контроля версий SVN, установленной на территории Заказчика

• Дистрибутив программного обеспечения

• Инструкция по сборке дистрибутива из исходных кодов, находящихся в системе контроля версий.

• Инструкция по установке дистрибутива

• Руководство для администратора системы

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

• Техническое задание на разработку системы (SRS)
• Критерии приемки проекта
• Календарный план разработки
• Бюджет проекта
• Документ, описывающий архитектуру проекта (SAD)
• База данных учета изменений (это не документ, а база данных системы ISSUE Tracking JIRA)
• И данный документ — план управления проектом

Организационная структура проекта

Участники проекта и их ответственность

Со стороны Заказчика в проекте участвуют исполнители следующих ролей:

• Представитель заказчика — представитель Заказчика, ответственный за формулирование требований, принятие стратегических решений, одобрение или не одобрение изменений а также предоставление информации, необходимой разработчикам проекта. Обычно Представитель Заказчика является представителем группы лиц, осуществляющих стратегическое управление проектом, однако существование и состав этой группы лиц является внутренним делом компании Заказчика. При данном масштабе проекта предполагается один Представитель Заказчика.
• Главный заказчик — лицо, ответственное за разрешение проблем общего характера, в случае разногласий между менеджером проекта и представителем Заказчика.
• Администратор инфраструктуры — ответственен за предоставление доступа к системам, находящимся на стороне Заказчика (SVN, Jira итп) а также за обеспечение их бесперебойной работы.
• Приёмщики — лица, ответственные за проверку выполнения критериев приемки.

Со стороны Исполнителя в проекте участвуют

• Менеджер проекта — выстраивание процессов управления проектом, решение важных вопросов, контроль процесса, внесение корректив.

• Лидер команды — управление оперативной деятельностью проекта согласно заданным процессам.

• Аналитик — уточнение требований к проекту

• Разработчики проекта — разработка архитектуры, написание кода, тестирование результатов друг друга

• Эксперт - аудитор — выполнение независимого аудита кода

• Тестировщики — выполнение независимого тестирования

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

Процесс управления проектом

Стартовые активности

Оценка

Согласована с Заказчиком и определена в ТЗ

Выбор персонала

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

• Пелевин Дмитрий Олегович — Лидер команды, Старший разработчик

• Рудер Иван Давыдович — Аналитик, Разработчик

• Кузьмин Роман Михайлович — Менеджер проекта

• Чуркин Иван Валерьевич — Эксперт-аудитор

Тестировщики на этой стадии проекта не определены. Будут выбраны в зависимости от наличия свободного времени.

Ресурсы

Рабочие станции разработчиков и ПО, необходимое им для работы предоставляет Исполнитель.

Заказчик предоставляет доступ к системе контроля версий SVN, находящейся на одном из ее серверов и обеспечивает бесперебойную работу этого сервера и его доступ в интернет.

Заказчик предоставляет доступ к системе Issue Tracking-a JIRA.

Заказчик предоставляет доступ к системе класса Team Collabortaion (возможно Confluence, коль скоро используем JIRA).

Исполнитель также предоставляет сервер для сборки версий системы и систему Continuum, в качестве системы непрерывной интеграции(CI)

Обучение персонала

В рамках проекта необходимо выделение бюджета и времени для обучения разработчиков технологии Мегатехнология.

Планирование работ

Предварительное расписание

Первый релиз проект должен выйти 20 августа 2010 года

Распределение персонала и ресурсов

См. выше.

Планируемый бюджет

Бюджет проекта составляет 3 миллиона долларов.

Контроль проекта

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

Изменение требований инициируется Представителем Заказчика в виде создания нового Issue в JIRA и назначения Аналитика ответственным за него.

Аналитик ответственен за выполнение оценки влияния каждого изменения на проект. Изменение может

• Увеличить бюджет проекта

• Увеличить календарный срок проекта

• Внести в проект новые риски

В обязанности аналитика входит написание комментария к Issue с указанием влияния изменения на проект и внесения одной из своих рекомендаций

• Внести изменение в текущую итерацию проекта

• Внести изменение в следующую итерацию проекта

• Не вносить изменение вообще

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

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

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

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

Управление расписанием и бюджетом

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

Оплата работ Заказчиком производится ежемесячно. Оплачиваются задачи, законченные на момент выставления счета. Счет включает детализацию по задачам и их бюджетам.

Управление качеством

Управлять качеством — значит добиваться таких качественных показателей продукта, при которых он наиболее точно соответствует Business Case. (В отличие от процесса обеспечения качества, описанного в разделе «Служебные процессы», управление качеством не является синонимом повышения качества. Иногда, в процессе управления качеством, может быть принято решение, наоборот, понизить качество той или иной составляющей проекта, с целью сокращения времени выхода на рынок или уменьшения стоимости проекта)

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

Управление коммуникациями

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

• Система Issue Tracking — JIRA

• Система Team Collaboartion (Confluence или любая WIKI-based система)

• Электронная почта

• Телефон

JIRA используется для

• Управления требованиями (issue report) — см.управление требованиями.

• Создания и отслеживания состояния отчета об ошибке (bug-rpeort)

• Постановке задач разработчикам

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

Электронная почта используется как средство привлечь внимание участника проекта к дискуссии или Issue в системе Issue tracking либо когда необходимо решить административный или технический вопрос (например, у кого-то просрочен пароль в JIRA). Другое использование электронной почты — предоставление представителю заказчика еженедельных отчетов о состоянии дел в проекте. Вопросы по проекту, ответы на которые важны для дальнейшей разработки, никогда не задаются посредством электронной почты.

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

В таблице перечислены наиболее распространенные типы информации и способы их передачи.

Тип информации	Средство коммуникации	Источник информации	Адресат информации
Новое требование об изменении	JIRA	Представитель Заказчика	Аналитик
Отчет об ошибке	JIRA	Любой участник	Лидер команды
Подтвержденное требование об изменении	JIRA	Аналитик	Лидер команды
	Email		Менеджер проекта
Задача на исполнение	JIRA	Лидер команды	Разработчик, Тестировщик, Аудитор, Аналитик
Отчет об исполненной задаче	JIRA	Разработчик, Тестировщик, Аудитор, Аналитик	Лидер команды
Обсуждение вопросов, касающихся проекта	Confluence	все	все
Еженедельный отчет	Email	Лидер команды	Менеджер проекта, Представитель Заказчика
Запрос о доступе к инфраструктуре	Email	все	Администратор Инфраструктуры
Отчет о проблеме (эскалация)	Email	Участники проекта	Менеджер проекта, Лидер команды
Отчет о проблеме (эскалация)	Email	Менеджер проекта	Представитель Заказчика
Отчет о проблеме (эскалация)	Email	Закзачик	Менеджер проекта
Отчет о проблеме (эскалация)	Email, телефон	Представитель Заказчика, Менеджер проектов	Главный заказчик

Управление метриками

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

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

Сравнение текущего плана и факта (с указанием, успеваем ли мы по графику)

Перечисляются недооцененные и переоцененные задачи и задачи, ошибочно не включенные в изначальный план ( с целью дальнейшего анализа)

Управление рисками

На стадии планирования проекта определены следующие риски:

• Непонимание бизнес цели проекта Исполнителем (может привести к не идеальной реализации)
• Нарушения в работе распределенной команды, вызванные задержками со стороны персонала Заказчика
• Нарушения работы, вызванные неготовностью оборудования и сервисов, предоставляемых заказчиком
• Болезнь одного из ключевых членов проектной команды
• Неправильная оценка ожидаемой нагрузки на сервер
• Плохая пригодность технологии Мегатехнология к созданию Мегапроекта

По данным рискам:

Риск	Вероятность	Важность	Вредный эффект	Стратегия предотвращения	Стратегия преодоления
Нарушения работы, вызванные неготовностью оборудования и сервисов	Низкая	Средняя	Календарные задержки и увеличение бюджета.	По возможности, подготовить резервный вариант для JIRA и Confluence	Временно использовать другие средства коммуникации. Временно прекратить делать commit-ы в SVN
Болезнь одного из ключевых членов проектной команды	Низкая	Средняя	Календарные задержки	Продумать возможные замены.	Заменить заболевшего.

В обязанности менеджера проекта входит отслеживание возникновения как идентифицированных так и непредвиденных рисков.

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

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

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

Закрытие проекта

При закрытии проекта должны пройти следующие фазы:

• Приемщики проекта должны принять проект в соответствии с критериями приемки. В случае несоответствия проекта критериям, должен быть создан перечень несоответствий и отправлен Менеджеру проекта (фактически, этого не должно произойти, поскольку все неисправности должны быть устранены до этого в процессе работы над проектом). По факту приемки ими подписывается акт приемки.

• Представителю Заказчика должны быть переданы артефакты, перечисленные в начале этого документа.

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

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

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

Процесс разработки

Жизненный цикл проекта

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

Работающие версии будут создаваться в результате относительно коротких итераций (в терминологии Scrum — спринтов). Длина одного спринта будет от недели до трех недель. Результат итерации — работающая версия с четко определенной функциональностью будет помечаться в SVN путём создания ветки (branch).

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

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

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

Технические средства разработки

Разработка ведется на Java 1.6 под ОС Windows XP с применением Eclipse IDE и Tortoise SVN в качестве Svn-клиента.

Для планирования итераций используется JIRA.

Инфраструктура

См Ресурсы

Процесс приемки продукта

Основным критерием приёмки продукта является его пригодность для решения бизнес-задач (соответствие Business Case).

Формальные критерии — соответствие функциональным и нефункциональным требованиям.

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

Служебные процессы

Управление конфигурациями

Процесс сборки дистрибутива проекта будет осуществляться при помощи системы maven.

Будет написана краткая инструкция по сборке, позволяющая собрать дистрибутив из любой версии, находящейся в системе контроля версий. Для сборки необходимо будет:

• рабочая машина с выходом в интернет

• java 1.6

• maven

• СУБД Mysql

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

План тестирования

В процессе разработки, разработчики постоянно тестируют результаты друг друга, а также просматривают код друг друга (непосредственно после выполнения update из SVN).

Тестировщики тестируют только версии — результаты итераций. Результаты тестируются согласно плану итерации. Отдельный документ — тест план не создаётся.

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

Документирование

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

Из них создаются и согласуются единожды на стадии планирования проекта:

• Техническое задание на разработку системы (SRS) — (Дальнейшие изменения фиксируются лишь в JIRA.)

Могут пересматриваться в исключительных случаях

• Документ, описывающий архитектуру проекта (SAD)

• Данный документ (план управления проектом)

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

• Критерии приемки проекта

• Календарный план разработки

• Бюджет проекта

Изменяются ежедневно:

• База данных учета изменений (это не документ, а база данных системы ISSUE Tracking JIRA)

Создаются еженедельно:

• Отчеты о состоянии проекта.

Отчеты включают в себя —

• Список задач, над которыми работала команда

• Список законченных задач

• Потраченный за неделю бюджет

• Сравнение текущего и первоначального планов (календарного и бюджетного)

• Сравнение текущего плана и факта (успеваем ли вовремя)

• Список изменений, включенных в план за неделю и их влияние на проект

• Список произошедших за неделю рисков и их влияние на проект

• Список найденных за неделю потенциальных рисков и их влияние на проект

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

Процессы обеспечения качества

На обеспечение должного уровня качества направлены следующие действия:

• Правило не включения изменения в текущую итерацию. Направлено на исключение «несходимости» процесса.

• Согласование с Заказчиком всех решений, могущих повлиять на качество

• Периодический аудит бизнес целей проекта менеджером

• Периодический аудит кода экспертами

• Использование системы непрерывной интеграции

• Парное тестирование и независимое тестирование

• Жесткий процесс отбора персонала для участия в проекте

Процесс аудита кода проекта

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

Важно отметить, что в качестве критериев качества кода предполагается использовать критерии, выработанные нашей компанией совместно с немецким партнером (Brox IT Solutions) и используемые при разработке ПО для европейских корпораций (Siemens, Volkswagen, Дойче Телеком, Credit Suisse). Данные критерии доступны на английском языке в виде WIKI. По желанию Заказчика, к ним будет предоставлен доступ.

Процесс работы с проблемами

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

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

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

Процесс управления контрактами

В данном проекте отсутствует

Процесс улучшения процессов

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



Версии документа

Дата	Версия	Описание	Автор
17.07.2008	1.0	Первая версия	Кузьмин Роман Михайлович
15.08.2008	1.1	Уточненная версия	Кузьмин Роман Михайлович
15.08.2008	1.2	Правки для большей юридической точности	Кузьмин Роман Михайлович