С «никогда» мы, конечно, загнули, но в Dodo действительно не было единого отработанного подхода к приоритизации бэклога B2C команд. Кто-то использует RICE, кто-то смотрит только на выручку от фичи, в некоторых продуктах до сих пор всё делается на великом и могучем «вижене». В целом подход рабочий, но только в случае, если у каждой команды есть свой продукт, внутри которого участники становятся экспертами, понимают боли клиентов и могут без дополнительных инструментов определить, какую задачу брать следующей.
А что случилось?
Небольшая предыстория. В Dodo есть два типа команд: глобальные и рыночные. У каждой команды есть своя стратегия развития продукта. Глобальные команды выстраивают стратегию исходя из потребностей всех рынков и концепций, рыночные — очень плотно взаимодействуют с бизнес-юнитами конкретного рынка. Приоритет задач идёт от бизнеса.
Подробно о структуре Dodo Engineering, командах и их приоритетах рассказывает наш СЕО Александр Андронов @alex4Zero в этой статье.
Команда Global Customer Experience (GCX), в которой мы с соавтором этой статьи Юлей @LuCera отвечаем за продуктовую аналитику, прокачивает клиентский опыт в приложении и на сайте Додо Пиццы по всему миру. Мы разрабатываем продукты, которые заботятся о клиентах: помогают легко выбирать, быстро заказывать и радоваться приятным мелочам. При этом наша задача — реализовать решения, которые подойдут всем рынкам.
Мы вели два больших проекта, которые болели у всех, но рыночные команды не смогли бы их затащить к себе в бэклог из-за большого объёма. В марте стратегия всей компании поменялась, нам пришлось сосредоточиться на сохранении бизнеса и быстро перекроить бэклоги. Ключевым рынком для Dodo стала Евразия, и чтобы его усилить, наша команда по факту из глобальной превратилась в рыночную.
Стало понятно, что:
нам надо отказаться от долгосрочных проектов и брать в работу задачи, которые можно быстро реализовать и которые сразу дадут эффект для бизнеса;
есть список идей от бизнес и IT-команд, которые могут дать профит, но непонятно, что брать в первую очередь;
одновременно с этим списком идей будут работать несколько команд разработки
В общем, запрос на инструмент для приоритизации назрел, осталось только этот инструмент найти. Или создать.
RICE, или Почему мы решили изобрести велосипед
Прежде чем приступать к созданию нового, сначала решили изучить критичные недостатки старого.
RICE был хорош, но изменившиеся рыночные условия ярко подсветили его ограничения.
В нём не учитывались деньги, из-за чего невозможно было рассчитать окупаемость фичи.
Confidence почти ничем не отличался от скоринга на вижене, ведь чаще всего в нём использовались значения 50%, 80%, 100%. А какой продакт-оунер уверен в своей фиче менее, чем на 80%?
Reach иногда был устаревшим или слишком приблизительным. Зачем здесь жертвовать точностью, если можно подтягивать свежие значения из наших баз?
Отсутствовала гибкость: фреймворк не подходил для скоринга тасок для безопасности, службы поддержки, цепи поставок.
Итоговый скор был недостаточно прозрачным. Понятно, что 460 лучше, чем 350, но что конкретно это значит: немного или существенно лучше? Ценна ли гипотеза 1 сама по себе? Проще было бы использовать стобалльную систему.
Не было гибких настроек: что если для одних фич важнее окупаемость, а для других — уверенность в фиче? Как это учесть во фреймворке?
При этом у RICE были и плюсы: ребята уже привыкли скорить с его помощью, а время на переучивание стоило слишком дорого.
Поэтому, взяв за основу RICE и список фич из бэклога, мы сели рисовать идеальный фреймворк.
Идеальный фреймворк 1.0 и 2.0
Выгрузили все идеи в Miro, пытаясь где можно сохранить привычные составляющие. Получили RICE, но с дополнениями.
-
Reach — количество пользователей, которых затронет фича. Для выбора пользователей или сессий по определённым характеристикам использовались размеченные в приложении события с параметрами и пользовательские характеристики:
тип пользователя (новые, старые, все);
платформа (iOA, Android, web);
действия, которые пользователь должен был совершить;
и те, которых не должно было быть в пользовательском флоу.
Ease I — время на разработку фичи. Определялось разработчиками.
Ease II — время на разработку и запуск A/B теста по фиче.
Confidence — уверенность в гипотезе на основе результатов кастдевов, информации от коллег и экспертов.
Impact — количество денег, которые мы бы теряли, пока не выкатили бы, наконец, эту фичу или зарабатывали бы на ней.
Synergy — эффект от сочетания нескольких фич. Это казалось особенно классной идеей, потому что иногда пользователь одновременно сталкивается с ненативностью приложения, ошибками и ещё какой-нибудь фигнёй типа долгой загрузки. Все три проблемы кажутся важными. Но что если достаточно исправить всего одну и это значительно улучшит пользовательский опыт и уменьшит отток?
На этапе подготовки MVP пришла идея избавиться от лишнего, чтобы не перегружать фреймворк и быстрее перейти к его использованию. Так мы убрали симулятор фич (Synergy) и отдельное время на разработку АБ (Ease II).
В итоге фреймворк стал выглядеть так:
Reach и Impact рассчитывались для каждой гипотезы в Redash на лету по свежим данным. Усреднение происходило по месяцу, а информация о среднем чеке помогала учитывать две основные ситуации:
фича помогает конвертироваться тем клиентам, которые раньше не оформляли заказ;
фича работает на увеличение среднего чека.
Тест на продактах
Фреймворк скоринга был готов. Теперь дело за малым — научить им пользоваться и собирать обратную связь для улучшений. Мы решили «убить двух зайцев» и совместить обучение со скорингом тех идей, которым было суждено превратиться в единый бэклог. Сделали общий IT+бизнес воркшоп, на котором разделились на мини-группы, взяли все идеи и начали их скорить по новому фреймворку. Сначала каждая группа оценивала свой набор идей, выписывала, как она пришла к итоговому результату, с какими сложностями столкнулась. Затем отскоренные идеи презентовали остальным участникам.
На выходе собралась таблица с отскоренными идеями и куча инсайтов для улучшения фреймворка. К примеру, в чек-листе Confidence формулировки можно было считывать по-разному. Так, если человек верил в идею, абстрактные критерии позволяли накинуть несколько дополнительных баллов. В дальнейшем мы переписали критерии, чтобы все понимали их однозначно.
Также могли переоценить влияние в деньгах. Здесь помогла обратная связь от участников. Кроме того, мы договорились, что будем сравнивать план и факт, чтобы нарабатывать насмотренность. Ключевой вывод, который вынесли из этого воркшопа: скоринг не будет серебряной пулей. Это помощник, который позволяет отсечь лишнее, но решить за продакта, что делать, скоринг не сможет. Надо учитывать цели бизнеса, влияние решения на операционку пиццерий и т.д.
Ребрендинг
Новый фреймворк появился, а привычка мыслить по старому — осталась. Надо было отходить от прижившихся паттернов. Ребрендинг стал инструментом, который позволил не ограничивать себя рамками RICE и добавил гибкости оценке.
Так появился DODO Score.
Distribution — количество людей или заказов в месяц, для которых будет полезна фича (тут помогал дашборд в Redash для расчёта аудиторий).
Offering — потенциальный профит от фичи за 1 месяц (здесь мог учитываться средний чек по сконвертировавшимся пользователям или прирост среднего чека для текущих клиентов).
Developing — примерное время, которое будет затрачено на разработку: от нескольких часов до квартала. Например, выбор одной недели означает, что будут учитываться только 5 рабочих дней команды, которая работает над фичой. Проставляется либо разработчиком, либо продактом.
Objectiveness — уверенность в фиче, т.е. в тех результатах, которые мы от фичи ожидаем. Проходимся по чек-листу, выбираем нужные пункты и получаем итоговый скор.
Общий скор находится в диапазоне от 0 до 100. В такой системе координат легко ориентироваться: чем ближе к 100, тем лучше.
А для каждой составляющей (Distribution, Offering, Developing, Objectiveness) используется свой вес. Например, компоненты Distribution и Offering получили более высокие веса благодаря точности расчёта. Objectiveness и Developing могут рассчитываться излишне оптимистично, поэтому и веса у них ниже.
Изменение веса для каждого компонента помогает фреймворку оставаться актуальным для бизнеса:
для быстрых побед — больший вес у времени разработки (Developing) и как итог — у срока окупаемости;
для существенного прироста выручки будем корректировать веса Offering и Distribution;
если не хочется рисковать — увеличиваем вес Objectiveness.
А дальше что?
У нас появился свой Dodo Score, но мы только в начале пути к бриллиантовой приоритизации. Ведь мало только создать инструмент — важно, чтобы его использовали. Нам предстоит ещё прокачивать data-driven культуру в компании.
Кроме того, в нашем бэклоге не все задачи можно оценить в деньгах. Есть задачи, которые мы называем «UX без денег»: это когда у клиента болит, но это улучшение вряд ли принесёт нам миллионы. Здесь есть идея использовать логику Dodo Score, при этом вместо денег брать количество отзывов или коэффициент проблемности. Но об этом мы расскажем в следующий раз.
А какими фреймворками и лайфхаками для приоритизации пользуетесь вы? Любые рекомендации помогут нам и читателям узнать ещё больше об этой теме.