Риск характеризуется главным образом двумя факторами.

• Вероятность риска — это вероятность того, что событие действительно произойдет. Для оценки ее величины можно использовать простую процентную шкалу (0-100). Только риск с оценкой вероятности больше 0% представляет опасность для проекта. Риски с вероятностью 100% уже реализовались; другими словами, это известные проблемы. Группа может найти более эффективным такой подход, при котором используются от 1 до 3 точек на этой

шкале, соответствующие 25, 50 и 75%, потому что иногда несущественное различие в оценках вероятности— например, 60% или 70% — вызывает лишние споры.

• Влияние риска— влияние риска отражает степень важности неблагоприятных последствий реализации риска. Измерить эти потери непросто. Если риск имеет финансовый характер, группа может оценивать потери в денежном выражении: это долгосрочные затраты на эксплуатацию и сопровождение, потеря части рынка, краткосрочные затраты на дополнительную работу или упущенные возможности. Когда финансовые последствия оценены, их величину можно классифицировать по пятибалльной шкале, где 5 будет означать самый большие потери. Иногда риски таковы, что их последствия удается оценить только субъективно (скажем, от Iдо 5). Эта шкала, по существу, оценивает шансы на успех проекта:

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

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

• идентификатор— название, уникально идентифицирующее формулировку риска (идентификаторы понадобятся для отслеживания и отчетности);

• источник — источник может быть идентифицирован по предметной области , по категории или по фактору (соответствие проекта требованиям заказчика, стабильность организации );

• условия возникновения — описание условий, в которых риск может реализоваться и поставить проект под удар;

• вероятность— оценка вероятности реализации риска. Вероятность обычно выражается значениями от 1 до 3, представляющими величины в процентах (25. 50 и 75% соответственно);

• последствия— оценка последствий реализации риска для проекта; может быть выражена в денежном эквиваленте или числом по 5- балльной шкале,

• влияние — сводная количественная оценка риска, равная произведению его вероятности на количественную оценку его последствий. Заметим, что для ранжирования все оценки влияния рисков надо выражать в одних и тех же единицах;

•описание контекста— дополнительная информация, проясняющая ситуацию, в которой риск может реализоваться;

• связанные риски— перечень идентификаторов рисков, связанных с данным; этот список полезен для выявления связанных и независимых рисков.

Проранжировав риски по степени влияния, группа может заняться стратегией управления рисками и включением планов действий на случай реализации рисков в концепцию проекта. Поскольку управление рисками требует времени и усилий, ключевым моментом является идентификация ограниченного числа основных рисков, которые надо постоянно отслеживать. Простой, но эффективный прием —выявить десять основных рисков проекта. Эту «горячую десятку» должны одобрить все участники проекта. Дополнительный перечень важных рисков нужно включить в концепцию проекта (документ, созданный на стадии «Анализ») и в основной план проекта, который создается на стадии планирования.

2.5. ---------------------шаг 3 -Планирование риска

На стадии планирования вырабатываются действия, которые необходимо предпринять в отношении отдельных рисков, определяются приоритеты этих действий и создается общий план управления рисками, который образует основу сводного документа оценки рисков, являющегося обязательным результатом этапа «Одобрение концепции».

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

• Исследование — достаточно ли информации об этом риске? Требуется ли дальнейшее изучение ситуации, чтобы собрать больше информации и прояснить все характеристики риска прежде, чем вырабатывать план действий?

• Приемлемость — может ли группа игнорировать последствия риска и не предпринимать никаких действий?

• Управление — может ли группа сделать что-нибудь, чтобы снизить воздействие риска, если он реализуется?

• Возможность избежать проблемы — можно ли избежать риска, изменив продукт?

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

• снизить вероятность возникновения риска;

• уменьшить размеры потерь;

• изменить последствия риска.

Чтобы снизить риски, управление которыми находится в компетенции группы, надо применить ресурсы, необходимые для этого. Если же риск находится вне компетенции группы, стоит поискать обходные пути. Эффективными могут оказаться:

• переход на другое аппаратное обеспечение;

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

систему, которая лучше приспособлена для решения этих задач;

• передача контракта более квалифицированному подрядчику.

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

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

• идентификатор риска — уникальное имя, к- идентифицирует формулировку риска и используется для отчетов и отслеживания;

• формулировка риска — описание условий реализации риска, а также потерь, которые возможны в этом случае;

• стратегия управления риском — описание стратегии управления риском, включая все допущения;

• метрики стратегии управления рисками — параметры, позволяющие оценить, работает ли стратегия:

• вероятность— оценка вероятности реализации риска; обычно выражается значениями от 1 до 3, представляющими величины в процентах (25, 50 и 75% соответственно):

• последствия — оценка последствий реализации риска для проекта; может выражаться в денежном эквиваленте или числом

по 5-балльной шкале, которое показывает относительную важность этой проблемы;

• влияние — сводная количественная оценка риска, равная произведению его вероятности на количественную оценку его по-

следствий;

• действия — действия по управлению риском; все предпринятые действия должны регистрироваться системой отслеживания рисков;

• сроки — даты, к которым группа должны закончить выполнение этапов;

• ответственные — лица, ответственные за перечисленные действия;

• чрезвычайная стратегия — краткое описание плана действий на

случай, если намеченный план не справится с риском;

• «пороговые значения» и параметры чрезвычайных стратегий — служат для принятия решения.

2.6. -------------шаг 4 Управление рисками!!!!

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

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

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

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

Отчет о статусе риска может идентифицировать 4 возможных ситуации в управлении риском:

• риск устранен, план действий выполнен;

• действия происходят по плану, реализация плана продолжается;

• действия идут не по плану, следует принять корректирующие меры или ввести в действие чрезвычайный план;

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

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

2.7--------------------Шаг 5: контроль рисков

включает:

• контроль планов действий на случай реализации риска;

• корректировку отклонения от плана;

• реакцию на достижение «пороговых значений»;

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

3.Этап «Одобрение концепции» и его результаты

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

На этом этапе заказчик и проектная группа согласуют основные вопросы проекта.

Для достижения этого этапа необходимы четыре документа:

• «Концепция», где описан разрабатываемый продукт, решаемые им задачи, его характеристики и предварительный график;

• прототип приложения, который послужит иллюстрацией плана

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

• «Структура проекта», где описаны распределение ролей в проектной группе и области ответственности каждой роли;

• «Основной документ оценки рисков», где перечислены риски проекта и описаны методы управления ими.

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

Все основные этапы модели процесса разработки MSF означают достижение согласия между заказчиком, проектной группой и осталь­ными ключевыми участниками проекта. Достижение этапа «Одобре­ние концепции» означает достижение согласия по вопросам, пере­численным в следующей таблице:

\

Этап «Одобрение концепции» предоставляет заказчикам и проектной команде достаточно информации для принятия важного решения — следует ли продолжать выполнение проекта. В принципе, после рассмотрения результатов фазы «Анализ» и концепции продукта

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

3.1Концепция

Документ, описывающий концепцию, должен включать, по крайней мере:

•формулировку концепции;

• результаты исследования требований пользователей;

• информацию о конкурентоспособности решения;

• описание функциональных возможностей;

• приблизительный график.

--------------Формулировка концепции

Это высказывание иллюстрирует принципы формулирования концепции:

• конкретность;

• измеримость;

• достижимость;

• важность;

• наличие четко указанных сроков.

-------------Результаты исследования требований пользователей

Информация, полученная от заказчика и пользователей, является

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

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

-----------------Конкурентоспособность

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

---------------Наборы функциональных возможностей

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

----------------Приоритеты и график

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

3.2.Прототип

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

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