Лучший выход состоит в том, чтобы руководствоваться ожидаемой выгодой при решении, на какое количество рисков отважиться. В ретроспективе, главной причиной того, что мы раньше этого не делали, была нехватка дисциплины, чтобы заставить количественно оценить выгоду. В особенности по не очень выгодным проектам, мы стойко отказывались количественно оценить выгоду, поскольку это было единственным способом сохранять сколько-нибудь приличный вид всей затеи. Без объявленных ожиданий стоимости можно было опираться только на сокращение расходов на разработку. Обоснование преимущественно было таким: «Мы так снизим затраты, что они наверняка будут меньше, чем любая полученная выгода».
Реальное обоснование проекта (вы всегда знали это в глубине сердца) требует сбалансированности риска и выгоды, как показано на рисунке:
Здесь есть техническая проблема: как решить, перевешивает ли выгода, показанная на левой стороне, риски, показанные справа. Поскольку и выгода, и риски являются до некоторой степени неопределенными, следует ожидать, что и баланс тоже будет в некоторой степени неопределенным. Если призвать на помощь сложную математику, то получим диаграмму неопределенности, показывающую одновременное воздействие неопределенной выгоды и неопределенного риска. Однако без вычислений наилучшим подспорьем является симуляция с помощью RISKOLOGY, показывающая чистую выгоду для ряда из 100 смоделированных проектов. Система дает гистограмму, которую можно аппроксимировать гладкой кривой, как показано на этом рисунке:
Глава 22
Уточнение правил управления рисками
Вернемся к правилам, впервые изложенным в главе 10, чтобы добавить некоторые уточнения. Начнем здесь с пересмотра первого раздела этой главы «Что понимают под управлением рисками».
Управление рисками по сути представляет собой осуществление следующих шагов, включаемых в проект (пункты 6-12 включают больше всего изменений по сравнению со списком в главе 10, но мы, конечно, рассмотрим заново весь процесс):
1. Используйте процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту
2. Убедитесь, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.
3. Проведите всю указанную предварительную подготовку по каждому из рисков:
• Дайте наименование риску и присвойте ему уникальный номер.
• Проведите мозговой штурм для выявления показателей наступления события риска.
• Оцените влияние наступления риска на стоимость и расписание проекта.
• Оцените вероятность наступления риска.
• Рассчитайте подверженность риску в терминах расписания и бюджета.
• Определите заранее, какие меры придется принять, если и когда событие риска наступит.
• Определите, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включите действия по ослаблению риска в обший план проекта.
• Опишите все детали в специальной форме, шаблон которой приведен в Приложении Б.
4. Укажите возможные риски-катастрофы как исходные допущения проекта. Разработайте схему делегирования управления каждым из таких рисков вышестоящему руководству.
5. Сделайте первый подход к оценке расписания, исходя из предположения, что
6. Скачайте RISKOLOGY (см.. Введите параметры своего проекта в главную рабочую таблицу. Там же введите все индивидуальные настройки, какие сможете найти, опираясь на имеющиеся у вас записи о предшествующей деятельности вашей компании. Замените как можно больше общеотраслевых, заложенных в имитаторе, данных относительно главных рисков имеющейся у вас достоверной информацией. Добавьте индивидуально настроенные рабочие таблицы для всех второстепенных рисков, которые вы отслеживаете. Проведите моделирование для получения диаграммы риска для вашего проекта, добиваясь пересечения с вашей нанопроцентной датой.
7. Выразите, используя диаграмму риска, все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом. Вместо того чтобы объяснять концепцию диаграмм риска любому из не самых сообразительных заказчиков, отнеситесь к ней как к моделированию своего проекта, сделайте 500 прогонов, показывая все возможные результаты и сравнительную вероятность каждого.