Давно не было чисто продуктовых материалов и сегодня исправлю это упущение. Всё равно достойных материалов по геймдеву в руки не попадалось давно. Речь пойдет про A/B тесты, а точнее о том, как на практике реализовать подход к ним, чтобы проводить их систематически и оптимизировать подход к выбору гипотез. Описанный подход используется в skyeng и для многих будет избыточен, но определенные этапы, на мой взгляд, стоят того, чтобы внедрить.
Этап планирования.
1. Брейншторм идей (1 день)
Составляется список метрик, которые хотелось бы подтянуть, проводится брейншторм с привлечением команды и набрасывается список гипотез для каждой метрики
2. Описание гипотез (2 дня)
Если всё начинается с неформализированных идей в стиле "А давайте сделаем вот так", то на данном этапе приводится к описанию конкретной юзерстори для данной гипотезы, описание как будем проверять и оценивать успешность
3. Командная приоритезация по RICE (2 дня)
Проводится RICE приоритезация с участием команды, трема довольно объемная, отдельно останавливаться не буду сейчас, можно найти в нете, к примеру
тут
Важный момент - оценка проводится каждым членом команды, после происходит обсуждение, где каждый может защитить свои расчет, после все производят переоценку.
4. Приоритезация по ROI (3 дня)
Дальше стоит прикинуть влияние на ROI изменения каждой метрики. К примеру берем отвал на первом уровне и прогнозируем как его уменьшение на один процентный пункт повлияет на доход игры. Затем мы оцениваем каждую гипотезу и прикидываем на сколько процентных пунктов она изменит метрику. От отдела разработки мы узнаем ориентировочную стоимость данного эксперимента.
Для того, чтобы оценивать влияние реализации каждой гипотезы стоит начать проводить эксперименты и оценивать результат по факту. Накопив некоторый опыт получится оценивать по аналогии. В итоге получаем таблицу соотношение трудозатрат и теоретических результатов, на основе которой подбираем гипотезы, которые войдут в спринт.
5. Расчет влияния на метрики (2 дня)
Составляем табличку где указываем текущее состояние метрик проекта и теоретическое, после внедрения выбранных гипотез.
6. Проджект план (2 дня)
Дальше составляется проджект-план, в которым гипотезы декомпозируются на задачи, выделяются роли и всё это наносится на календарь. Главная задача не столько получить четкий план с дедлайна, сколько понять где происходит пересечение ресурсов и продумать эти моменты.
Этап реализации.
7. Валидация гипотезы, custdev (1 неделя)
Формулируются вопросы касательно каждой гипотезы, задаются клиентам. Полученные инсайты используются при проектировании, становится ясно на что обратить больше внимания.
Может проводиться и на более ранних этапах, но поскольку это значительно дороже по ресурсам, чем планирование разработки функционала, лучше делать после создания проджект-плана, когда есть точное понимание затрат ресурсов
8. Коридорный тест / UX-тест (1 неделя)
Когда дизайнер заканчивает первую итерацию макетов их есть смысл показать стороннему человеку, в идеале не из IT, чтобы получить фидьэк о исправить UX/UI ошибки до передачи в разработку.
9. Качественные тесты (2 недели)
Собирается прототип функционала, возможно далекий от идеала по оптимизации, но достаточный для того, чтобы проверить отвечает ли он требованиям к тесту
10. A/B тест (2 месяца)
Сам A/B тест, выделяются 2 группы пользователей, одни получают продукт без применения гипотез, другие с ним.
11. Внедрение результата
Источник (30 мин.):
https://www.youtube.com/watch?v=C1hlw6bz1Tc&feature=youtu.be