Приоритизация бэклога. Зачем нужны фреймворки и как работать по ICE — опыт менеджера с 5-летним стажем

На собеседованиях продакт-менеджеров, продакт-оунеров и скрам-мастеров любят спрашивать про фреймворки приоритизации и опыт работы с ними. Но реальной практики в этой области в статьях на Хабре изложено не так много — в тех текстах, которые попадались мне в последнее время, не хватает глубины именно для ICE.

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

Привет,

Я — Дима, был продакт-менеджером в QIWI и криптостартапе, а сейчас работаю в Gett. Но рассказ о своем опыте построю в отрыве от конкретной компании, поскольку успешно применял этот подход в разных командах.

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

Когда не обойтись без фреймворка приоритизации

В стартапах ранней стадии чаще всего фреймворки приоритизации не используются. Команда занята проверкой гипотез, поиском целевого сегмента клиентов, изучает его потребности и тестирует базовое решение (продукт) — ищет product-market fit. Проверка гипотез в большинстве случаев не требует разработки — ручные продажи, лендинги, чаты, no code — любимые инструменты стартаперов. То есть разработчиков может не быть совсем или они могут разрабатывать ядро продукта из минимального набора необходимых компонентов.

Когда у продукта появляется основной функционал, растет количество клиентов, сегментов и стран, возникает необходимость приоритизировать фичи, в том числе разрабатываемые разными командами. И здесь без договоренности о том, как именно расставлять приоритеты — то есть без фреймворка — уже не обойтись.

Во фреймворках приоритизации используют понятие «скоринг» — это оценка задач по заранее определенным критериям. После скоринга у задачи появляется показатель (score), по которому разные таски можно ранжировать с точки зрения очередности разработки.

Благодаря скорингу фичей получается:

• снизить предвзятость оценки конкретного продакт-менеджера;

• пересчитывать скоринг после изменений входящих параметров, например, при запуске аналогичной фичи у конкурентов или при появлении более простого способа решения потребности клиента;

• организовать сквозную приоритизацию внутри компании, когда есть разные команды и кросс-командные фичи.

Распаковываем RICE и ICE

Существует как минимум 15 фреймворков приоритизации задач — модель Кано, взвешенная оценка, MoSCoW и другие. Среди самых популярных методов скоринга фичей выделяют RICE и ICE. Первую популяризировал предприниматель Шон Эллис в книге «Взрывной рост» (Growth Hacking) в 2017 году, потом уже в 2018 ветеран Google и Microsoft Итамар Гилад разобрал работу фреймворка ICE.

RICE

Свое название методика получила по первым буквам входящих в расчет компонент:

• Reach (охват) — какое количество клиентов будет охвачено.

• Impact (эффект) — насколько фича повлияет на ключевой показатель (увеличит выручку, снизит расходы или регуляторные риски).

• Confidence (уверенность) — насколько мы уверены, что фичи достигнет ожидаемого эффекта.

• Effort (усилия) — сколько времени потребуется, чтобы сделать фичу.

  

ICE

ICE — это вариация RICE, где отдельно не выделяют R (Reach), считая его компонентом I (Impact). Это имеет смысл с точки зрения бизнеса. Например, если фича затрагивает небольшой процент наиболее лояльных пользователей, Reach (охват) будет низким, тогда как Impact (влияние) будет больши́м.

Дальше я буду говорить только про ICE.

Чаще всего используют одну из двух трактовок ICE — «классическую» или «финансовую».

Классический ICE измеряется в условных единицах и лучше подходит для быстрого скоринга и ранжирования.

• Impact (влияние) включает в себя сразу и количество охваченных клиентов, и выгоду от фичи. Как правило, для быстрой оценки Impact оценивается в баллах по шкале от 1 до 10.

• Confidence остается тем же, что и в RICE. Измеряется по шкале от 1 до 10 или в процентах.

• Effort меняется на Ease — простоту реализации, по сути, обратное значение от усилий. Effort можно считать в человеко-днях, story points, T-shirts (S, M, L, XL) или аналогично Impact разбить на 10 интервалов.

Поясню, как работает «быстрый» ICE, на примере абстрактной фичи, отправляющей некоторые системные сообщения не по SMS, а через push в мобильное приложение:

• это фича средняя по эффекту на бизнес — на 5 из 10;

• выше среднего по сложности разработки — на 8 из 10;

• уверенность почти 100%, но что-то может пойти не так, поэтому 80%.

Impact (5) × Confidence (80%) / Effort (7) = 0,57 условной единицы оценки.

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

Для таких случаев подходит более точный вариант — финансовый ICE — подсчет выгоды от вложения денег в разработку фичи или, как говорят финансисты, profit & loss (PnL): дословно «прибыль и убытки». Финансовый вариант сложнее для расчета, но зато оперирует понятными для руководства измерениями — затратами и экономическим эффектом в деньгах.

