Brainstorm, RICE, HADI или как решать сложные задачи

Недавно меня спросили про амбициозную задачу из моего рабочего опыта, которую непонятно было как решить.

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

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

Поэтому давайте рассмотрим следующую задачу: «Нам нужно вырастить Consent Rate пользователя в 2 раза»

Брейншторм

Брейншторм — это процесс, в котором команда собирается вместе и начинает накидывать идеи, которые смогут решить поставленную задачу. Главная задача брейншторма — накидать как можно больше идей, чтобы отмести 80% из них и начать разрабатывать первые 20%, которые могут стрельнуть. Идеи могут быть любыми, абсолютно безумными.

Давайте рассмотрим пример брейншторма, который мог бы быть при решении данной задачи:

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

2. Показывать пользователю картинку, что если он не нажмет на разрешение отслеживания, то мы украдем его кота

3. Угроза физической расправы при отказе от отслеживания

4. Метод трех кликов. Перед этим разрешением спрашивать у пользователя еще два каких-то бесполезных разрешения, чтобы на третье он уже кликнул методом: «Да, да, да, дайте поиграть»

5. По-братски попросить дать нам разрешение отслеживать его IDFA

6. Давать бонусы в игре на старте, если пользователь поделился своим ID

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

1. Чуть-чуть закастомить разрешение на отслеживание, чтобы пользователь не думал, что мы пытаемся украсть все его личные данные (что очевидно так, но ему так думать не надо)

2. Показывать окно позже, чтобы пользователь поиграл пару минут в приложение, а уже потом спрашивать об ID. Логика: «Ну ладно, ребята вроде нормальные, им не жалко»

Итого, по итогам брейншторма у вас сформировалась таблица с гипотезами.

RICE

На самом деле, в данном примере нам больше подходит методология ICE, но расскажу я про обе.

RICE — Reach Impact Confidence Effort.

Каждый из этих параметров оцениваем по шкале от 1 до 10.

Reach — сколько пользователей затронет наше изменение. Пример: мы улучшили путь от нажатия на кнопку купить до списывания денег с карты и получения бонуса от покупки. Так как в нашем приложение примерно 40% плательщиков, то считаем, что мы охватим 40% людей. В целом можно считать, что оценка этого параметра в данном случае — 4.

Impact — какой эффект будет от данного изменения на людях, которых мы этим изменением охватим. Так как баллы выставляются субъективно, то хорошей практикой будет брать РЕАЛЬНЫЕ МЕТРИКИ С ПРОЕКТА, а не «я вам отвечаю х2 сделаем». Но это так, лирическое отступление. Пример: возвращаемся к нашей изначальной задаче и оцениваем манипуляции физической расправой. Вы с командой решили, что в целом звучит хорошо, но кажется это принесет от силы 2% сверху, поэтому оцениваем эту Impact на 1 (все субъективно и обсуждается с командой, главное — логика для оценки всех гипотез одинаковая)

Confidence — насколько вы уверены в вашей гипотезе. Пример: возвращаемся к манипуляциям физической расправой. Ну кажется, что пользователя может не заинтересовать продукт, который просит ID, по которому можно вычислить где он живет, и говорит, что если он этого не сделает, то к нему применят санкции. Поэтому и Confidence мы оцениваем на 1.

Effort — сколько времени понадобиться, чтобы реализовать фичу. Можно использовать сторипойнты, как отправную точку и делить их на 5. Пример: возвращаемся к той же самой фиче. Разработчик говорит: «Работы на час максимум». Но мы все же оценим Effort на 2, а то знаем мы этих разработчиков.

Итого: у вас получились комбинация очков. Итого RICE расчитывается по формуле:
RICE = (Reach Impact Confidence)/Effort

В нашем случае (давайте не будем докапываться, что примеры разные для каждой метрики) получается
RICE = 2

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

Тут добавляется новый параметр:
Ease — насколько просто будет реализовать фичу. Условно метрика, обратная Effort. В нашем случае она получится 8.

ICE = 32

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

Методология HADI

Основа нашего теста будет заключаться именно в HADI методе.
HADI — Hypothesis Actions Data Insights
Hypothesis — Гипотеза. Фраза строится как «Я думаю, что если я сделаю А, то получится В»
Actions — Действия. В нашем случае разработка и внедрение этого в проект.
Data + Insights — Данные и инсайты из данных. Я лично считаю, что если вы как аналитик собрали данные, и не извлекаете из них инсайты, то вы дурак, поэтому не вижу даже смысла разделять эти два пункта.
Инсайт — некий прикол, который вы нашли в данных и можете его использовать для дальнейшего роста продукта.

Далее вы двигаетесь по этому круговороту жизни в соответствии с вашей табличке с оценкой гипотез по ICE/RICE, как нарисовано на картинке выше.

Вы спросите меня: «А зачем мне вообще HADI, если я могу просто проверять гипотезы одну за одной».
А я вам отвечу: HADI не преследует цели последовательной проверки гипотез. Эта методология нужна для того, чтобы извлекать инсайты, и корректировать стратегию по достижению результата.

К примеру вы поняли, что в целом угрозы физической расправы поднимают конверсию в положительный ответ на ATT окно, но у вас ухудшается Retention. Ну не предусмотрели вы, что пользователю может не нравится, что ему угрожают с первых минут использования приложения, и он в целом его удалил. В таком случае все гипотезы, которые связаны с угрозами, вы забракуете и не будете их даже тестить, как бы они не находились высоко в скоринге.

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

Вывод

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

А если вы хотите почитать еще про развитие в аналитике данных: телеграм-канал