Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.
Тестирование гипотез в продуктовой команде является неотъемлемой частью успешного бизнеса, позволяющей принимать обоснованные решения на основе фактов, а не предположений, снизить риски и увеличить вероятность успеха продукта на рынке. В современном быстром темпе разработки, где требования пользователей постоянно меняются, тестирование гипотез обеспечивает высокую скорость адаптации к изменениям и инновационность продуктов, что делает эту тему актуальной и необходимой для компаний
В этой статье я хочу поделиться кейсом, как мы настроили процесс тестирования гипотез в одной продуктовой компании.
Ниже будет описан подробный гайд, как выглядит процесс, который можете брать за основу. А если нужна подробная консультация или внедрение смело обращайтесь ко мне напрямую в телеграм.
Как выглядит процесс?
Процесс тестирования гипотез мы визуализировали на Kanban доске (см. картинку ниже), которую сделали в Jira. Получился беклог гипотез на Домен, Отдельные представления на каждый юнит и продуктовую команду.
В этап Ideas Backlog каждый участник команды может положить идею.
Любую идею product manager на следующем этапе должен превратить в продуктовую гипотезу. У хорошо описанных идей гораздо выше шансы попасть в бэклог на проверку.
Как описать идею?
Максимально детально опишите идею. Постарайтесь структурировать описание так, чтобы оно отвечало SMART критериям. Нам пригодится любая информация.
Вопросы, ответы на которые нам сильно помогут.
Specific.
В чём идея? Какое изменение нужно совершить в продукте?
Какой результат мы ожидаем получить?
На какой сегмент клиентов направлено изменение? Кто получит выгоду?
Measurable.Как будем измерять результат?
По каким метрикам будем отслеживать прогресс достижения цели?
Какого значения метрики мы должны достичь, чтобы считать цель достигнутой?
Achivable.Почему считаем, что цель идеи достижима?
Что поможет в её достижении?
Что помешает достичь её?
Relevant.Какую проблему мы решаем?
Как идея соотносится со стратегией компании?
На какие стратегические цели направлена?
По возможности приведите ссылки на материалы, подтверждающие ценность и обоснованность идеи.
Time bound.Есть ли какие-то ограничения по времени? Чем они обсуловлены?
Какой желаемый срок реализации идеи?
Важно! Указанные временные рамки не являются коммитментом продуктовой команды. Конкретные сроки проверки гипотезы и сроки реализации определяет команда на следующих шагах процесса.
Источник. Опционально укажите, что является источником идеи, прикрепите ссылку на источник из базы
Например:
UX исследование,
Инсайт из данных,
Брейншторм команды,
Мнение стейкхолдера или члена команды,
Customer Service,
User Feedback,
Анализ выпущенных проектов и проверенных гипотез,
Рынок, тренды, медиа
Этап Refinement
Продакт выбирает из ideas backlog одну идею для уточнения и проработки.
Закончив уточнение гипотезы, product manager берёт в работу следующую гипотезу.
Как сформулировать гипотезу?
Проверьте корректность заголовка.
Заголовок должен максимально ёмко отвечать на вопрос “Что нужно сделать?” и отражать суть гипотезы.
Сформулируйте гипотезу.
Формат: Если <сделать следующие изменения в продукте> для <сегменты клиентов>, то <метрика> <вырастет/снизится> на Х <единица измерения>
Пример:
Изначальная формулировка идеи: Предлагать пользователю доп аксессуары при покупке смартфона.
Если мы будем предлагать пользователю добавить в корзину аксессуары при выбранном смартфоне, то увеличим средний чек покупки на Х % .
Переработайте и расширьте изначальную формулировку идеи, чтобы она максимально раскрывала гипотезу.
Некоторые вопросы которые помогут раскрыть идею:
Что должно измениться в продукте?
Какой результат ожидаем получить?
На какие сегменты клиентов направлено изменение? Какой будет охват? (не всегда нужно заполнять)
Какую проблему решаем/ цель преследуем?
Почему считаем, что проблема существует и важная/ цель релевантна? Приведите все ссылки на инсайты и материалы, подтверждающие проблему.
Почему считаем, что цель достижима? За счет чего?
Как измеряем результат? Какие дополнительные метрики, информационные метрики и контрметрики будем учитывать?
Есть ли какие-то ограничения по времени и чем они обусловлены?
В карточку Гипотезы в Jira мы вшили следующий шаблон, который автоматически заполняется при создании новой гипотезы:
Этап Hypothesis backlog
Исходя из собранных знаний о гипотезе, следует провести её оценку.
Оценка проводится коллективно, путём голосования в закрытую. В итоговый расчёт идёт среднее.
В голосовании участвуют:
Члены discovery team.
Автор идеи.
Релевантные эксперты, которые помогут точнее оценить гипотезу (разработчики, стейкхолдеры, кроссфункции).
Задача ответственного продакта - убедиться, что гипотезу оценили все люди, необходимые для точной оценки.
Если в оценках большой разброс - значит, гипотезу люди воспринимают неоднозначно и это сигнал к синхронизации/ доработке.
Оценка может и должна регулярно пересматриваться по мере появления новых знаний о гипотезе.
После этапа Refinement гипотезы требуется оценить по ICE.
Результат: Команда имеет оцененный бэклог и понимает какие гипотезы пойдут на следующий этап.
Стратегия компании и фокус меняется со временем, появляются новые вводные. Поэтому оценки необходимо пересматривать. Для нас пересмотр оценок был раз в квартал.
Этап Next
Важный этап выбора гипотез в работу. Раз в неделю команда собирается на планирование Discovery спринта и выбирает следующую гипотезу в работу, на основе ICE приоритета и общей дискуссии. Лимит на данную колонку = 1 в один момент времени.
Также на этой встрече команда решает каким способом они будут тестировать гипотезу и формирует план проверки гипотезы декомпозируя гипотезу на задачи которые необходимо сделать чтобы ее проверить.
Важно убедиться на встрече что есть ответы на все вопросы (часть из них может быть проработана ДО планирования”
Как выглядит опыт тестовой и контрольной группы?
На каких пользователях тестируем? (Какие пользователи и в какой момент становятся частью эксперимента).
Какой размер выборки пользователей для эксперимента?
Как долго будет длиться эксперимент?
Как измерим изменения? Достаточно ли метрик? Расширьте при необходимости набор.
Чётко и однозначно сформулируйте, что будет являться успехом проверки, а что нет.
Этап Discovery и инструменты проверки гипотезы
Один из самых важных этапов на котором осуществляется проверка гипотезы и запускается эксперимент
Главная задача Discovery Team на этом этапе - как можно меньшими ресурсами как можно точнее подтвердить или опровергнуть гипотезу.
Подумайте, как вы будете проверять гипотезу.
Понятно, что лучшая проверка гипотезы - рабочий продукт и реальные цифры. Но не всегда целесообразно применять весь арсенал способов для проверки.
Ваша задача - найти самый быстрый и дешёвый способ без привлечения разработки (или с минимальным ее привлечением).
При выборе набора инструментов руководствуйтесь пониманием о цене ошибки и цене упущенной выгоды.
Как пример, проверка гипотезы точно не должна быть дольше и дороже, чем воплощение задачи "на бою".
Некоторые возможные инструменты проверки:
Расчет экономической модели;
Коридорные тесты прототипа;
Опросы клиентов;
Fake feature в АБ;
Предпродажи;
Growth Hack;
Качественно-количественные UX тесты (first click, тест на понимание, немодерируемый тест и т.п.);
MVP;
И много других.
Итоговый дизайн эксперимента может совмещать в себе несколько способов проверки гипотезы.
Запустите эксперимент!
Важно не менять условия эксперимента по ходу его проведения, это может отразиться на корректности результатов и честности выводов.
Подведите итоги эксперимента.
Получилось ли достичь критериев успеха?
Корректно ли был проведен эксперимент?
Какие новые инсайты из эксперементы мы получили? Запишите их в базу инсайтов.
Поделитесь результатами с кем-то из коллег, попросите ревью эксперимента и выводов.
Этап Discovery done
Примите решение о дальнейших шагах.
По итогам гипотеза может либо превратиться в задачу и быть отправлена на следующий этап - Requirements, либо закрыта как неподтвержденная или нецелесообразная - перейти на этап Bin (корзина).
Также на этом этапе у нас был обязательный критерий, проведено review другими продактами. В конце Discovery спринта у нас была встреча Sprint review на которой каждый продакт рассказывал о результатах эксперимента и выводах, далее остальные продакты и участники Discovery команд накидывали вопросы. Это очень помогало шэрить знания, обмениваться опытом и задавать друг другу правильные вопросы.
Этап Requirements
Если гипотеза подтвердилась, то на этом этапе Продакт формулировал решение, описывал границы MVP. Часто для этого использовался инструмент User story mapping, который помогал разложить задачу на шаги пользователя и сформировать MVP решения. Здесь же прикидывались дизайн-макеты. Не чистовые варианты, а скорее драфты, которые далее можно было принести на PBR (грумминг) с командой.
Этап Bin
На любом этапе процесса мы можем отказаться от Гипотезы и перевести ее в статус Bin с соответствующим комментарием и обоснованием.
Этап Ready to Delivery
Подтвержденные гипотезы храняться в беклоге на разработку. Здесь же проводиться оценка по ICE по такому же принципу как я описал выше. Далее уже при планировании разработки вытягивается следующая задача находящиеся сверху.
Метрики
Для того чтобы отслеживать эффективность процесса мы внедрили ряд метрик.
Ключевая метрика успеха Discovery процесса:
% зеленых тестов после разработки фичи. Что такое зеленый тест? Если после разработки любой фичи она проходит А/В тест и версия с новой фичей показывает рост метрик, то тест зеленый, если роста нет - серый, если провал по метрикам - тест красный.
Discovery процессы нам нужны для того чтобы увеличивать confidence (уверенность в том что фичу нужно делать) и тогда после ее разработки % зеленых тестов будет выше. Для этого мы и начали строить процессы Discovery.
Но на количество зеленых тестов сходу не повлияешь, для отслеживания прогресса нужны контр метрики, через которые мы можем влиять на % зеленых тестов, например:
Количество гипотез, проверяемых за период
Средняя скорость проверки гипотез
Отношение подтвержденных гипотез к выброшенным
Данные метрики анализировались на каждой ретроспективе после Discovery спринта. Мы смотрели динамику и то, как у нас работает процесс, как меняются контр метрики и как от них зависит целевая метрика.
Как процессы Discovery экономят деньги?
Процессы Dsicovery улучшают confiedence, уверенность в том, что фичу нужно делать. Поэтому при успешных процессах Discovery количество задач приносящих эффект увеличивается, а следовательно вы экономите деньги на разработанных впустую фичах.
Если понравилась статья, жду вас на своем бесплатном вебинаре, где рассмотрим кейсы и примеры Канбан систем. Также подписывайтесь на мой телеграмм канал и приходите на консультацию.
