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

Обо мне

Михаил СорокинРаботаю в IT уже около 10 лет, последние 6 лет занимаюсь бизнес анализом, управлением проектов и менеджментом продукта(appery.io).

https://www.facebook.com/sorokin.mikhail

Сертифицированный Scrum Product Owner

https://www.linkedin.com/in/profileofmikhailsorokin

Сертифицированный Scrum Master

О чем выступление

- Традиционная модель управления рисками, PMBOK

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

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

Scrum-But и Scrum-And

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

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

Что же такое риск?

НЕОПРЕДЕЛЕННОЕ событие или условие, наступление которого отрицательно или положительно сказывается на ЦЕЛЯХ проекта.

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

ИЗ ТОП 10 - 4 риска в относятся к бизнес-анализу

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

* Алексей Минкевич(с), PMP, тренер по управлению проектами.

Кто занимается управлением рисками?

!Scrum: Менеджер проекта Scrum: Команда Разработчиков и Scrum Мастер

А зачем это бизнес-аналитику?

- БА видит области наибольшей неопределенности- БА, как любой член команды, должен уметь работать с

рисками- Меньше стресса на проекте- 4 из 10 ключевых рисков относятся к бизнес анализу- Может повысить культуру работы рисков на своем проекте- Легче бороться с рисками, чем решать проблемы

Источники Рисков

- Откуда стоит бизнес аналитику ждать беды риск?

Что мне делать если я хочу работать с рисками?

План реагирования на возникновение пожараНужен план!

Классическая модель: жизненный цикл риска

Классическая модель работы с рисками предлагает нам следующие шаги:

1. Идентификация рисков 2. Документирование3. Качественный анализ рисков4. *Количественный анализ5. Планирование реагирования на

риски6. Контроль рисков

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

Классика: идентифицируем риски

- Кто может знать о рисках проекта-продукта

- Владелец продукта (product owner): требования, сам заказчик, коммуникация, приоритеты.

- Команда: технические и интеграционные риски, требования, приоритеты

- Пользователи

- SME: правовые нормы, требования.

- Отдельный митинг для выявление рисков заводить не стоит. Риски хорошо выявляются в контексте других митингов.

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

Идентифицируем риски в Scrum: какие и где

Ежедневный Scrum: задачи на спринт, цели спринта

Планирование: требования, планирование работ на спринт, цели спринта

Поддержка беклога продукта (backlog refinement): риски, связанные с конкретными задачами, интеграционные риски и приоритеты

Обзор спринта: риски связанные с инкрементом и релизом

Ретроспектива: процессы, инструментами, люди

Классика. Документируем риски, реестр рисков

- Первый шаг к управлению рисками - записать риск.

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

Классика: запись в реестре рисков

Влияние риска Среднее

Вероятность риска Высокая

Описание риска Неготовность требований (историй и КП) к планированию нового спрфинта.

Влияние на проектКоманда не сможет взять требования в разработку и будет упущено время и фича пойдет в разработку только в след. спринте.

Область риска Скоуп

План реагированияНачинать описывать требования, стори как можно раньше. Планировать работу по выявлению требований за спринт. Следить за блокерами при разработке требований.

Тип стратегии обработки риска Снижение

Хозяинриска Менеджер проекта, BA

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

Как регистрируются в Scrumе

- В Scrum нет артефакта для документирования рисков

- Предлагаю риски можно записывать:

- На странице для ретроспективы

- Журнале Sprint-а (Sprint log)

- Вешать стикеры с рисками на Scrum доску

Регистрируем риски в Scrum

- Ежедневный Scrum. Блокеры* и новые риски - в журнал спринта, на доску.

- Ретроспектива. Формат ретроспективы дополнить вопросами выявляющими риски. “Что можно было бы улучшить и если мы это не улучшим, то чем это нам грозит?”

- Поддержка Беклога Продукта. Записать в описании задачи.

- Планирование. Вносить либо в страницу ретроспективы нового спринта, либо в журнал стринта.

Страница с результатами ретроспектив:

Что можно было бы улучшить? и что могло и может пойти не так?

Что получилось улучшить?

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

Спринт лог: блокеры

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

Риски на Scrum доске

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

Анализ: Какие риски заслуживают внимания?

Реагировать нужно только на ключевые риски.

Ключевой риск - это риск с высокой вероятностью И высоким влиянием.

Вероятность

Влияние

Ключевые риски. Где вероятность и влияние высокие и средние.

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

- Определив ключевые риски, мы уже можем составить план реагирования на них.

- Целью реагирования может быть

- Устранение самого риска или снижение его вероятности или влияния на цели проекта.

- Устранение последствий

- Тип стратегии обработки риска негативных рисков

- Предотвращение, Смягчение, Перенос, Принятие.

- План реагирования на риск вносят документируют

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

- Риск:

Включить в MVP слишком мало и получить негативную обратную связь пользователей и потерю доверия к продукту.

Стратегия: уменьшение риска

- Мы можем иметь следующий план:

- Создать прототип фичи и получить обратную связь.

- Провести приемочное тестирование как можно раньше, на прототипах.

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

Планирование реагирования на риски в Scrum-е

- Scrum не предоставляет механизмов определения важности рисков: заимствуем у классической модели. Команда и ПО определяет важность риска.

- План реагирования на риск в Scrumе может быть сформирован на

- Ретроспективе

- Планировании

- Обзоре бэклога

- * На дополнительном митинге после Ежедневного скрама.

Контроль рисков: классика

- Применение планов реагирования на риск- Обновление реестра рисков

- переоценка рисков - удаление рисков, которые уже не актуальны

- Выявления новых рисков

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

Контроль рисков в Srcume

- Планирование спринта: выявление новых рисков, связанных с целями спринта и задачами.

- Ежедневный Scrum: выявление блокеров и верификация, что блокеры, озвученные вчера, ушли. Определение рисков связанных с целями спринта и задачами.

- Ретроспектива: проверить, что осталось с прошлой ретроспективы и оценить насколько риски устранены.

- Поддержка Беклога Продукта (backlog refinement): выявление рисков связанных с конкретной историей.

- Обзор Спринта: верификация рисков связанных с инкрементом и релизом.

Заключение: Эволюция управления рисками

1. Решает проблемы. На риски не реагирует.

2. Замечает риски, но не знает, что с ними делать. 3. Пытается пользоваться

инструментарием и начинает работать с рисками. 4. Осознанно работает с

рисками и внедряет культуру управления рисками на проекте.

Спасибо!

Вопросы?