Доклад Михаила Сорокина на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург www.analystdays.com

1. Управление Рисками и
Бизнес-Аналитик
Классическая модель и “Scrum-And”

2. Обо мне
Михаил Сорокин
Работаю в IT уже около 10 лет, последние 6 лет занимаюсь бизнес
анализом, управлением проектов и менеджментом продукта(appery.io).
https://www.facebook.com/sorokin.mikhail
Сертифицированный Scrum Product Owner
https://www.linkedin.com/in/profileofmikhailsorokin
Сертифицированный Scrum Master

3. О чем выступление
- Традиционная модель управления рисками, PMBOK
- Традиционная модель +
Scrum (Реактивность)
= “Scrum-And” (Проактивность)
- Бизнес-аналитик и управление рисками
- Мой опыт работы с рисками: практики управления
рисками

4. Scrum-But и Scrum-And
- Scrum But: “Мы используем Scrum, но перед
релизом выделяем спринт на регрессионное
тестирование”
- Scrum And: “Мы используем Scrum и применяем
классические практики управления рисками.”

5. Что же такое риск?
НЕОПРЕДЕЛЕННОЕ событие или условие, наступление
которого отрицательно или положительно
сказывается на ЦЕЛЯХ проекта.
Если негативное событие(влияющее на ваши цели)
произошло, то это уже не риск. Это уже ПРОБЛЕМА.

6. ИЗ ТОП 10 - 4 риска в относятся к бизнес-анализу
1. Неверная оценка
2. Внезапный рост требований(scope creep)
3. Недопонимания(двусмысленность) требований
4. Потеря или болезнь ключевого сотрудника
5. Плохая продуктивность
6. Неверно выбранная технология
7. Неверная оценка запросов на изменения (change requests)
8. Бюрократия
9. Плохо поставленные коммуникаций
10. Все уснули - не желание key stakeholders как с нашей так и с той
стороны выполнять свои обязанности
* Алексей Минкевич(с), PMP, тренер по управлению проектами.

7. Кто занимается управлением рисками?
!Scrum: Менеджер проекта Scrum: Команда Разработчиков и Scrum Мастер

8. А зачем это бизнес-аналитику?
- БА видит области наибольшей неопределенности
- БА, как любой член команды, должен уметь работать с
рисками
- Меньше стресса на проекте
- 4 из 10 ключевых рисков относятся к бизнес анализу
- Может повысить культуру работы рисков на своем проекте
- Легче бороться с рисками, чем решать проблемы

9. Источники Рисков
- Откуда стоит бизнес аналитику ждать беды риск?

10. Что мне делать если я хочу работать с рисками?
План реагирования на возникновение пожараНужен план!

11. Классическая модель: жизненный цикл риска
Классическая модель работы с рисками
предлагает нам следующие шаги:
1. Идентификация рисков
2. Документирование
3. Качественный анализ рисков
4. *Количественный анализ
5. Планирование реагирования на
риски
6. Контроль рисков

12. Практики Управления Рисками и Церемонии в Scrum

13. Классика: идентифицируем риски
- Кто может знать о рисках проекта-продукта
- Владелец продукта (product owner): требования, сам заказчик,
коммуникация, приоритеты.
- Команда: технические и интеграционные риски, требования, приоритеты
- Пользователи
- SME: правовые нормы, требования.
- Отдельный митинг для выявление рисков заводить не
стоит. Риски хорошо выявляются в контексте других
митингов.

14. Идентификация рисков: Классика и Scrum

15. Идентифицируем риски в Scrum: какие и где
Ежедневный Scrum: задачи на спринт, цели спринта
Планирование: требования, планирование работ на спринт,
цели спринта
Поддержка беклога продукта (backlog refinement): риски,
связанные с конкретными задачами, интеграционные риски и
приоритеты
Обзор спринта: риски связанные с инкрементом и релизом
Ретроспектива: процессы, инструментами, люди

16. Классика. Документируем риски, реестр рисков
- Первый шаг к управлению рисками - записать
риск.
- Можно риск “проговорить” и если все понимают, что он
важный*, то и наметить план его минимизации. Это лучше чем
“ничего” :)

