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

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

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

Рис. 23-2. Шаблон трассирования элемента риска

В шаблоне предусмотрены поля для записи о вероятности материализации риска в проблему, о негативном влиянии на проект, как результат этой проблемы и об общей подверженности проекта риску. Я оцениваю вероятность по шкале от 0,1 (практически невозможно) до 1,0 (обязательно произойдет), а ущерб — по относительной шкале от 1 (нет проблем) до 10 (полный кошмар). Еще лучше попытаться оценить потенциальное влияние в единицах потерянного времени и денег. Умножьте вероятность на влияние, чтобы оценить уязвимость для каждого элемента риска.

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

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

Рис. 23-3 иллюстрирует фактор риска, который лидеры проекта Chemical Tracking System обсуждали в начале этой главы. Команда оценила вероятность и ущерб на основании своего предыдущего опыта. Но, не оценив другие факторы риска, она не узнает, насколько серьезна подверженность риску с коэффициентом 4,2. Первые два метода минимизации уменьшают вероятность того, что этот риск перейдет в проблему, увеличивая участие пользователей в процессе составления требований. Прототипирование снижает вероятность потенциального ущерба, запрашивая обратную реакцию пользователей по пользовательскому интерфейсу на ранних стадиях проекта.

Рис. 23-3. Пример фактора риска для Chemical Tracking System

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

Список факторов риска — не то же самое, что план управления риском. Для малого проекта вы можете включить свои планы управления риском в план управления проектом разработки ПО. Для большого проекта необходимо написать отдельный план управления риском, формулирующий предполагаемые подходы для выявления, оценки, документирования и учета риска. Этот план должен включать распределение ролей и обязанностей в действиях по управлению риском. Шаблон плана по управлению риском доступен на https://www.processimpact.com/goodies.shtml. Для многих проектов назначается менеджер по управлению риском, который отвечает за все, что может пойти не так. В одной компании такого сотрудника называли «Иа-Иа», в честь печального персонажа из «Винни-Пуха», который постоянно горевал о том, как все может быть плохо.

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