2.3 Качественная оценка рисков
Качественная оценка рисков – процесс представления качественного анализа идентификации рисков и определения рисков, требующих быстрого реагирования. Такая оценка рисков определяет степень важности риска и выбирает способ реагирования. Доступность сопровождающей информации помогает легче расставить приоритеты для разных категорий рисков. Качественная оценка рисков это оценка условий возникновения рисков и определение их воздействия на проект стандартными методами и средствами. Использование этих средств помогает частично избежать неопределенности, которые часто встречаются в проекте. В течение жизненного цикла проекта должна происходить постоянная переоценка рисков.
2.4 Количественная оценка рисков
Количественная оценка рисков определяет вероятность возникновения рисков и влияние последствий рисков на проект, что помогает группе управления проектами верно принимать решения и избегать неопределенностей. Количественная оценка рисков позволяет определять:
· Вероятность достижения конечной цели проекта
· Степень воздействия риска на проект и объемы непредвиденных затрат и материалов, которые могут понадобиться.
· Риски, требующие скорейшего реагирования и большего внимания, а также влияние их последствий на проект.
· Фактические затраты, предполагаемые сроки окончания.
Количественная оценка рисков часто сопровождает качественную оценку и также требует процесс идентификации рисков. Количественная и количественная оценка рисков могут использоваться по отдельности или вместе, в зависимости от располагаемого времени и бюджета, необходимости в количественной или качественной оценке рисков.
2.5 Планирование реагирования на риски
Планирование реагирования на риски - это разработка методов и технологий снижения отрицательного воздействия рисков на проект. Берет на себя ответственность за эффективность защиты проекта от воздействия на него рисков. Планирование включает в себя идентификацию и распределение каждого риска по категориям. Эффективность разработки реагирования прямо определит, будут ли последствия воздействие риска на проект положительными или отрицательными.
Стратегия планирования реагирования должна соответствовать типам рисков, рентабельности ресурсов и временным параметрам. Вопросы, обсуждаемые во время встреч, должны быть адекватны задачам на каждой стадии проекта, и согласованы со всеми членами группы по управлению проектом. Обычно требуются несколько вариантов стратегий реагирования на риски.
Мониторинг и контроль следят за идентификацией рисков, определяют остаточные риски, обеспечивают выполнение плана рисков и оценивают его эффективность с учетом понижения риска. Показатели рисков, связанные с осуществлением условий выполнения плана фиксируются. Мониторинг и контроль сопровождает процесс внедрения проекта в жизнь.
Качественный контроль выполнения проекта предоставляет информацию, помогающую принимать эффективные решения для предотвращения возникновений рисков. Для предоставления полной информации о выполнении проекта необходимо взаимодействие между всеми менеджерами проекта.
Целью мониторинга и контроля является выяснить, было ли:
· Система реагирования на риски внедрена в соответствии с планом
· Реагирование достаточно эффективно или необходимы изменения
· Риски изменились по сравнению с предыдущим значением
· Наступление влияния рисков
· Необходимые меры приняты
· Воздействие рисков оказалось запланированным или явилось случайным результатом.
Контроль может повлечь за собой выбор альтернативных стратегий, принятие корректив, перепланировку проекта для достижения базового плана. Между менеджерами проекта и группой риска должно быть постоянное взаимодействие, должны фиксироваться все изменения и явления. Отчеты по выполнению проекта должны формироваться регулярно.
Глава 3. Методика управления проектом
Существуют различные методики управления проектами В данном курсе мы будем придерживаться методики «Мягкого внедрения» ведения проекта. Это методики мягкого и жесткого внедрения.
Внедрение - внедрение в условиях взаимного доверия Заказчика и Исполнителя, при котором проблемы и ошибки Заказчика берет на себя большей частью Исполнитель.
Жесткое внедрение - внедрение в условиях жесткого формального управления, пониженного доверия и повышенной ответственности Заказчика и Исполнителя. Жесткое внедрение обычно является следствием сильных политических рисков
Данная технология разработки и внедрения имеет следующие проверенные границы применимости:
· Рассчитано на взаимное доверие Заказчика и Исполнителя в пределах не менее одного этапа работ, имеется в виду, что Заказчик или Исполнитель могут блокировать проект, но не более чем в рамках этапа.
· Оптимально для проектов сроком до 3х месяцев и трудоемкостью до 1 чел/года. Для изготовления более сложной системы, необходимо, чтобы ее отдельные модули внедрялись не дольше 3х месяцев, в противном случае методика не применима.
· Учет модели ценообразования. Данная методика разработана с учетом рискованного для Исполнителя и выгодного для Заказчика "ценообразования за весь проект". Это не исключает возможность применения более простой расчетной схемы повременного типа.
· Заказчик готов заплатить больше, но за результат, а не за усилия (время) Исполнителя. Покупка проекта, а не времени Исполнителя позволяет Заказчику снять с себя значительную часть ответственности за свои проблемы и ошибки.
· Ключевые пользователи Заказчика не является специалистами в информационных системах. Заказчик предпочитает работать не с формальной спецификацией, а с документацией пользователя и моделями системы.
· Методика применима для небольших заказных и серийных систем.
Данный этап проводится по договору о консалтинге, т.е. оплата этапа повременная. В виду неопределенности задачи спланировать заранее ее стоимость невозможно. Себестоимость этапа примерно равна 10% себестоимости всех работ.
Основной продукт этапа - документ "Постановка Задачи" (Product Vision).
Данный документ должен определять цель проекта и включать в себя список ключевых требований без подробной расшифровки. Важный критерий: несмотря на отсутствие подробного описания, список должен поддаваться статистической оценке трудоемкости со стандартным отклонением (риском) в приемлемых рамках.
На основе "Постановки Задачи" требуется составить документ "Экономическое обоснование".
Данный документ должен содержать статистическую оценку трудоемкости (себестоимости) работ. С другой стороны, должен быть сделан анализ экономического эффекта от внедрения.
При анализе используется статистика трудоемкости (эффективности) аналогичных проектов. При отсутствии данной статистики неизбежны ошибки в оценках причем на порядок, в данном случае следует попробовать получить статистику опираясь на результаты разработки/демонстрации прототипов.
Для оценки рисков требуется разработать как минимум 2 простейших прототипа (они могут быть выполнены как один).
"Интерфейсный прототип" - это прототип, имитирующий 1-2 важнейших диалоговых окна программы. Необходимо проанализировать реакцию пользователей с целью изучения рисков связанных с модификацией их требований.
"Архитектурный прототип" - это прототип, проверяющий самые критические места будущей архитектуры. Данный прототип служит для оценки технологических рисков.
Данные прототипы не должны далее использоваться при разработке системы, требуется начать разработку заново. Это связано с тем, что прототипы служат для нахождения оптимальных решений, но таковыми не являются.
Оценку рисков требуется выразить в виде возможного превышения трудоемкости (пессимистичная оценка). Именно из данной оценки следует исходить при определении общей трудоемкости (цены) продукта.
В результате мы имеем нечетко сформулированное задание "Постановка Задачи" и оценку стоимости в "Экономическом обосновании". Риски от нечеткости требований должны быть покрыты пессимистичной оценкой. С точки зрения юридического договора "Постановка Задачи" может играть роль ТЗ, но с указанием в договоре на то, что более приоритетный документ "Документация пользователя" (см. ниже) и система будет приниматься по "Приемочным испытаниям" (см. также ниже)
Степень Важности | Продукт этапа | Описание продукта |
1 | Постановка Задачи | Цель проекта. Список ключевых требований без подробной расшифровки |
2 | Экономическое обоснование | Оценка экономического эффекта и себестоимости проекта. |
3 | Интерфейсный прототип | Модель одного из ключевых интерфейсов пользователя |
4 | Архитектурный прототип | Модель для оценочной проверки выбранной архитектуры |
Условие завершения этапа: подписание сторонами "Постановки Задачи" и "Экономического обоснования".
На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются все требования с ключевыми пользователями. Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза.
Одновременно в виде пошаговых сценариев (use case) пишется "Документация Пользователя", раскрывающая пункты "Постановки Задачи". Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии - должностные инструкции пользователям. Запрещается использование в документации слова "должен", время описания выбирается как неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы "Документация пользователя" играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа.
Возможны два варианта взаимодействия "прототип-документация":
1) При относительно четком представлении о функциональности до разработки очередного прототипа должны быть готовы основные пункты "Документации", описывающие его работу. В данном случае "Документация" одновременно играет роль нечеткой спецификации на прототип. Нечеткость заключается в том, что "Документация" может быть исправлена с целью соответствия реализации в прототипе, если прототип реализовал удачное, но не документированное решение.
2) При отсутствии представления о лучшем варианте реализации по краткому заданию на основе "Постановки Задачи" сначала создается прототип. После одобрения Заказчиком документируется желаемое поведение системы.
Пользователь оценивает прототип и документацию одновременно. Если, осмотрев прототип, пользователь согласен с описанием поведения конечной системы в "Документации Пользователя", осуществляется переход к созданию прототипа следующего функционального модуля.
Как отмечено выше, "Документация" фактически заменяет классическое ТЗ,. таким образом на лицо ряд преимуществ:
1. Описание программы делается на языке, понятном пользователю.
2. Уже на первых этапах разработки программы пользователь включается в анализ своей рабочей документации.
3. Нет необходимости править ТЗ и Документацию одновременно.
4. Как правило, заботятся в первую очередь о ТЗ, обычно документация далеко отстает от текущего состояния программы. В данном случае этого не наблюдается.
Степень Важности | Продукт этапа | Описание продукта |
1 | Прототип всей системы | Прототип системы - это набор прототипов проверяющий не менее 80% пользовательских и архитектурных решений. Все прототипы должны быть приняты Заказчиком. |
2 | Документация (ТЗ) | Должны быть составлены и одобрены сценарии не менее 80% поведения конечной Системы. |
Условие завершения этапа: этап завершается письменным соглашением Заказчика и Исполнителя о том, что конечная система будет принята, если соответствует последней согласованной версии "Документации Пользователя"; архитектура и требования стабильны, не предвидится изменений более чем на 20% в ходе следующего этапа.
Важное замечание о юридической стороне. Вполне возможно, что не удается достигнуть согласия ключевых пользователей с прототипом или описанием в Документации. В данном случае Заказчик должен принять волевое решение на уровне топ-менеджера и определиться с требованиями. Если этого не происходит, или если требования выходят за рамки "Постановки задачи" с учетом надбавок на риск, рекомендуется пересмотреть трудоемкость/цену проекта или прекратить его. Указанная возможность прекращения проекта должна быть предусмотрена в договоре.
Заключение
Широкое применение методика планирования работ на основе проекта получила в строительстве. Например, для управления проектом сооружения гидроэлектростанции на реке Черчилль в Ньюфаундленде (полуостров Лабрадор). Стоимость проекта составила 950 млн. долларов. Гидроэлектростанция строилась с 1977 по 1986 г. Этот проект включал более 100 строительных контрактов, причем стоимость некоторых из них достигала 76 млн. долларов. В 1984 году ход работ по проекту опережал расписание на 18 месяцев и укладывался в плановую оценку затрат.
По существу, значительный выигрыш по времени образовался от применения точных математических методов в управлении сложными комплексами работ, что стало возможным благодаря развитию вычислительной техники.
В настоящее время в Америке уже сложились глубокие традиции использования систем управления проектами во многих областях жизнедеятельности. Применение системы управления проектами на практике может быть эффективным и для очень небольших проектов, так как, основную долю среди планируемых проектов составляют именно небольшие по размерам проекты.
... с ее бизнес- деятельностью, имеет (или даже может себе позволить иметь) в своем штате подобных специалистов. Такая услуга, как предоставление персонала управления проектами (менеджеров проектов), достаточно широко распространена в мире. Не является она чем-то экзотическим и в России. К важнейшим элементам, влияющим на развитие и формирование данного сегмента рынка, относятся обучающие курсы и ...
... и, по необходимости, актуализации плановых решений. Стабильности Стабильность планирования обеспечивается неизменностью основных целей и ограничений проекта, его жизнеспособностью, а также гибкостью и адаптивностью системы. 2. Процессы планирования Процессы планирования включают подпроцессы (задачи), которые по степени важности можно разделить на основные и вспомогательные. Основные ...
... роста, а также понимание необходимости расширения услуг, ассортимента и возможностей дальнейшего развития данного вида бизнеса, выездное ресторанное обслуживание имеет все предпосылки для бурного развития. Глава II. Анализ и оценка актуальности кейтеринг-проекта в г.Сибай. Представление проекта «Обеды в офис» 2.1 Анализ и оценка актуальности кейтеринг-проекта в г.Сибай Для того чтобы ...
... критичными. Там, где сроки выполнения проекта серьезно затягиваются, весьма вероятными последствиями являются перерасход средств и недостаточно высокое качество работ. Поэтому, в большинстве методов управления проектами основной акцент делается на календарном планировании работ и контроле за соблюдением календарного графика. Жизненный цикл проекта. Любой проект проходит через определенные фазы ...
0 комментариев