Для того чтобы начать составление списка рисков (на начальном этапе):

Соберите коллектив разработки вместе (на этом этапе он должен быть небольшим; если он насчитывает больше 5-7 человек, то оценка рисков выполняется только лидерами групп).

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

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

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

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

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

В качестве основы обсуждения можно взять какой-либо базовый список рисков, например Assessment and Control of Software Risks (автор - Capers Jones) [JON94] либо the Taxonomy-Based Risk Identification, созданный Институтом разработки программного обеспечения [CAR93]. Передавайте список по кругу: уже названные риски могут навести участников на мысль о других.

Для того чтобы обновить список рисков (на более поздних этапах):

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

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

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

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

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

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

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

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

1. Большой
2. Значительный
3. Умеренный
4. Небольшой
5. Малый

Составьте документацию с описанием рисков и распространите ее среди участников проекта.

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

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

Наконец, риск можно передать другой организации.

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

Существуют риски, для реализации либо отмены которых необходимо выполнить некоторые действия. Действия второго рода необходимо выполнить на ранних итерациях процесса разработки. Постарайтесь преодолеть риск при первой возможности. Если риск сформулирован в форме "X может работать неправильно?", следует проверить работу X как можно скорее.

Примеры:

• Для того чтобы уменьшить риск несовместимости продуктов X и Y, будет создан прототип, позволяющий оценить сложность их интеграции. Для проверки успешности интеграции будут протестированы следующие параметры (составьте список параметров).
• Для того чтобы уменьшить риск неправильной работы базы данных A, эта база данных будет проверена в ходе нескольких тестов, моделирующих нагрузку от приложения.
• Для того чтобы уменьшить риск неудачного возвратного тестирования приложения с помощью утилиты Z,мы приобретем и используем ее на следующей итерации.

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

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

В резервном плане должны быть учтены:

Определите индикаторы рисков

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

• Объем работ, которые необходимо переделать, остается слишком высоким
• Количество непригодных продуктов остается слишком высоким
• Фактические затраты намного превышают запланированные

Некоторые риски можно отслеживать, основываясь на требованиях и результатах тестирования проекта, например:

• Время ответа системы на порядок превосходит требуемое

Некоторые риски связаны с конкретными событиями, например:

• Программные компоненты не были выпущены третьей стороной вовремя.

Существует множество других, менее четких индикаторов, которые не позволяют однозначно определить возникновение проблемы. Например, всегда существует риск ухудшения морального состояния в коллективе (на некоторых этапах проекта это происходит довольно часто). Существуют несколько индикаторов: ворчание, "юмор висельника", не выполненные сроки, низкое качество и прочее. Ни один из этих показателей не является однозначным индикатором; например, шутки о невозможности выполнения выпуска вовремя могут являться нормальным способом снятия стресса, но если они продолжаются, это может означать, что коллектив предчувствует надвигающийся провал.

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

Определите действия на случай неудачи, или "план B".

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

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

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

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

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

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

При завершении итерации сформулируйте цели следующей итерации с учетом списка рисков. В частности:

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

Не беспокойтесь, если список рисков увеличивается в ходе начального этапа и этапа уточнения. Участники проекта, выполняя свою работу, осознают, что некоторые казавшиеся тривиальными действия также подразумевают риски. В ходе интеграции продуктов могут проявиться ранее скрытые затруднения. Опасность рисков должна неуклонно уменьшаться в ходе завершения этапа уточнения и в течение всего этапа построения. Если этого не происходит, возможно, рискам не уделяется достаточно внимания, или система является слишком сложной, или построить систематическую стратегию работы с рисками для данной системы невозможно. Дополнительная информация содержится в документе Рекомендация по рабочему продукту: Список рисков.