Риск-менеджмент вашего продукта
Закон Мёрфи — Всё, что может пойти не так, пойдет не так
Необходимо заранее охватить всевозможные риски и хотя бы принять их. Важно, чтобы свершившийся риск не был для вас полной неожиданностью.
Что такое риск
Риск — это негативное событие, которое может наступить с некоей вероятностью и имеет некую критичность для вас.
Ваша задача: выявить риски, распределить по типам и проранжировать их на основании критичности и вероятности.
Что делать с риском
Для каждого риска проставьте критичность K и вероятность P (от 1 до 3. 3- мегакритично, 1 — малокритично).
Получите интегральный показатель по всем рискам (например, по формуле P+ 2* K). Отсортируйте список в порядке убывания и у вас будет план по обработке рисков (начиная с самых критично-вероятных).
- Вырабатываем меры по уменьшению критичности
- Вырабатываем меры по уменьшению вероятности
- Если ничего сделать с ним не можем, то надо смириться с этим и знать что это может случиться.
Пример обработки риска
Возьмем риск, который несет на себе каждый из нас — автомобильная авария.
Вероятность — средняя, ближе к высокая (особенно для тех, кто постоянно катается за рулем на дальние расстояния).
Критичность — очень высокая.
Как можем снизить вероятность — меньше кататься на авто, найти работу поближе и ходить пешком, либо работать из дома. Не ездить с лихачами. Взять за правило никогда не гнать под желтый.
Как можем снизить критичность — купить машину побольше, всегда пристегиваться, машина с подушкой безопасности.
Полностью риска избежать не получится, и нужно смириться с тем, что это может произойти с каждым (но при этом надо предпринять как минимум те меры, которые мы описали).
Примеры рисков при разработке продукта
Выделим несколько рисков, с которыми вы можете столкнуться:
Усложнение функционала и ненужные функции. Стремление все усложнить и накрутить — очень частая история. Старайтесь сознательно с этим бороться.
Костыли. Программисты могут без вашего ведома использовать некие костыльные решение на неимением более подходящего решения. Проблема костылей в том, что они усложняют сопровождение и увеличивают риски возникновения ошибок в продукте
Смена product owner. При этом скорее всего изменится видение продукта, его стратегическое развитие. Если придет неподходящий человек, то это может погубить даже стабильный устойчивый успешный продукт.
Слишком сильное желание угодить потребителю - в погоне за мимолетными желаниями пользователей вы быстро потеряете фокус продукта и сделаете решение “все для всех”. Обычно такие решения очень сложны в использовании, неповоротливые и имеют очень сложный витиеватый интерфейс.
Управление требованиями по продукту
Что реализовать продукт, его необходимо конкретно и однозначно описать. Чем точнее описание, тем меньше будет разница между ожиданиями и результатом.
Описывать продукт необходимо итеративно. Для начала определитесь с 1 версией продукта - минимальный функционал, который будет введен в эксплуатацию.
Как описывать требования
Описывать его можно в виде пользовательских историй. Каждая история - это детализация возможности некоторой роли в системе. Можно это делать в формате “Я как роль такая-то могу сделать то-то с такой-то целью”.
Ключевые моменты пользовательской истории:
- роль
- что может сделать
- для чего он это делает.
Совместно с разработчиком можно детализировать описание и добавить технические ограничения и детали:
- какие поля будут у формы,
- какие ответы должна обрабатывать форма
- реакция системы в специфичных ситуациях (например, на мобильном экране)
- специфические ограничения доступа.
К первой версии программы надо идти поэтапно. В крайнем случае это может быть 1 этап.
ТЗ (техническое задание) на этап - это по сути набор пользовательских историй.
К пользовательским историям можно прикладывать макеты, которые были сформированы ранее.
Организация хранения требований
Где хранить пользовательские истории? В беклоге. В самом простом случае это таблица Excel со следующими полями:
- Пользовательская история
- Статус (Не начата, В работе, Отложено, Внедрено)
- Приоритет
- Сложность реализации
- Детальные требования
- Значение для продукта
На основании приоритета, значения для продукта и сложности вы можете определить, что необходимо реализовать в первую очередь.
Как работать с беклогом
Беклог - это постоянно обновляемый документ. В него попадают все новые хотелки, возникающие по ходу проекта. Ни в коем случае не внедряйте сразу все, что приходит в голову.
Если в ходе этап возникла идея - просто заносим в беклог и описываем ее в разрезе всех столбцов беклога. Очень часто возникает ситуация, что требование быстро становится неактуальным, либо трансформируется или уточняется. Поэтому нет необходимости транзитом через беклог сразу “гнать” требования в сторону разработчиков.
Двигаясь по этапам вы периодически обновляете беклог:
- обновляете статусы реализованных возможностей
- добавляете новые идеи
- детализируете самые приоритетные истории
Когда подходит время делать следующий этап, вам не нужно судорожно придумывать, что делать дальше. Вы берете из беклога самые приоритетные истории и из них делаете ТЗ.
Пример карты рисков и шаблон беклога есть среди материалов к данному курсу
Советы
- Посмотрите серию видео про бизнес-риски на нашем канале Youtube #bizproblem
Задание
- Составьте свою карту рисков и проранжируйте их по вероятности и степени критичности (по интегральному показателю).
- Составьте план мероприятий по обработке рисков.
- Сформируйте начальный беклог для своего проекта (не менее 5 возможностей) с заполнением всех полей.