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

 

 

2.4 Количественная оценка рисков.

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

Вероятность достижения конечной цели проекта

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

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

Фактические затраты, предполагаемые сроки окончания.

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

 

 

2.5 Планирование реагирования на риски.

 

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

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

 

 

 

2.6.  Мониторинг и контроль.

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

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

Система реагирования на риски внедрена в соответствии с планом Реагирование достаточно эффективно или необходимы изменения          Риски изменились по сравнению с предыдущим значением             Наступление влияния рисков                                                              Необходимые меры приняты

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

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

 

 

Глава 3. Методика управления проектом

 

Существуют различные  методики управления проектами В данном курсе мы будем придерживаться методики «Мягкого внедрения» ведения проекта. Это методики мягкого и жесткого внедрения.

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

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

Данная технология разработки и внедрения имеет  следующие проверенные границы  применимости:

Рассчитано на взаимное доверие Заказчика и Исполнителя  в пределах не менее одного этапа  работ, имеется в виду, что Заказчик или Исполнитель могут блокировать  проект, но не более чем в рамках этапа.

Оптимально для  проектов сроком до 3х месяцев и  трудоемкостью до 1 чел/года. Для  изготовления более сложной системы, необходимо, чтобы ее отдельные модули внедрялись не дольше 3х месяцев, в противном случае методика не применима.

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

Заказчик готов  заплатить больше, но за результат, а не за усилия (время) Исполнителя. Покупка проекта, а не времени  Исполнителя позволяет Заказчику  снять с себя значительную часть  ответственности за свои проблемы и  ошибки.

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

Методика применима  для небольших заказных и серийных систем.

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

Основной продукт  этапа - документ "Постановка Задачи" (Product Vision).

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

На основе "Постановки Задачи" требуется составить документ "Экономическое обоснование".

Данный документ должен содержать статистическую оценку трудоемкости (себестоимости) работ. С  другой стороны, должен быть сделан анализ экономического эффекта от внедрения.

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

Для оценки рисков требуется разработать как минимум 2 простейших прототипа (они могут  быть выполнены как один).

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

"Архитектурный прототип" - это прототип, проверяющий самые критические места будущей архитектуры. Данный прототип служит для оценки технологических рисков.

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

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

В результате мы имеем  нечетко сформулированное задание "Постановка Задачи" и оценку стоимости  в "Экономическом обосновании". Риски от нечеткости требований должны быть покрыты пессимистичной оценкой. С точки зрения юридического договора "Постановка Задачи" может играть роль ТЗ, но с указанием в договоре на то, что более приоритетный документ "Документация пользователя" (см. ниже) и система будет приниматься по "Приемочным испытаниям" (см. также ниже)

 

 

Степень Важности	Продукт этапа	Описание продукта
1	Постановка Задачи	Цель проекта. Список ключевых требований без подробной расшифровки
2	Экономическое обоснование	Оценка экономического эффекта  и себестоимости проекта.
3	Интерфейсный прототип	Модель одного из ключевых интерфейсов пользователя
4	Архитектурный прототип	Модель для оценочной  проверки выбранной архитектуры

 

Условие завершения этапа: подписание сторонами "Постановки Задачи" и "Экономического обоснования".  На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются все требования с ключевыми пользователями. Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза.  Одновременно в виде пошаговых сценариев (use case) пишется "Документация Пользователя", раскрывающая пункты "Постановки Задачи". Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии - должностные инструкции пользователям. Запрещается использование в документации слова "должен", время описания выбирается как неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы "Документация пользователя" играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа.  Возможны два варианта взаимодействия "прототип-документация":

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

2) При отсутствии  представления о лучшем варианте  реализации по краткому заданию  на основе "Постановки Задачи" сначала создается прототип. После  одобрения Заказчиком документируется  желаемое поведение системы. Пользователь оценивает прототип и документацию одновременно. Если, осмотрев прототип, пользователь согласен с описанием поведения конечной системы в "Документации Пользователя", осуществляется переход к созданию прототипа следующего функционального модуля. Как отмечено выше, "Документация" фактически заменяет классическое ТЗ,. таким образом на лицо ряд преимуществ:

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

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

Как правило, заботятся  в первую очередь о ТЗ, обычно документация далеко отстает от текущего состояния программы. В данном случае этого не наблюдается.

Степень Важности	Продукт этапа	Описание продукта
1	Прототип всей системы	Прототип системы - это  набор прототипов проверяющий не менее 80% пользовательских и архитектурных решений. Все прототипы должны быть приняты Заказчиком.
2	Документация (ТЗ)	Должны быть составлены и  одобрены сценарии не менее 80% поведения  конечной Системы.

 
Условие завершения этапа: этап завершается  письменным соглашением Заказчика  и Исполнителя о том, что конечная система будет принята, если соответствует  последней согласованной версии "Документации Пользователя"; архитектура  и требования стабильны, не предвидится  изменений более чем на 20% в  ходе следующего этапа.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 Заключение

 

                Широкое применение методика планирования работ на основе проекта получила в строительстве. Например, для управления проектом сооружения гидроэлектростанции на реке Черчилль в Ньюфаундленде (полуостров Лабрадор). Стоимость проекта составила 950 млн. долларов. Гидроэлектростанция строилась с 1977 по 1986 г. Этот проект включал более 100 строительных контрактов, причем стоимость некоторых из них достигала 76 млн. долларов. В 1984 году ход работ по проекту опережал расписание на 18 месяцев и укладывался в плановую оценку затрат.