Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

Компания Etsy выложила в открытый доступ свою экспериментальную программу Feature API (ранее известную как Etsy A/B API), поддерживающую не только A/B-тестирование, но и онлайн-регулирование количества пользователей из контрольной группы. Среди других инструментов для A/B-тестирования можно назвать Optimizely, Google Analytics и др.

В интервью 2014 г. с Кендриком Вонгом из компании Apptimize Лейси Роадс так описал свой путь: «Экспериментирование в Etsy проистекает из желания принимать обоснованные решения и гарантировать то, что, когда мы запускаем новую функциональность для миллионов наших пользователей, она действительно работает. Очень часто у нас появлялись такие программные компоненты, разработка и поддержание которых отнимали много времени и сил, а никаких доказательств их популярности у пользователей не имелось. A/B-тестирование позволяет нам… еще на стадии разработки понять, что над этой функциональностью действительно стоит работать».

Интеграция A/B-тестирования в планирование функциональности

Когда выстроена инфраструктура, поддерживающая A/B-релизы и тестирование, нужно убедиться, что представители заказчика думают о каждом компоненте функциональности как о гипотезе и используют релизы для экспериментов с реальными пользователями, чтобы подтвердить или опровергнуть гипотезы. Планирование эксперимента должно проходить в контексте воронки привлечения клиентов. Барри О’Райли, соавтор книги Lean Enterprise: How High Performance Organizations Innovate at Scale, описывает, как можно формулировать гипотезы в разработке возможностей приложения:

«Мы верим, что увеличение размеров фотографий отелей на сайте бронирования приведет к увеличению интереса клиентов и повышению показателя конверсии. Мы будем уверены в необходимости продолжения, если количество клиентов, просматривающих изображения отелей и затем в течение 48 часов бронирующих номер, увеличится на 5 %».

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