Настройка командной работы на кратный рост: 7 инсайдов
Начитавшись полезных книг из серии Lean Startup я попытался применить, что там описано в рабочий процесс реальных команд. Благо, “подопытных” команд было достаточно, поскольку давно являюсь трекером и участником образовательных программ в нескольких акселераторах. Эксперименты шли больше года и вот основные инсайды, что удалось словить.
1. Что вообще такое гипотеза?
Чтобы обесценить любой маркетинговый план можно, выдержав небольшую паузу, в ответ небрежно сказать “ведь это всего лишь гипотеза”. Но что на самом деле гипотеза? Насколько маркетинговый план является гипотезой? Улучшения в канале привлечения является гипотезой роста? А если надо поправить семантические опечатки в объявлениях? Рост будет не заметным, но и оставлять ошибки нельзя. Где грань между просто задачей и гипотезой роста?
Наличие предполагаемого количественного улучшения в метриках делает задачу гипотезой роста, в какой-то момент решили мы. Это самое простое определение, его легко понять и легко формулировать следующим образом:
Если <действие>, то <изменение метрик>
Если записывать гипотезу на стикер, то можно разделить его горизонтальной чертой и в верхней части писали действие, а в нижней - ожидаемый результат.
Мы получили инсайд чуть позже, когда начали вешать гипотезы и задачи на одну доску. Оказалось, что гипотезы тянули проект вперед, а задачи отвечали за рутину, которая позволяла не откатываться назад. Удивительно было то, что мы научились регулировать скорость роста. Если мы видим на доске задач 2 гипотезы роста и 7 задач, то это сообщение нам, что мы мало внимание уделяем росту. Когда это стало наглядно, команды перестали себя обманывать, что делают все возможное, чтобы расти и научились балансировать между ростом и рутинными задачами.
2. Тестирование гипотез
В процессе тестирования гипотеза должна пройти путь через цикл Build -> Measure -> Learn. В русскоязычном интернете, часто используются HADI циклы (Hypothesis, Action, Data, Insight), что означает цикл от гипотезы, через реализацию и сбор данных к выводам.
Но на практике все оказалось куда сложнее. Какие-то гипотезы могли тестироваться несколько дней, какие-то несколько недель. Где-то обсуждались результат теста и получали инсайд, а иногда даже не собирали данные по гипотезе.
Единого процесса не было, пока мы не попробовали кое-что из Скрама. Уже на второй спринт были улучшения в командной работе, которые отметили все участники. Из Скрама мы взяли Планирование Спринта в одно и то же время каждую неделю, где обсуждали, какие гипотезы будем тестировать, Ежедневные Встречи на 15 минут каждое утро, что здорово мешало реализовывать гипотезы в последний момент, Обзор Спринта перед Планированием Спринта, где делали вывод по каждой гипотезе. Не все проблемы были решены, но этого было достаточно, чтобы не браться за слишком большие гипотезы, успевать тестировать то, что запланировали и обсуждать результаты.
Еще один большой шаг в сторону прозрачности процессов стала канбан доска с HADI циклом.
Все идеи, которые мы придумывали на Планировании спринта, мы записывали в первую колонку. Гипотезы в работе попадали во вторую колонку. После исполнения гипотез перемещали в третью колонку, чтобы собрать данные. После сбора данных гипотезы попадали в четвертую колонку, где надо было указать или проговорить вывод для каждой.
3. Исполнение задач
То, что у нас появилась доступная для всех доска с гипотезами, сильно упорядочило работу с гипотезами. Наши ежедневные встречи стали проходить продуктивнее, однако мы обнаружили проблему на уровень глубже. Большинство гипотез содержало несколько подзадач для разных сотрудников. На доске с гипотезами для них не было места. К тому же всегда есть текущие задачи. Как управлять исполнением задачами было не понятно.
Мы решили эту проблему, установив еще одну доску, но уже с задачами следующего вида.
В первом столбце располагались гипотезы продублированные с из второй колонки доски с гипотезами. Напротив каждой гипотезы располагались задачи актуальные только для нее. Под гипотезами был бэклог то есть рутинные задачи.
То что мы задачи по гипотезам и рутинные задачи бэклога располагались на одной доске еще раз наглядно показывала насколько мы движемся вперед или же пытаемся не скатиться назад.
4. Кто отвечает за измерения?
Продвигаясь дальше в наших улучшениях мы нашли новую проблему - сбор данных. Измерения не всегда делались, часто запускались с задержкой или ошибкой. Например, часто ошибки были в UTM метке или целях. Однако, сбор данных это слишком критически важное действие в процессе Build Measure Learn.
Решение оказалось очень простым – ввести роль аналитика данных и назначить туда сотрудника, у которого самым большой опыт в web аналитике. Он должен отвечать за корректный сбор данных по всем гипотезам. Перед перемещением гипотезы в третью колонку он должен перепроверять, как собираются данные. Он должен отчитывался по результатам проверки гипотез на Обзоре спринта.
Никто не отвечает за аналитику, если за нее отвечают все. Роль аналитика должна быть в каждой Команде Роста.
5. Информационный вакуум
Назначив роль аналитика по проекту, мы решили одни проблемы, но всплыли другие. Теперь все коллеги беспокоили аналитика, когда им нужны были данные. Это было особенно неудобно, поскольку часто приходилось совмещать работу аналитика с должностью маркетолога или программиста. Коллеги по несколько раз в день уточняли, какой результат тестирования гипотез.
Практика, ставить монитор с метриками в общей комнате, помогла решить эту проблему. Аналитик выводил все текущие эксперименты и ключевые параметры на экран. Это прекрасно ложилось в концепцию Shared Understandings, когда вся команда должна находиться в едином информационном пространстве.
6. Измерения могут врать
Мы заметили, что рост метрик в успешно протестированных гипотезах откатывался назад иногда уже на следующий спринт. Дошло до того что пришлось попросить аналитика более внимательно покопаться в данных.
Результат сильно нас удивил и огорчил. Оказалось, что большинство проведенных экспериментов показывали улучшения в рамках статистической погрешности, и им нельзя было верить.
Инсайт: Необходимо задумываться о статистической значимости эксперимента до его начала. Ожидаемая цель роста может быть статистической ошибкой или случайностью.
Оказалось, очень часто мы тестировали улучшения конверсии в канале привлечения, где слишком мало пользователей. Выбирали не достаточно большой период тестирования. Да, это очень точная работа с калькулятором, и очень специфические знания в математической статистике, но она может помочь не тратить время на бесполезные гипотезы.
7. Постоянные улучшения
Как вы видите, мы постоянно искали слабые места в нашей командной работе и устраняли их. В этом нам очень помогал еще один принцип из Скрама Ретроспектива спринта. В конце каждого спринта мы задавали четыре простых вопроса и искали ответы:
1. Что шло хорошо в прошлой итерации?2. Какие проблемы были в прошлой итерации?3. Какие идеи появились по ходу ретроспективы?4. Какие улучшения мы запланируем на следующую итерацию?
В итоге команды ускорили свой рост до 3-4Х в квартал и считают своим главным конкурентным преимуществом не свое ценностное предложение на сайте, а то что внутри команды есть то, что позволит им быстро расти и реагировать на изменения у конкурентов.
Хотите быстро расти как стартап? Записывайтесь на курсы от Growth Academy. Научим тетсировать гипотезы роста бизнеса, и расти кратно быстрее конкурентов.
