На собеседованиях продакт-менеджеров, продакт-оунеров и скрам-мастеров любят спрашивать про фреймворки приоритизации и опыт работы с ними. Но реальной практики в этой области в статьях на Хабре изложено не так много — в тех текстах, которые попадались мне в последнее время, не хватает глубины именно для 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 часто критикуют (например, здесь):
За субъективность. Разные люди оценивают по-разному или оценки меняются во времени.
За манипулирование. Команда может попробовать хакнуть ICE и протащить любимую фичу вперед нужной.
За излишнюю простоту. ICE в условных единицах не покажешь инвестору.
За сложность. Если оценивать в деньгах, нужны усилия аналитиков и компетенции в построении финансовых моделей.
Обсудим аргументы в защиту 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%. Причина простая: предварительная оценка хорошо описывала известную сложность, то есть была консервативной («не менее, чем...») и оптимистичной («вроде это несложно»).
Effort (high-level) |
Effort (after grooming) |
Effort difference |
|
Group budgets |
40 |
70 |
75% |
3DS add card flow |
15 |
22 |
47% |
API credentials |
25 |
48 |
92% |
Invite statuses |
15 |
23 |
53% |
Reports columns customisation |
14 |
19 |
36% |
Booker assignment |
15 |
27 |
80% |
Automatic limit for Client X |
15 |
30 |
100% |
Subscriptions |
50 |
70 |
40% |
Total |
189 |
309 |
63% |
Я выхожу из ситуации просто — учитываю рост трудозатрат с обнаружением сложности и увеличиваю первоначальную оценку на 63% (этот коэффициент получен эмпирическим путем и работает для моей команды).
Вишенка на торте — калькулятор стоимости человеко-дня
Очень классно, если в вашей компании есть оговоренная стоимость одного человеко-дня разработки, рассчитанная финансистами по всем правилам. Однако, если этого нет, но хочется понять, чем отличается зарплата на руки и стоимость дня для бизнеса, можно попробовать посчитать.
Я не нашел годного расчета, поэтому запилил свой Калькулятор стоимости 1 дня разработки:
200 тыс. руб. на руки получает в среднем разработчик в Москве согласно исследованию Хабра, то есть примерно 10 тыс. руб. за рабочий день.
-
Со всеми налогами и накладными издержками один день разработки обходится для компании:
39 тыс. руб. для аккредитованной IT-компании;
45 тыс. руб. для обычной компании без налоговых льгот.
Средняя фича может стоить 1 млн руб. для компании, так что надо быть уверенным, стоит ее делать или нет. Здесь логично разместить рекламу аутсорс-разработки (становится понятно, почему даже компании с сильной in-house командой привлекают внешнюю помощь).
Трудозатраты: взгляд разработчика
В калькуляторе выше вы видели 20% времени, заложенных на технический долг. Это обычная практика. Мой коллега — тимлид — согласился пояснить, почему это так.
Слово Стасу:
Откуда к нам приходят фичи? Компания ставит цели, договаривается с командами о приоритетных направлениях, формулирует OKR. Для выполнения OKR придумываются гипотезы, часть из них попадает в разработку.
Задачи приходят к нам в виде эпиков — улучшений продукта, которые можно сделать за один-максимум два спринта. Я слежу за тем, чтобы эпики не превышали 15–20 стори поинтов и предлагаю продакту фазировать улучшения. С помощью дробления повышается и точность оценки трудозатрат, и сокращаются сроки релизов.
Основной конфликт: продакт хочет фичи, разработчики не хотят продуктовый долг.
Продакт хочет, чтобы фичи делались дешево, потом стоимость владения не увеличивалась.
Чтобы разрешить этот конфликт, мы договорились, что 20% трудозатрат отдаем на погашение тех долга. Этот резерв распределяет команда разработки.
Сменятся поколения продактов и разработчиков, но нужно отдавать старые долги.
Что нужно, чтобы приоритизация заработала
Сначала стратегия, потом фичи.
ICE не дает ответ на вопрос, как компании победить конкурентов или что нужно делать в ближайшее время. Если просто приоритизировать все запросы на фичи — это:
займет много времени;
может расфокусировать команду.
На мой взгляд, это одна из главных проблем, на которых может сломаться приоритизация. Что можно сделать: пройти обратным путем — от фичи к цели компании, как об этом говорил Стас в первом пункте.
Договоритесь в компании о единой методологии оценки.
Вторая преграда для внедрения ICE или другой методологии — приоритизация должна быть сквозной, то есть единой для всех команд, которые тесно работают друг с другом. Это одна из задач директора по продуктам (Chief Product Officer) — придумать одинаковые правила игры.
Приоритизируйте крупные фичи, затем всё остальное.
Дальше поделюсь базовой рекомендацией от Стивена Кови — планируй сначала крупные и важные дела. Сначала большие камни, потом галька, затем песок.
Допустим, команда может за месяц сделать одну-две крупных фичи, а три уже нет. Тогда в нашу емкость с ресурсами нужно положить сначала две крупных фичи, потом три средних, остальное отдать мелким фичам. Если заполнять в противоположном порядке, может не хватить места для крупного и важного.
Используйте инструменты для фиксирования и автоматического обновления ICE.
В Jira и другом ПО для приоритизации есть возможность добавлять ICE-score к каждой задаче. По моему опыту еще лучше дополнительно разложить ICE на impact, confidence и effort и сделать один слайд (1-pager) для руководства, чтобы более широкому кругу, а не только команде разработки, было понятно, как компания тратит деньги и что получит взамен.
Заключение
Подведем итог,
Используйте ICE вместо RICE (Impact может включать в себя Reach).
Как расшифровывать E — решать вам. Это ease (сложность реализации) или величина обратно пропорциональная — effort (усилия).
Быстрый ICE в условных единицах подходит для скоринга 100 задач. Если надо выбирать из 20 — посчитайте ICE в деньгах.
Бизнес-кейс — фундамент для оценки эффекта (Impact). Постарайтесь, чтобы ваша формула для экономического эффекта была простой и проверяемой. Компоненты для формулы держите под рукой.
Уверенность (Confidence) не должна строиться только на харизме автора идеи, идеи нужно проверять, чтобы сделать Confidence ближе к 100% — интервью с клиентами хорошо, тестовый запуск еще лучше.
Трудозатраты (Effort) можно считать в человеко-днях или story points. Заложите рост оценки усилий на разработку по мере углубления в требования по фиче.
За человеко-день разработчик получит на руки 10 тыс. руб., а компании этот день обойдется в 39 тыс. руб. из-за налогов, бенефитов и накладных расходов. Не забывайте про деньги, когда загружайте in-house разработку, и нанимайте аутсорсеров для отдельных задач.
Effort генерит технический долг. Договоритесь с разработчиками о его размере и способах погашения.
-
Чтобы приоритизация прижилась в компании:
Приоритизируйте задачи, связанные со стратегическим выбором компании. Проверяйте цепочку от фичи к целям компании.
Договоритесь со всеми смежными командами о единой методологии приоритизации.
Приоритизируйте по Стивену Кови — сначала внутри списка крупных задач, потом переходите к средним и небольшим.
Упрощайте расчет ICE через трекеры задач.
Если хотите обсудить продакт-менеджмент, приоритизацию, добавляйтесь в LinkedIn или пишите в личку в Telegram.