В этом случае:

• Impact считается в долларах или рублях;

• Confidence, как и раньше, в процентах от никакой 0% до абсолютной уверенности 100% в успехе фичи;

• Effort в стоимости разработки.

А оценка нашей фичи из примера будет такова:

• охват 100 тыс. пользователей; считаем экономию для каждого: частота 10 сообщений в год, стоимость одного сообщения 2 рубля через SMS, push — 0.5 рублей с учетом поддержки этого канала;

• Confidence — тот же, 80%;

• 20 дней разработки = 700 тыс. руб.

Impact (100 тыс. пользователей × 10 сообщений в год × (2 — 0.5) руб. экономии) × 80% — 700 тыс. руб. = 500 тыс. руб.

Достоинства и недостатки ICE скоринга

Подход ICE часто критикуют (например, здесь):

1. За субъективность. Разные люди оценивают по-разному или оценки меняются во времени.

2. За манипулирование. Команда может попробовать хакнуть ICE и протащить любимую фичу вперед нужной.

3. За излишнюю простоту. ICE в условных единицах не покажешь инвестору.

4. За сложность. Если оценивать в деньгах, нужны усилия аналитиков и компетенции в построении финансовых моделей.

Обсудим аргументы в защиту ICE, разобрав каждый из компонентов скоринга.

Impact

Субъективная оценка хороша, когда продакту с тимлидом разработки нужно за один час отскорить десять фичей. Но давайте разберем, как относительно недорого снизить эту субъективность.

Чтобы не углубляться в юнит-экономику, тонкости расчета lifetime value, разберем простой пример: вы продакт внутреннего продукта службы поддержки клиентов. Ваша фича — внедрение чат-бота в личном кабинете клиента для снижения нагрузки на телефонную поддержку.

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

Какие данные могут пригодиться для расчета?

• кол-во клиентов;

• % клиентов с обращениями в саппорт;

• среднее количество обращений в саппорт за год;

• стоимость обработки обращений в чате и по телефону;

• доля обращений в чат среди всех обращений;

• % автоматизации однотипных обращений в чат;

• стоимость обращения недовольного клиента, который пожалуется аккаунт менеджеру или даже генеральному директору.

Допустим, эти данные есть — что дальше?

Нужно рассчитать бизнес-кейс — экономический эффект по максимально простой формуле.

Для нашего примера бизнес-кейс можно подсчитать так:

• 100 тыс. пользователей × 10% доля тех, кто обращается в саппорт × 5 обращений в год × 30% доля обращений в чат × 50% потенциал автоматизации × 50 рублей экономии на звонках — 50000 руб. за внедрение внешнего решения — 15000 чатов × 1 руб. выплаты вендору = 310 тыс. руб.

Если вы используете внешний API, его лучше учесть именно в экономическом эффекте вместе с платежами партнерам за внедрение. Затраты вашей команды на интеграцию нужно относить к Effort (усилиям).

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

Чтобы получить более точную, хотя и консервативную оценку, считайте Impact не на всех клиентов, а на конкретный сегмент или даже тематику обращений в саппорт, с которыми вы знакомы лучше всего. Например, если 50% обращений по статусу заказа, давайте оценим потенциал автоматизации через чат-бот только по этой тематике. Возможно, эффект будет настолько больши́м, что кратно окупит разработку.

Confidence

Чтобы рассчитать уверенность или веру в успех, нужно провалидировать фичу. Это хлеб с маслом для продакта и тема отдельной статьи. Но не стоит полагаться только на свое мнение (или оценку автора идеи фичи).

Я обычно применял метод Confidence-meter от Итамара Гилада, где мнение одного или нескольких коллег дает в лучшем случае 20% уверенности, а полноценная проверка гипотез через интервью, MVP и А/Б-тесты повышает Confidence до 60–95%. 100% по Гиладу не бывает никогда.

Мой совет на этапе оценки уверенности — максимально отключить самоуверенность и сфокусироваться на «накоплении» Confidence с помощью подходящих способов валидации того, что проблема существует, а ваша фича решает эту проблему достаточно эффективно.

Effort и его рост

Перейдем к оценке усилий и трудозатрат.

Здесь я вижу две проблемы.

Первая — сложность оценки effort до подготовки полных требований к продукту, а вторая — технический долг.

Как правило, оценка сложности занижена.

Ниже пример из моего опыта, когда после предварительной оценки окончательная вырастала на 36–100%, в среднем на 63%. Причина простая: предварительная оценка хорошо описывала известную сложность, то есть была консервативной («не менее, чем...») и оптимистичной («вроде это несложно»).

Я выхожу из ситуации просто — учитываю рост трудозатрат с обнаружением сложности и увеличиваю первоначальную оценку на 63% (этот коэффициент получен эмпирическим путем и работает для моей команды).