17. Классика: запись в реестре рисков
Влияние риска Среднее
Вероятность риска Высокая
Описание риска Неготовность требований (историй и КП) к планированию нового спрфинта.
Влияние на проект
Команда не сможет взять требования в разработку и будет упущено время и фича пойдет в разработку
только в след. спринте.
Область риска Скоуп
План реагирования
Начинать описывать требования, стори как можно раньше. Планировать работу по выявлению требований
за спринт. Следить за блокерами при разработке требований.
Тип стратегии обработки риска Снижение
Хозяин
риска Менеджер проекта, BA

18. Регистрация рисков: Классика и Scrum

19. Как регистрируются в Scrumе
- В Scrum нет артефакта для документирования рисков
- Предлагаю риски можно записывать:
- На странице для ретроспективы
- Журнале Sprint-а (Sprint log)
- Вешать стикеры с рисками на Scrum доску

20. Регистрируем риски в Scrum
- Ежедневный Scrum. Блокеры* и новые риски - в журнал спринта, на
доску.
- Ретроспектива. Формат ретроспективы дополнить вопросами
выявляющими риски. “Что можно было бы улучшить и если мы это не
улучшим, то чем это нам грозит?”
- Поддержка Беклога Продукта. Записать в описании задачи.
- Планирование. Вносить либо в страницу ретроспективы нового
спринта, либо в журнал стринта.

21. Страница с результатами ретроспектив:
Что можно было бы улучшить? и что могло и может пойти не
так?
Что получилось улучшить?

22. Риски в Спринт Логе

23. Спринт лог: блокеры
Блокеры(impediments) следует регистрировать, чтобы проводить
анализ на ретроспективе. Блокеры можно хранить в логе спринта. Если
блокер возникает регулярно, то это риск для процесса.

24. Риски на Scrum доске
● Disclaimer: фото не мое. Мы отошли от практики скрам досок, т.к. команды стали
распределенными.

25. Анализ: Какие риски заслуживают внимания?
Реагировать нужно только на ключевые риски.
Ключевой риск - это риск с высокой вероятностью И высоким влиянием.
Вероятность
Влияние
Ключевые риски. Где вероятность и
влияние высокие и средние.

26. Планирование реагирования на риски
- Определив ключевые риски, мы уже можем составить план
реагирования на них.
- Целью реагирования может быть
- Устранение самого риска или снижение его вероятности или влияния на цели
проекта.
- Устранение последствий
- Тип стратегии обработки риска негативных рисков
- Предотвращение, Смягчение, Перенос, Принятие.
- План реагирования на риск вносят документируют

27. Планирование реагирования на риски

28. - Риск:
Включить в MVP слишком мало и получить негативную обратную связь пользователей и
потерю доверия к продукту.
Стратегия: уменьшение риска
- Мы можем иметь следующий план:
- Создать прототип фичи и получить обратную связь.
- Провести приемочное тестирование как можно раньше, на прототипах.
Планирование реагирования на риски, пример

29. Планирование реагирования на риски в Scrum-е
- Scrum не предоставляет механизмов определения важности
рисков: заимствуем у классической модели. Команда и ПО
определяет важность риска.
- План реагирования на риск в Scrumе может быть сформирован
на
- Ретроспективе
- Планировании
- Обзоре бэклога
- * На дополнительном митинге после Ежедневного скрама.

30. Контроль рисков: классика
- Применение планов реагирования на риск
- Обновление реестра рисков
- переоценка рисков
- удаление рисков, которые уже не актуальны
- Выявления новых рисков

31. Практики Управления Рисками и Церемонии в Scrum

32. Контроль рисков в Srcume
- Планирование спринта: выявление новых рисков, связанных с
целями спринта и задачами.
- Ежедневный Scrum: выявление блокеров и верификация, что
блокеры, озвученные вчера, ушли. Определение рисков
связанных с целями спринта и задачами.
- Ретроспектива: проверить, что осталось с прошлой
ретроспективы и оценить насколько риски устранены.
- Поддержка Беклога Продукта (backlog refinement): выявление
рисков связанных с конкретной историей.
- Обзор Спринта: верификация рисков связанных с инкрементом и
релизом.

33. Заключение: Эволюция управления рисками
1. Решает проблемы.
На риски не реагирует.
2. Замечает риски, но не
знает, что с ними делать. 3. Пытается
пользоваться
инструментарием и
начинает работать с
рисками.
4. Осознанно работает с
рисками и внедряет
культуру управления
рисками на проекте.

34. Спасибо!
Вопросы?