{"id":14286,"url":"\/distributions\/14286\/click?bit=1&hash=d1e315456c2550b969eff5276b8894057db7c9f3635d69a38d108a0d3b909097","title":"\u041f\u043e\u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430\u0434 \u043a\u0440\u0443\u043f\u043d\u0435\u0439\u0448\u0438\u043c\u0438 \u0418\u0422-\u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c\u0438 \u0441\u0442\u0440\u0430\u043d\u044b","buttonText":"","imageUuid":""}

Как тестировать в два раза больше гипотез в 2 раза быстрее?

Как я делаю в своих проектах:

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

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

Как делаю я (тезисно)

  • Все гипотезы хранятся в отдельном документе - мой шаблон
  • Гипотезы регулярно обсуждаются, правильно приоритизируются по системе RICE и правильно формулируются
  • Количество гипотез четко регламентируется. Вместимость лога и пропускная способность команды для тестировать
  • Обязательно делать выводы по каждой гипотезе

Ну теперь давайте по порядку. Начнем с хранилища...

Лог-гипотез - место в котором хранятся все гипотезы и куда они вносятся. В чем польза этого документа?

  • Гипотезы не теряются
  • Команда не прибегает к руководителю с предложениями. Все вносится в лог гипотез и обсуждается на очередной встрече

Лог не резиновый и у него должна быть определенная емкость. В моем случае это 40 гипотез. Когда что-то реализуется, на освободившееся место пишется новая. Таким образом вы не будете обсуждать 400-500 гипотез, каждую встречу)

Как приоритизировать, как формулировать, как обсуждать?

Тут есть ряд строгих правил, которые нарушать нельзя.

  • 2-3 минуты на презентацию гипотезы. Если гипотезу нельзя презентовать за 3 минуты, это не гипотеза, это проект
  • 1 минуты на обсуждение и оценку
  • Четкое кол-во гипотез берутся в реализацию на четкий период
  • Обязательный отчет по тестированию

Давайте буду на своем примере рассказывать с примерами.

Обсуждение 1 раз в 2 недели. Встреча регулярная, стоит у каждого в календаре, каждый знает о ней и готовится.

На встрече есть так называемый Growth master, который ведет встречу и следит за таймингом. В моем случае это делаю я.

Моя задача следить, чтобы гипотеза презентовалась быстро, не вызывала много вопросов и её можно было легко оценить (Как? Расскажу чуть позже). Если тайминг тянется, я раздаю лещей и переключаю команду к следующей гипотезе.

Авторы презентуют свои гипотезы и после каждой гипотезы, ВСЕ участники встречи ставят оценку (субъективно) по системе ICE.

ICE - система оценки Impact, Confidence, Ease по 10 бальной шкале.

I - Влияние на результат
C - Влияние на результат
E - Легкость реализации

Давайте на примере. Есть гипотеза, "Заменив текст на главном баннере, мы можем увеличить конверсию на 0,1%". Я ставлю оценку...

I - Сильно повлияет? Нуууу давайте так, на 3.

С - Повлияет на результат? У человека будет много шагов помимо этого (каталог, корзина, оплата и т.д) и я думаю, что это влияет, но не критично. Оценка 3

Е - Легко ли это? Да, точно легко! Моя оценка 10

Итог: 3+3+10=16 моя оценка для данной гипотезы.

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

Команда не обсуждает гипотезы, которые уже оценили. Обсуждаются новые гипотезы. Так мы не обсуждаем 100 раз одно и тоже.

Ну а как же их формулировать?

Гипотеза становится гипотезой после формулировки...

"Если мы сделаем N, это может улучить N, на N"

Гипотезы без этой формулировки отправляются автору и обсуждаются на следующей встрече.

Как делаются выводы?

У каждой гипотезы есть ответственный (проджект), который отвечает за реализацию. Он же ОБЯЗАН предоставить отчет об эффективности к следующей встрече.

Ну вот на примере выше, у проджекта есть 2 недели, чтобы заменить текст, проверить А/Б тестом или по другому и сделать выводы в формате БЫЛО/СТАЛО. После чего мы определим делаем дальше или отметаем.

Автор гипотезы может, но не обязан её реализовывать.

Какие выводы

-- Хотите расти? Тестируйте больше

-- Чтобы тестировать эффективно внедряйте регламенты

-- Встречу курирует growth master и он не должен быть мягким

-- Чтобы у команды была мотивация, внедряйте бонусы (для всех реализаторов, не только для автора)

-- Подход ICE подошел мне больше, он простая, но альтернатив много.

Полезное:

Шаблон лога гипотез - клик

Ну и скромненько мой TG канала - клик

Мой личный TG. Пишите в ЛС, отвечу на вопросы и помогу с тем, что не понятно.

0
Комментарии
-3 комментариев
Раскрывать всегда