Вишенка на торте — калькулятор стоимости человеко-дня

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

Я не нашел годного расчета, поэтому запилил свой Калькулятор стоимости 1 дня разработки:

• 200 тыс. руб. на руки получает в среднем разработчик в Москве согласно исследованию Хабра, то есть примерно 10 тыс. руб. за рабочий день.

• Со всеми налогами и накладными издержками один день разработки обходится для компании:

  • 39 тыс. руб. для аккредитованной IT-компании;

  • 45 тыс. руб. для обычной компании без налоговых льгот.

Средняя фича может стоить 1 млн руб. для компании, так что надо быть уверенным, стоит ее делать или нет. Здесь логично разместить рекламу аутсорс-разработки (становится понятно, почему даже компании с сильной in-house командой привлекают внешнюю помощь).

Трудозатраты: взгляд разработчика

В калькуляторе выше вы видели 20% времени, заложенных на технический долг. Это обычная практика. Мой коллега — тимлид — согласился пояснить, почему это так.

Слово Стасу:

• Откуда к нам приходят фичи? Компания ставит цели, договаривается с командами о приоритетных направлениях, формулирует OKR. Для выполнения OKR придумываются гипотезы, часть из них попадает в разработку.

• Задачи приходят к нам в виде эпиков — улучшений продукта, которые можно сделать за один-максимум два спринта. Я слежу за тем, чтобы эпики не превышали 15–20 стори поинтов и предлагаю продакту фазировать улучшения. С помощью дробления повышается и точность оценки трудозатрат, и сокращаются сроки релизов.

• Основной конфликт: продакт хочет фичи, разработчики не хотят продуктовый долг.

• Продакт хочет, чтобы фичи делались дешево, потом стоимость владения не увеличивалась.

• Чтобы разрешить этот конфликт, мы договорились, что 20% трудозатрат отдаем на погашение тех долга. Этот резерв распределяет команда разработки.

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

Что нужно, чтобы приоритизация заработала

1. Сначала стратегия, потом фичи.

ICE не дает ответ на вопрос, как компании победить конкурентов или что нужно делать в ближайшее время. Если просто приоритизировать все запросы на фичи — это:

• займет много времени;

• может расфокусировать команду.

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

2. Договоритесь в компании о единой методологии оценки.

Вторая преграда для внедрения ICE или другой методологии — приоритизация должна быть сквозной, то есть единой для всех команд, которые тесно работают друг с другом. Это одна из задач директора по продуктам (Chief Product Officer) — придумать одинаковые правила игры.

3. Приоритизируйте крупные фичи, затем всё остальное.

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

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

4. Используйте инструменты для фиксирования и автоматического обновления ICE.

В Jira и другом ПО для приоритизации есть возможность добавлять ICE-score к каждой задаче. По моему опыту еще лучше дополнительно разложить ICE на impact, confidence и effort и сделать один слайд (1-pager) для руководства, чтобы более широкому кругу, а не только команде разработки, было понятно, как компания тратит деньги и что получит взамен.

Заключение

Подведем итог, 

1. Используйте ICE вместо RICE (Impact может включать в себя Reach).

2. Как расшифровывать E — решать вам. Это ease (сложность реализации) или величина обратно пропорциональная — effort (усилия).

3. Быстрый ICE в условных единицах подходит для скоринга 100 задач. Если надо выбирать из 20 — посчитайте ICE в деньгах.

4. Бизнес-кейс — фундамент для оценки эффекта (Impact). Постарайтесь, чтобы ваша формула для экономического эффекта была простой и проверяемой. Компоненты для формулы держите под рукой.

5. Уверенность (Confidence) не должна строиться только на харизме автора идеи, идеи нужно проверять, чтобы сделать Confidence ближе к 100% — интервью с клиентами хорошо, тестовый запуск еще лучше.

6. Трудозатраты (Effort) можно считать в человеко-днях или story points. Заложите рост оценки усилий на разработку по мере углубления в требования по фиче.

7. За человеко-день разработчик получит на руки 10 тыс. руб., а компании этот день обойдется в 39 тыс. руб. из-за налогов, бенефитов и накладных расходов. Не забывайте про деньги, когда загружайте in-house разработку, и нанимайте аутсорсеров для отдельных задач.

8. Effort генерит технический долг. Договоритесь с разработчиками о его размере и способах погашения.

9. Чтобы приоритизация прижилась в компании:

   1. Приоритизируйте задачи, связанные со стратегическим выбором компании. Проверяйте цепочку от фичи к целям компании.

   2. Договоритесь со всеми смежными командами о единой методологии приоритизации.

   3. Приоритизируйте по Стивену Кови — сначала внутри списка крупных задач, потом переходите к средним и небольшим.

   4. Упрощайте расчет ICE через трекеры задач.

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