«Управление рисками: основы, теория, практика»

2. УПРАВЛЕНИЕ РИСКАМИ:
основы, теория, практика
Юлия Корытко, Project Manager, DataArt

3. 3

4. 4
Риск проекта - всякое событие или условие, которое может оказать как негативное, так
и позитивное влияние на итоги проекта.
Риск – это всегда вероятностное событие
Превентивная работа над рисками
Риски есть всегда
Непрерывное управление рисками
Выявление рисков нужно одобрять

5. 5
Цель управления рисками – минимизировать убытки и максимизировать возможности
Управление рисками включает:
 Идентификацию рисков
 Оценка рисков
 Планирование
 Мониторинг и контроль

6. 6
1. Идентификация рисков
Чтобыидентифицироватьриск, нужно сначала идентифицироватьцель
Удобно формулировать риски в виде «Причина – Событие - Эффект»
Objective – to travel by train from A to B for a meeting at a certain time
Failure to get from A to B on time for the
meeting
This is simple converse
of the objective
Being late and missing the meeting
This is the statement of the
impact of the risk, not the risk
itself

7. 7
Objective – to travel by train from A to B for a meeting at a certain time
There is no bullet on the train so I get hungry
This does not impact on achievement of
the objective
Missing the train causes me to be late and miss the
meeting
This is a risk which can be controlled by making sure
I allow plenty of time to get to the station
Severe weather prevents the train from running and me
from getting to the meeting
This is a risk which I cannot control, but against
which I can make a contingency plan

8. 8
Идентификация рисков
1. Development estimate is not accurate due to absence of
detailed requirements
2. New Year holidays in different countries interfere with
project timeline
3. Different time zones of project team reduces
communication overlaps
4. Significant product changes may be required based on
user feedback

9. 9
Трипишем, четыредержимв уме
Три пишем, или Риски которые мы документируем и подтверждаем с заказчиком
 Требования (будут менять, неполные, дизайны поменяются.…)
 Коммуникации с заказчиком
 Интеграция с третьесторонними системами

10. 10
Требования
 Priorities/functionality changes for implemented features
 UI design delivery delays
 Redoing work after modifying designs
 Non-functional requirements appearance

11. 11
Коммуникации с заказчиком
 Availability of customer’s team members to
work with the team and provide a feedback
 Low availability of Product Owner
 Inconsistent acceptance process

12. 12
Интеграция с третьесторонними системами
 3d party system may require additional development
 Partner API’s integration issues
 Database integration issue

13. 13
Четыре держим в уме, или Внутрикомандные риски
Трипишем, четыредержимв уме
 Квалификации
 Доступность людей – отпуска, болезни, bus factor
 Поддержка менеджмента
 Коммуникации внутри проектной группы

14. 14
2. Оценка рисков
Probability (likelihood) Impact Proximity

15. 15
3. Стратегии реагирования на риски
 Стратегия уклонения (avoid)
Полное исключение риска из проекта; нет варианта, что риск материализуется
 Стратегия снижения (mitigate)
Самая распространенная стратегия
• Снижение вероятности
• Снижение эффекта

16. 16
 Принятие риска(accept)
Активное принятие – формируется резерв для устранения последствий
Пассивноепринятие– есть план что делать в случае последствий
 Передачариска (transfer)
Последствия перекладываются на третью сторону, сам риск не устраняется

17. 17

18. 18

19. 19
skype: yuliya.korytko
email: juliakorytko@gmail.com