Менеджмент цифрового продукта. От идеи до идеала

После обновления приложения 100 тыс. пользователей (владельцев старых устройств) не смогут столкнуться с потерей функциональности приложения. На восстановление работоспособности понадобится один месяц. Накопленная статистика показывает, что за это время от использования приложения могут отказаться 10 % пользователей. Средний доход на пользователя в месяц – 500 руб.

Объем риска: величина потерь – 10 тыс. пользователей, вероятность возникновения потерь – 0,1.

Объем риска =10 тыс. пользователей × 0,1 = 1000 пользователей.

Таким образом, объем риска составляет 1000 пользователей. Это означает, что в результате потери функциональности из-за обновления приложения можно ожидать, что 1000 пользователей могут отказаться от использования приложения в течение месяца. Если средний доход на пользователя в месяц составляет 500 рублей, то потенциальные потери дохода составят 500 тыс. рублей.

4.3.4.2. Выставление порога риска для проекта

Порог риска для проекта – это максимально допустимый уровень риска, который может быть принят или с которым можно справиться в рамках инициативы. Он зависит от целей, бюджета, сроков, качества и других ограничений проекта, а также от аппетита к риску заинтересованных сторон проекта.

Для выставления порога риска необходимо сравнить объем риска с ожидаемой прибылью от проекта, то есть с разницей между доходами и затратами. Если объем риска превышает ожидаемую прибыль инициативы, то риск неприемлем и требует принятия мер по его снижению, передаче, митигации или отказу от инициативы. Если объем риска меньше или равен ожидаемой ценности инициативы, то риск приемлем и может быть принят, управляем, митигирован или игнорирован.

Например, компания может выработать следующие стандарты принятия рисков:

➠ Не начинать разработку инициативы, если суммарный объем присущих рисков превышает годовой доход от инициативы.

➠ Приостановить или откатить инициативу, если объем ущерба в результате реализации рисков составляют более 10 % от годового дохода инициативы.

4.3.5. Оценка трудозатрат на разработку

Оценка трудозатрат на разработку – важный этап при формулировании гипотезы, который позволяет определить, сколько времени и ресурсов потребуется для реализации различных сущностей, таких как эпики или решения. Оценка трудозатрат помогает планировать работу, прогнозировать сроки и бюджет, а также оценивать окупаемость инициатив.

Однако точная оценка трудозатрат в человеко-часах, особенно для больших и сложных сущностей, может быть затруднительной и затратной. Кроме того, такая оценка может быть неточной или устаревшей из-за неопределенности, изменений или рисков, связанных с проектом. Поэтому в гибкой разработке часто используются альтернативные способы оценки трудозатрат, которые основаны на относительной сложности сущностей, а не на абсолютных значениях.

Мы уже знакомы с относительной оценкой в сторипоинтах, которая используется для оценки сущностей размеренности пользовательской истории. Теперь давайте посмотрим на способы с относительной оценкой, которые позволяют быстро оценивать трудозатраты в днях работы команды.

В этой главе мы рассмотрим два способа, которые подходят для быстрой оценки сущностей размером в квартал, то есть тех, которые требуют от трех до шести месяцев для реализации. Эти способы называются оценкой по «ведрам» (bucket system estimation) и оценкой по сходству (affinity estimation).

4.3.5.1. Ретроспективная оценка трудозатрат

Если команда сформировалась относительно давно и успела закрыть несколько эпиков, то эти ретроспективные данные можно использовать для оценки будущих историй. Чтобы оценить трудозатраты в часах команды на эпики, которые уже были сделаны, можно использовать следующий метод. Сначала нужно собрать данные о количестве сторипоинтов и юзерстори, выполненных по каждому эпику с момента старта команды. Затем нужно посчитать долю сторипоинтов, приходящуюся на каждый эпик, относительно общего количества сторипоинтов, выполненных командой. Наконец, нужно умножить эту долю на количество рабочих дней с момента старта первого спринта команды. Это даст приблизительную оценку трудозатрат в днях команды на каждый эпик.

Для наглядности можно построить таблицу, где:

➠ Эпик – это название эпика, который был выполнен командой.

➠ Сторипоинты – это сумма всех сторипоинтов, затраченных на эпик с момента старта команды.

➠ Юзерстори – это сумма всех юзерстори, выполненных по эпику с момента старта команды.

➠ Дни команды – это оценка трудозатрат в днях команды на эпик, рассчитанная по формуле:

Табл. 4.8. Пример таблицы с расчетом количества затраченных дней

В табл. 4.8 предполагается, что команда выполнила 200 сторипоинтов за 40 рабочих дней. Тогда, например, для эпика «Внедрение дизайн-системы» оценка трудозатрат в днях команды будет равна:

Теперь команда может ориентироваться на суммарную оценку в сторипоинтах и/или в юзерстори для оценки новых эпиков. Оценку в днях можно скрыть, чтобы не вызвать привязку к абсолютным значениям в оценке.