A/B-тестирование — все еще единственный достоверный способ проверить гипотезы и влияние изменения на продуктовые метрики.
Что нужно сделать, чтобы провести A/B-тестирование:
- Выделить две сбалансированные группы: тестовую и контрольную.
- Настроить показ новых функций тестовой группе, а старых — контрольной.
- Ждать, когда прокрасится A/B-тест.
Когда я работал в Skyeng, мы разработали фреймворк, который состоит из 9 шагов до проведения A/B-тестирования. С внедрением и оптимизацией этих шагов у нас появилось больше шансов продуктивнее проводить A/B-тесты.
Сейчас я работаю в «Кухне на районе» и не использую ничего из перечисленного. Я планирую работу своей команды из одного разработчика максимум на 2 недели вперед. Перечисленные пункты больше подходят для крупных ИТ-компаний, где очень высока цена ошибки, а пара процентных пунктов конверсии из одного шага в другой стоит миллионы.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Брейншторм
Чтобы упорядочить процесс генерации идей, важно сфокусировать команду вокруг определенных метрик. Например, мы задаем вопрос: «Что нужно сделать, чтобы на первый пробный урок выходило больше людей, чтобы пользователи быстрее оплачивали курсы?», а затем генерируем гипотезы по нужной нам метрике.
Что получаем: список гипотез по каждой метрике.
Описание гипотез
На следующем этапе мы заполняем сводную таблицу со списком гипотез, описываем к каждой гипотезе пользовательские истории. Еще прописываем, как можем проверить гипотезу, какой критерий успешности будем использовать. Это позволяет понять, какую проблему будет решать команда, какие гипотезы будет проверять. Некоторые гипотезы на этом этапе мы сразу отметаем, и это экономит время команды.
Что получаем: список хаотичных идей превращается в документ, с которым можно работать.
Командная приоритизация по RICE
Далее мы делаем сводную таблицу с RICE-приоритизацией. Это своего рода отскоренный шорт-лист гипотез, в которые верит команда. Мы делаем отдельную вкладку на каждого участника команды напротив одной гипотезы в Google Таблицах. Так за одну гипотезу отвечает конкретный человек. После первичного голосования по системе RICE важно дать каждому участнику команды защитить свою гипотезу, а затем при необходимости переголосовать.
Что получаем: команда принимает взвешенное решение.
Приоритизация по ROI
Показатель ROI — это коэффициент окупаемости вложений, который мы используем, чтобы понять, сколько денег уйдет на реализацию конкретной фичи. На этом этапе мы узнаем, сколько дает прирост одного процентного пункта к нашей метрике. Это позволяет понять, какой шаг воронки выгоднее оптимизировать. Затем команда делает прогноз по каждой из гипотез. Например, оценивает, сколько будет стоить новая фича, где и насколько можно сократить косты.
Что получаем: получаем ROI гипотезы, по которым можно отскорить убыточные проекты.
Комит в метрики
Далее мы делаем переход от проектов к метрикам, которые они растят. Здесь важно показать, как изменятся метрики после внедрения определенной фичи. Мы создаем таблицу с вкладками «Сейчас» и «Будет», где фиксируем изменения в процентном соотношении.
Что получаем: комит, при котором вы гарантированно заработаете денег как команда, независимо от того, получится ли запустить тот или иной проект.
Проджект-план
На этом этапе мы декомпозируем задачу на этапы, выделяем роли и намечаем календарный план. Это помогает увидеть пересечения ресурсов. Например, из таблицы мы видим, что у дизайнера десять задач в день в один период.
Что получаем: план работы на ближайшее время с понятными пересечениями, которые можно вовремя поправить.
Валидация гипотезы
Дальше нужно провести кастдев: выделить гипотезы, сконвертировать их в вопросы, пообщаться с 5-10 клиентами. Эти инсайты помогут при проектировании.
Что получаем: понимание, что важно и неважно, чему уделить больше всего внимания.
Коридорный тест/UX-тест
На этом этапе мы собираем прототип своего решения. Важно отметить, что при сборке прототипа полезно обсуждать вопросы с коллегами не из ИТ, а из смежных отделов. Например, с юристами и финансистами.
Что получаем: список доработок до передачи в разработку.
Быстрые тесты
На этом этапе мы стараемся придумать, как «захардкодить» что-то в Google Таблицах или договорившись с тим-лидом, чтобы не уходить на три месяца в разработку.
Что получаем: первые данные по воронке, на основе которых можно построить прогноз.
Чек-лист подготовки к сплит-тестированию:
- Брейншторм идей
- Описание гипотез
- Командная приоритизация по RICE
- Приоритизация по ROI
- Комит в метрики
- Проджект-план
- Валидация гипотезы
- Коридорный тест/UX-тест
- Быстрые тесты
Если проделывать эти шаги до проведения сплит-тестирования, то у команды появляется больше шансов сдвинуть метрики и не потерять деньги.
Посмотреть полное видео доклада Алексея Проворова с конференции Product Mindset можно по ссылке.
