2. Содержание тренинга
• Что такое риск
• Предмет управления рисками
• Идентификация и оценка рисков
• Стратегии управления рисками
• Процесс управления рисками
3. Что такое риск?
• Что такое риск?
• Почему и когда мы рискуем?
• Почему мы не рискуем?
• Почему мы пренебрегаем риском?
5. Что такое риск?
Риск – это событие, которое может произойти в ходе
проекта, и таким образом повлиять на исход проекта.
Риск связан с неопределенностью.
Риск имеет вероятность.
8. Идентификация рисков – примеры из Project Plans
• Wrong stored procedures, i.e. some procedure works incorrectly.
• Send bug report and wait for answer
• Requirements are defined vaguely and as clarified they become inconsistent (or contradictory)
• Provide to the customer our understanding of requirements wherever they seem to be unclear. Provide
interim versions of the application for customer evaluation
• Customer response to project related inquiries is too slow
• Ask customer beforehand to have enough time to get an answer
• The overall project estimates are wrong
• Review estimates on a regular basis and take corrective actions (find “shortcuts”, change priorities, add
resources, reduce functionality)
• Split the project in short iterations and update the estimates (as well as the requirements) before each
iteration
• The team will not be able to support the existing Oracle database due to the lack of knowledge.
• The team velocity can be low than expected.
• Increase the team size. Allocate 6 developers instead of 4 required and 3 testers instead of 2 required.
• The total effort required for open tasks is tool little to workload the entire team
• Probability - 5%, Impact - Immeasurable
• Let the team do some research for future projects. Or let them study new techs.
9. Идентификация рисков
• Как должен быть сформулирован риск:
o Понятная проблема
o Понятное влияние на проект
o Понятные способы решения проблемы
• В нашем случае практически всегда риски негативно влияют
на …
• Почему про некоторые риски забывают:
• Не хватает опыта или данных для идентификации
проблемы
• Невозможно или сложно измерить влияние риска на
проект
• Не ясны пути решения проблемы
10. Типичные источники рисков
• Требования
• Технологии и средства разработки
• Программный код и другие проектные артефакты
• Процесс разработки
• Окружение
• Человеческий фактор
11. Чеклист по управлению рисками I
• Регулярно пересматривайте матрицу рисков
• Привлекайте членов команды для анализа и оценки
рисков
• События происходят не так, как вы задумали. Надежда
на это – плохой план.
• Что если из проекта уйдет кто-то из членов команды?
• Что если ключевой дедлайн будет перемещен на более
раннее время?
• Анализируйте критический путь проекта.
12. Чеклист для поиска рисков II
• Какие аспекты проекта новы для вашей команды?
• Было ли у вас достаточно времени на
планирование?
• Есть ли риск что результаты проекта не будут
приняты клиентом?
• Есть ли зависимости от других команд, организаций,
сторонних продуктов?
• Возможно ли что цели проекта изменятся?
• У вас нет замены для ключевой фигуры/части
проекта.
• Интеграция подсистем, подпроектов – это источник
рисков.
• Вы четко понимаете цель проекта?
13. Оценка риска
• Выбрать метрику и пороговое значение
• Спрогнозировать ее значения в ходе проекта
• Определить размер потерь для пессимистичного варианта
(Risk Impact - RI)
• Рассчитать Risk Probability (RP) как вероятность перехода
через пороговое значение
• Расcчитать Risk Exposure как произведение Risk Impact и Risk
Probability
14. Метрики рисков
• Риск – трудности с использованием сторонней компоненты, что
приведет к высоким трудозатратам, соизмеримым на
самостоятельную разработку функциональности компоненты. (10
ч-дней)
• Метрика: средние трудозатраты на интеграцию компоненты
• Оптимистичный вариант: 1 ч.-день
• Реалистичный вариант: 4 ч.-дней
• Пессимистичный вариант: 14 ч.-дней (если через 4 дня поймем,
что надо писать самим)
• Transition Threshold: 4 ч.-дня
• Потери в пессимистичном случае: 10 ч.-дней
• Risk Probability: Средняя - 30%
• Risk Exposure: 3 ч-дня
15. Какие метрики можно подобрать?
• Риск – болезнь членов команды
• Риск – много ошибок
16. Метрики из упражнения 1
Текущий процент заболевших в компании
Отношение времени на bug-fixing ко времени
реализации функциональности
17. Как оценить вероятность?
Хороший подход – на основе вербальных оценок, связанных с
конкретными числами.
• Критическая 95% – 80%
• Максимальная 80% – 60%
• Высокая 60% – 40%
• Средняя 40% – 30%
• Малая 30% – 20%
• Минимальная 20% – 10%
Или
• Очень высокая (Very high) 80%
• Высокая (High) 60%
• Средняя (Medium) 40%
• Низкая (Low) 20%
18. Каким рискам нужно уделить больше внимания?
Приоритизация должда базироваться на common sense
Приоритизация по принципу Impact - Probability:
• High - High
• High – Low
• Low - High
• Low – Low
Приоритизация по Risk Exposure:
• Risk Exposure = Impact * Probability
19. Что дальше?
• Mitigate – смягчать
A.Совершать предварительные действия до материализации риска для снижения размера
возможных потерь
B.Планировать действия по борьбе с последствиями в случае материализации риска для
снижения размера фактических потерь
• Accept – принять
• Счесть допустимым и не закладывать резервов в бюджет
• Avoid – избегать
• тем или иным способом избавиться от источников риска
• Contain – включать в резерв
• Резервировать средства в бюджете в размере ожидаемых потерь в случае материализации
риска
• Transfer –
• Резервировать средства в бюджете в размере ожидаемых потерь в случае материализации
риска
20. Возможности
• Exploit
• Убрать неопределенность, так чтобы событие точно
произошло. Обратное к Avoid.
• Share
• Постараться выжать максимум из возможности для всех
вовлеченных сторон.
• Enhance
• Opposite to mitigate. Do all possible actions
• Accept
• Принять. Случится – хорошо. Не случиться – ничего
страшного.
21. Как выбрать стратегию?
Стоимость стратегии:
V = VA + RP * (VB + VC) = VA + RP * VB + RE
здесь:
VA – стоимость превентивных мер
VB – стоимость мер по борьбе с последствиями
VC – стоимость понесенных потерь
RP – вероятность риска (Risk Probability)
RE – средние ожидаемые потери (Risk Exposure)
Для стратегии Contain: V = Risk Exposure
22. Пример рассчета стратегии
• Риск – трудности с использованием сторонней компоненты, что
приведет к высоким трудозатратам, соизмеримым на
самостоятельную разработку функциональности компоненты. (10
ч-дней)
• Стратегия Mitigate – создание прототипа. 2 ч-дня. Тем самым
мы перейдем от пессимистичного варианта к оптимистичному и
сэкономим 3 дня.
• VA + RP * (VB + VC) = 2+0,3*(10+1) = 5,3 ч-дней.
• Стратегия Avoid – сразу начать писать самим. В этом случае
риск пропадает (VB и VC=0).
• VA + RP * (VB + VC) = 10 ч-дней.
23. Risk Assessment Form
• ID – уникальный идентификатор риска
• Date – дата выявления риска
• Description – описание риска
• Affected milestone
• Probability – вероятность наступления негативных последствий
• Impact – дополнительный effort, необходимый для преодоления негативных
последствий
• Exposure – среднеожидаемые потери
• Mitigation plan – стратегия смягчения риска и потерь
• Responsible – лицо, ответственное за выполнение Mitigation plan
• Close date – дата успешного завершения плана
24. Управление рисками по ходу проекта
• Регулярный сбор метрик
• Регулярный анализ ситуации и корректировка
параметров рисков
• Реализация задач Mitigation A согласно основному
плану проекта
• Включение задач Mitigation B в план, как только
«сработал» Transition Indicator
• Регулярная идентификация новых рисков
Каковы ваши ответы на эти вопросы? Выписать на доске.
Практически все, что мы делаем (например, открываем холодильник, чтобы взять масла для бутерброда), связано с тем или иным риском ( в данном случае есть риск поражения током. Последствия – ожоговая травма или даже смерть, однако вероятность этого события крайне мала. Тем не менее, производители холодильников предпринимают множество усилий для того, чтобы описанного кейза не произошло. J ).
Люди думают что контролируют все события.
Но это не так. Есть события, которые априори находятс я вне нашего контроля.
Каковы ваши ответы на эти вопросы? Выписать на доске.
Практически все, что мы делаем (например, открываем холодильник, чтобы взять масла для бутерброда), связано с тем или иным риском ( в данном случае есть риск поражения током. Последствия – ожоговая травма или даже смерть, однако вероятность этого события крайне мала. Тем не менее, производители холодильников предпринимают множество усилий для того, чтобы описанного кейза не произошло. J ).
Люди думают что контролируют все события.
Но это не так. Есть события, которые априори находятс я вне нашего контроля.
Определение риска не утверждает что влияние негативное. Оно может быть и положительным.
Мы как раз и занимаемся рисками, потому что предполагаем их негативное воздействие.
Риск – потенциальная проблема.
Таким образом, управление рисками заключается в том, чтобы перейти от неопределенности и риска к возможностям.
Это определение, оценка и действия по сокращению проектных рисков на протяжении всего проекта и наилучшим для его целей образом.
Проектный риск-менеджмент должен быть про-активным.
Реактивный риск-менеджмент - это уже кризисное управление. Риск наступил. Надо предусмотреть такую возможность заранее. В противном случае - вызывать мистера Вульфа из Pulp Fiction. J
Управление не ради рисков. Управление для уменьшения их негативного влияния на проект и достижение цели проекта. Если вероятность риска ничтожно мала (например, заболели все участники проекта) - отбросьте его!
Рисковать только если выгода от успешного завершения дела больше вероятных потерь в случае провала.
Wrong prototype, i.e. system cannot work in way as customer supposed
Discuss possibility of changing prototype
One developer (1 from 4) is replaced between first and second iterations. This can cause a slow down in team velocity.
Project scope can be reduced
Introduction of the new developer as fast as possible.
Срок
Качество
Бюджет (количество ресурсов)
Мотивация
Провал полностью
Типичные риски.
100% - это уже не риск.
Меньше 5% - закладывать в бюджет.
Exposure может быть одинаковым для High-Low и Low-High рисков, хотя стратегии для них различны.
High – Low – prevention
Low – High – чаще обращать внимание, контролировать
Примеры:
Mitigate – смягчать
Совершать предварительные действия до материализации риска для снижения размера возможных потерь и вероятности его проявления
Планировать действия по борьбе с последствиями в случае материализации риска для снижения размера фактических потерь
Accept – принять
Low impact – High Probability
Avoid – избегать. Убираем источник риска.
Например. Сторонняя компонента. Поискать другую, с которой точно не возникнет проблем.
Или
Contain – включать в резерв
Фактически, включить в план. High probability