Шаблон для формулирования гипотез: 5 пунктов, чтобы оформить идею

127
#Разработка 10 сентября 2020
  • Дмитрий Подлужный

    Руководитель направления проектирования интерфейсов

Мы все чаще переходим от проектирования по требованиям заказчика к построению работы с упором на продуктовые гипотезы. Причин этому несколько. С одной стороны, от нас ожидают внедрение новых функций, потому что конкуренция растет, мир движется быстрее, а его изменчивость велика. С другой стороны, потребностей у пользователей все больше.

От требований к гипотезам

Эволюция процессов разработки программных продуктов привела к смене подходов. Старые модели с большим объемом документирования оказались не приспособлены к современности. Вместо этого пришли методы, связанные с непрерывной разработкой и пониманием того, что системы должны развиваться и меняться. Гипотезы стали хорошим инструментом, чтобы формулировать задачи к изменениям.

Если требования нуждаются в реализации, то гипотезы в первую очередь нуждаются в проверке. Но перед этим их надо сформулировать. А это иногда не так просто, как хотелось бы.

О важности формулировок

С одной стороны, гипотезу можно сформулировать как угодно: нет правил и законов, которые запретили бы нам любой подход. Здравый смысл подсказывает, что хорошо бы ее сформулировать понятно, чтобы другие люди поняли ее смысл. Но я вспоминаю ТРИЗ (теорию решения изобретательских задач), где очень важное место уделяется качеству постановки задачи, потому что эффективность решения сильно зависит от формулировки.

Мы считаем, что чем лучше сформулирована гипотеза, тем результативнее будет ее проверка. Под результатом понимается не только проверка самой гипотезы, но и те возможные инсайты, которые можно собрать по мере проверки. Для формализации и упрощения работы над созданием гипотез мы выделили следующие вопросы, отвечать на которые можно последовательно.

Из чего состоит Product Hypothesis Canvas

1. Мы полагаем, что…

Здесь мы описываем то, что планируем разработать.

2. Для (кого)…

В этом блоке определяем целевую аудиторию и, если надо, даем оценку доли подобной аудитории в нашем проекте.

Это важный этап, потому что он позволяет потом ранжировать гипотезы по степени их полезности для проекта. Участники команды могут очень легко увлечься интересной идеей и забыть, что она будет полезна в единичных случаях.

Если автор не в состоянии определить, для кого он формулирует гипотезу, то высока вероятность, что здесь идет расчет на случайность.

Подобно тому как некоторые игроки в пул сначала наносят сильный удар в надежде, что что-нибудь да закатится. Так и продуктовые менеджеры и дизайнеры генерят гипотезы без привязки к пользователям, в надежде, что что-нибудь да сыграет. С такими гипотезами надо быть осторожными, возможно, стоит потратить больше времени, чтобы их продумать детальнее.

3. Чтобы добиться...

Важно определить, какой результат мы ожидаем от эксперимента. Желательно, чтобы он выражался в чем-то конкретном. Не надо писать: «Должно стать лучше...» Нужно сформулировать свои ожидания так: «Улучшить [продукт] на 5%...»

В зависимости от гипотезы мы можем иметь разные ожидаемые результаты в краткосрочной и долгосрочной перспективе. Многие предпочитают сосредотачиваться на краткосрочных результатах и не принимать в работу гипотезы, направленные на долгосрочные цели. Но нам при создании гипотез нужно понимать, сколько времени займет ее проверка: один день, неделю, месяц или еще больше. В зависимости от этого мы потом можем планировать бэклог проведения эксперимента.

4. Как измерим

Возможность измеримости результата — ключевой параметр проверки продуктовых гипотез. И если ранее мы описали, что мы будем измерять, то здесь описываем, как и с помощью каких инструментов мы это сделаем.

Какие сигналы будут указывать на то, что созданная нами возможность эффективна? Какие ключевые показатели (качественные или количественные) мы будем измерять, чтобы предоставить доказательства того, что наш эксперимент был успешен?

5. Влияние (положительное или отрицательное)

Этот блок введен, чтобы мы могли размышлять о гипотезе шире, чем только об одной задаче. Его необязательно заполнять.

Бывают случаи, что внедрение одного функционала отрицательно влияет на другие параметры в системе. Например, мы внедряем на главную страницу сайта большую интересную презентацию, которая должна повысить вовлеченность, но при этом презентация влияет на скорость загрузки страницы, что увеличивает количество отказов и может, наоборот, снизить глубину просмотра.

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

Так выглядит наш шаблон для формулирования гипотез:

canvas_photo.png

Его можно скачать в PNG или в PDF. Тут есть онлайн-шаблон на Miro.

Product Hypothesis Canvas поможет вам лучше работать с гипотезами. Важно понимать, что канвас не решает задачу сам по себе, он только позволяет сосредоточиться на решаемой задаче и повысить эффективность решения.

Как достичь максимума

  • Помните: чем точнее ваша гипотеза, тем лучший результат она даст.
  • Не забывайте, для кого вы тестируете гипотезу.
  • Конкретизируйте ожидаемый результат.
  • Не забывайте про долгосрочные цели.
  • Продумайте, не даст ли внедрение вашей гипотезы в продукт отрицательный результат.

Оригинал статьи: rb.ru


  • Дмитрий Подлужный

    Руководитель направления проектирования интерфейсов

    Личная колонка

Блог

0 / 0
+7 495 981-01-85 + Стать клиентом
Работа у нас