Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл‑трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом
Тестирование гипотез — это неотъемлемая часть любой продуктовой разработки. Оно позволяет принимать решения, основанные на данных, а не на догадках, минимизировать риски и увеличить вероятность успеха на рынке.
Разработка — это дорогостоящий и ограниченный ресурс, поэтому важно сосредотачиваться на задачах, которые напрямую влияют на рост продуктовых метрик и выручки. Эффективный Discovery процесс позволяет минимизировать потери, исключая неэффективные продуктовые решения, и тем самым оптимизирует вложения в разработку.
В этой статье я расскажу, как мы наладили процесс тестирования гипотез в одной из продуктовых компаний. Это гайд, который вы можете взять за основу. Если вам потребуется помощь с внедрением, смело обращайтесь ко мне в Telegram.
Как устроен процесс?
Мы визуализировали процесс тестирования гипотез на Kanban‑доске, созданной в Jira. Эта доска включает общий бэклог идей, отдельные представления‑доски для каждого юнита и продуктовой команды. Важно, чтобы доска была интуитивно понятной и легко доступной для всех участников, так как прозрачность — основа успешного процесса.
Ниже рассмотрим ключевые этапы и критерии успешности выполнения этапов прохождения процесса Discovery.
Этап 1: Ideas Backlog
Любой член команды может добавить свою идею в эту колонку. Чем детальнее будет описание идеи, тем выше ее шансы попасть в бэклог проверки. Мы стараемся мотивировать участников использовать четкие формулировки и структуру, чтобы минимизировать недоразумения и ускорить последующую работу.
Какие идеи принимаются?
Идеи могут быть самыми разными — от мелких улучшений UX до кардинальных изменений продукта. Источники идей включают:
Анализ данных и поведения пользователей;
UX‑исследования;
Отзывы от клиентской службы;
Брейншторм команды или инсайты стейкхолдеров;
Тренды и конкурентный анализ.
Идеи оформляются по SMART‑критериям:
Specific (конкретность):
Опишите суть идеи, целевой результат, сегмент пользователей.Measurable (измеримость):
Какими метриками будем отслеживать изменения? Какое значение метрики покажет успех?Achievable (достижимость):
Обоснование, почему цель достижима. Что может помешать?Relevant (релевантность):
Как идея решает проблему? Соответствует ли она стратегии компании?Time‑bound (ограниченность во времени):
Определите сроки. Если есть временные ограничения, объясните, чем они обусловлены.
Важная часть — привязка идей к реальным данным. Например, ссылки на отчеты, результаты исследований или показатели аналитики. Это помогает сократить время на этапах обсуждения и оценки.
Идеи разбираются на командных встречах.
Этап 2: Refinement
На этапе «Refinement» продакт‑менеджер берет одну из идей из бэклога и превращает ее в гипотезу. Этот процесс требует глубокой проработки, чтобы гипотеза была четкой, а ее проверка — максимально эффективной.
Как описать гипотезу?
Гипотезы формулируются в формате:
Если <внести изменение в продукт> для <сегмента клиентов>, то <метрика> <увеличится/уменьшится> на Х.
Например:
Если предложить аксессуары при покупке смартфона, то средний чек вырастет на 10%.
Чтобы гипотеза была принята, нужно ответить на ряд ключевых вопросов:
Какое конкретное изменение мы вносим?
Какие сегменты клиентов охватит гипотеза?
Почему мы считаем, что эта проблема актуальна?
Какие дополнительные метрики помогут оценить результат?
После этого гипотеза переходит в Hypothesis Backlog.
Этап 3: Hypothesis Backlog
На этом этапе гипотеза проходит оценку по модели ICE (Impact, Confidence, Ease).
Impact (влияние): Насколько сильно гипотеза может повлиять на метрики бизнеса?
Confidence (уверенность): Насколько мы уверены в данных, которые лежат в основе гипотезы?
Ease (простота): Насколько легко и быстро можно проверить гипотезу?
Голосование проводится коллективно, включая автора идеи, discovery team и экспертов. Если оценки сильно различаются, это сигнал к доработке гипотезы.
Важный момент: мы регулярно пересматриваем оценки гипотез, особенно если появляются новые данные, которые могут повлиять на их приоритет.
Этап 4: Next
Еженедельно команда проводит планирование Discovery‑спринта. Здесь выбирается гипотеза для проверки, определяется метод тестирования и декомпозируется план.
На этом этапе задаются ключевые вопросы:
Какие пользователи попадут в тестовую и контрольную группы?
Какой объем выборки необходим?
Как долго будет длиться эксперимент?
Какие инструменты помогут провести тестирование быстрее?
Примеры инструментов для проверки:
Прототипы и коридорные тесты;
Опросы и интервью с клиентами;
Fake feature (фиктивная функция);
MVP (минимально жизнеспособный продукт).
Этап 5: Discovery
Discovery — это сердце процесса тестирования гипотез. Здесь команда с минимальными затратами проверяет, действительно ли гипотеза имеет потенциал.
Важный принцип: эксперименты должны быть короткими и дешевыми. Это снижает риски и позволяет протестировать больше идей за меньшее время.
Этап 6: Discovery Done
По завершении эксперимента команда делает вывод:
Гипотеза подтверждена — она переходит в Requirements.
Гипотеза опровергнута — она закрывается.
Результаты обсуждаются на спринт‑ревью. Это помогает всей команде извлечь уроки и улучшить процесс.
Этап 7: Requirements
На этом этапе подтвержденная гипотеза превращается в задачу для команды разработки. Здесь формируется MVP, создаются пользовательские сценарии, прорабатываются макеты.
Этап 8: Ready to Delivery
Готовые задачи попадают в бэклог разработки. Здесь важно сохранить приоритеты, установленные ранее, и следить за выполнением задач в срок.
Эти шаги позволяют команде выстроить четкий процесс тестирования гипотез, минимизировать риски и сосредоточиться на действительно ценных задачах. Если вы хотите внедрить такие процессы в своей компании, пишите мне, и я помогу вам с этим.
Ключевые контрольные точки в процессе
В процессе Discovery предусмотрены важные контрольные точки с участием CPO и Product‑лидов. Их задача — валидировать гипотезы перед тем, как они попадут в разработку. Это исключает возможность формального прохождения процесса: каждый Product‑менеджер должен обосновать гипотезу, используя данные и результаты тестов.
Две основные контрольные точки:
После подтверждения проблемы пользователя
На этом этапе проводятся качественные и количественные исследования, которые доказывают, что заявленная проблема действительно существует и актуальна для целевого сегмента пользователей.После проверки решения
Следующая валидация проводится после тестирования предполагаемого решения. Это может быть прототип или другой способ проверки, который демонстрирует, что решение эффективно и способно устранить выявленную проблему.
Как мы изменили культуру в компании?
Благодаря внедрению этого процесса мы кардинально изменили подход к разработке и отношение сотрудников к работе с задачами. Теперь каждая идея изначально рассматривается как гипотеза, требующая проверки.
Ключевые изменения:
Нельзя передать задачу в разработку без прохождения этапов Discovery и обоснования ее ценности.
Разработка активно участвует в процессе: инженеры задают вопросы и челленджат задачи, оценивая их с точки зрения бизнес‑ценности и соответствия стратегическим целям.
Такой подход не только повышает качество задач, поступающих в работу, но и формирует культуру осознанного использования ресурсов компании.
Метрики успеха Discovery процесса
Основной индикатор успешности Discovery — доля «зеленых» тестов после АВ. Это гипотезы, которые после реализации показывают рост метрик. Тк разрабатывать фичу дорого и долго, то за счет процессов Discovery мы отбрасываем невалидные идеи раньше недопуская их проход в разработку.
Чтобы отслеживать как работает Discovery процесс, мы используем метрики:
Количество гипотез, проверенных за период.
Средняя скорость проверки.
Соотношение подтвержденных гипотез к отвергнутым.
Эти данные анализируются на ретроспективах Discovery команды, чтобы улучшать процесс.
Как Discovery помогает экономить?
Эффективные Discovery‑процессы увеличивают уверенность в выборе задач, что позволяет избегать затрат на ненужные фичи. Это экономит ресурсы и ускоряет выход полезных решений на рынок.
Больше актуальных навыков по управлению продуктами и проектами вы можете получить в рамках практических онлайн‑курсов от экспертов отрасли.
24 декабря пройдет открытый урок, посвященный роли Product Owner. На встрече сформируете чёткое представление о позиции Product Owner и навыках, которыми он должен обладать. Если интересно, записывайтесь по ссылке.
