Зачем и как тестируют гипотезы в IT
О чём вообще речь?
Современное IT — это итерационный процесс. Каждая фича, каждый сайт или сервис обязательно проверяются: сперва на этапе идеи, а после — в процессе реализации.
Тестирование работает по принципу естественного отбора: слабые продукты прикрывают, а сильным дают зелёный свет. Чем крупнее проект, тем больше гипотез в нём проводят. К примеру, прямо сейчас в Яндексе тестируют сотни, тысячи идей и решений, из которых вырастут только лучшие фичи.
А кто мешает сразу делать хорошо? Логику же никто не отменял!
Действительно, продуктовая команда должна сделать хорошо — для этого в работе она опирается на свои профессиональные знания и опыт. Однако это помогает не всегда.
Отсечь субъективное. Тестирование гипотез помогает избежать ошибок при развитии продуктов. Такие ошибки возникают, когда руководитель или менеджер «влюбляется» в свою идею и настаивает на её реализации. Дизайнерам и редакторам тестирование гипотез и решений помогает отсечь «вкусовщину».
В Яндексе руководитель одного из направлений очень верил в возможности имейл-маркетинга. Он настаивал: «Мы можем делать такие письма о нашем продукте, что люди будут пользоваться им чаще». Он опирался на опыт, который получил на предыдущем месте работы. Но у команды были сомнения: продуктом пользуются люди, которые нечасто читают электронные письма.
В итоге решили провести эксперимент: за две недели сравнили охват и целевые действия сперва через рассылку по почте, а после — в пуш-уведомлениях. Оказалось, что уведомления работают на 40% лучше. В результате руководитель согласился, что вкладывать силы в имейл-маркетинг будет нерационально.
К такому решению пришли за две недели. А без тестирования могли бы ошибочно заняться рассылками и потерять время.
Узнать неизвестное. Тестирование гипотез помогает нащупать новые, перспективные направления работы. Для этого продуктовые команды часто создают MVP — Minimum Viable Product. Так называют проекты, которые быстро делают для тестирования гипотез и решений.
MVP часто метафорически сравнивают со строительством самолёта прямо в процессе полёта. На самом деле минимально жизнеспособный продукт в авиации — это самолёт, в котором не установлены пассажирские кресла и другие привычные вещи. Его задача заключается в том, чтобы просто взлететь и показать себя устойчиво в полёте.
MVP создают небольшими командами за несколько недель или месяцев. Чтобы не тратить ресурсы, отрезают всё лишнее. К примеру, первое время обходятся без сайта, а вместо автоматизации процессов делают всё руками.
Лавка, один из важнейших продуктов Яндекса, тоже выросла из MVP. Проект тестировали в одном из районов Москвы, Хамовниках — товары доставляли с пары дарксторов всего по нескольким улицам. Вместо курьеров на работу выходили сами менеджеры — чтобы сэкономить ресурсы и лучше понять особенности работы «в поле».
В результате Лавка взлетела и из MVP превратилась в огромный сервис. Конечно, многие из тестируемых проектов в Яндексе не выстрелили. Но и закрыть их не жалко: проверили гипотезу и пошли работать дальше.
Найти пути улучшения. Любой успешный продукт непрерывно развивается, чтобы меняться вместе с миром, рынком и клиентами. А также чтобы находить лакуны, которые дают ресурсы для роста.
Хороший продакт-менеджер постоянно придумывает новые гипотезы, часто выстраивая их в пайплайн — последовательность действий. Например:
Нам нужно доставлять курьером сразу по три заказа, чтобы заработать больше. Есть идея: промить спецпредложениями товары из Лавки по людям, которые живут рядом с новым клиентом. Потестируем это, а если взлетит — будем после тестировать специальные скидки выходного дня, чтобы доставлять сразу по 7–10 заказов в субботу и воскресенье.
Тоже мне работа — придумывать идеи и тестировать их. Лучшая работа в мире!
Безусловно, продакт — одна из лучших работ в мире. Но при этом очень сложная и ответственная.
— Нужно следить за чистотой эксперимента. К примеру, прежде чем проверить новую фичу с помощью знаменитого A/B-теста, опытный продакт сделает ещё и A/A-тест: сверит сегмент аудитории сам с собой, чтобы убедиться, что выборка точно случайна и искажений в ходе эксперимента нет.
Кроме того, с помощью А/А-теста можно определить доверительный интервал, в рамках которого изменения конверсии могут быть случайными и не зависеть от изменений на странице. Например, в ходе А/А-теста одна и та же страница показала конверсию 2 и 3%. Значит, если при А/Б-тесте конверсия попадёт в диапазон от 2 до 3%, вносить изменения не стоит, так как они не повлияют на результат.
— Важно знать современные фреймворки тестирования, разбираться в метриках. Вообще, профессиональный продакт больше сидит в табличках, сравнивая числа, чем ходит по офису с задумчивым видом в поисках идеи. Продакт — это прежде всего аналитик.
— Необходимо уметь взаимодействовать с клиентами и пользователями. Для этого продакты проводят «коридорные исследования»: обсуждают нововведения с коллегами. А после напрямую общаются с пользователями с помощью опросов и созвонов. Общение — это большая и важная часть работы, которую называют кастдевом, от customer development. Настольная книга по кастдеву — «Спроси маму» Роба Фитцпатрика. Почитайте её конспект.
В Яндексе есть даже специальная комната для наблюдения за пользователями — как в американских фильмах про детективов. Пользователь работает с новым устройством или интерфейсом, а дизайнеры за стеклом, прозрачным с одной стороны, смотрят за его действиями. Такой подход помогает поймать неочевидные ошибки и «узкие места» в продукте.
В отличие от детективных фильмов, участники такого тестирования не видят наблюдателей просто для того, чтобы не отвлекаться и пользоваться продуктом словно в обычной среде.
Кроме того, продакт и специалист по тестированию гипотез умеет доносить свои идеи до команды, переупаковывая их в язык, который понятен разработчикам, дизайнерам, менеджерам.
— Приходится исследовать лучшие практики. В IT занимаются тестированием уже много лет и создали десятки фреймворков. Хороший продакт много читает, смотрит, посещает конференции, общается с коллегами. Он знает, что в компании А «подкрутили» известный фреймворк, а в компании Б недавно выяснили важные особенности рынка.
Всё это помогает быть успешнее в тестировании. Ведь продукт в IT похож на гепарда: команда может ошибиться в «охоте за идеями» только пару раз, после ресурсы кончатся.
Перед запуском любого A/B-тестирования нужно честно ответить себе, на каких метриках мы ожидаем увидеть изменение и какими будут основные сценарии принятия решения после. Например, если в эксперименте ничего не прокрасится и всё будет «серое» — покатим мы такое изменение или нет? А если «зелёное», то какой рост должен случиться, чтобы назвать эксперимент успешным?
Часто, выкатывая изменение в нашем продукте, мы улучшаем метрики одной фичи и ухудшаем другие — например потому, что другая кнопка стала менее заметна. В этом случае важно заранее понять, есть ли метрики, которые мы будем готовы «разменять» на улучшение в метриках текущего эксперимента. И если да, то в какой пропорции.
Также важно держать в голове, какие есть ключевые сценарии и метрики продукта, которые просаживать ни в коем случае нельзя, даже если эксперимент оказался суперуспешным и сулит нам золотые горы. Это особенно важно в монетизационных сценариях. Грубо говоря, эксперимент с рекламной кнопкой во весь экран, очевидно, принесёт нам денег, но в долгосрочной перспективе пользователи просто не захотят иметь дело с приложением и скачают другое.
Кстати, вопрос долгосрочной или краткосрочной перспективы тоже важен: иногда какое-то изменение нельзя увидеть в эксперименте, потому что он длится относительно небольшое количество времени, а вы, допустим, хотите проверить, изменится ли частотность записи на стрижку в вашем сервисе. Понятно, что в большинстве своём люди не стригутся каждый день и даже каждую неделю, поэтому делать выводы можно будет только при большом сроке сбора данных. Или придётся использовать другие методы.
В общем, у каждого продукта своя специфика, своя частотность использования, свои ключевые метрики. И хороший продакт должен понимать эти особенности.
Екатерина Смагина, менеджер продукта в Геосервисах Яндекса
Но ведь есть продукты, где не нужны ни продакты, ни гипотезы!
Возможно, но не в IT. Здесь слишком большие скорости рынка и технологий, слишком велик шанс ошибиться. Права на серьёзную ошибку, которой можно было избежать с помощью тестирования, просто нет. Иначе обойдут конкуренты или кончатся ресурсы на исправление. Поэтому продакт — это очень важный человек, буквально капитан корабля.
Когда вы придёте на работу или стажировку в Яндекс, обязательно познакомитесь с продактами и увидите важные приёмы их работы на практике. Это полезный опыт, который точно вам пригодится!
