Глава 17. Встройте основанную на гипотезах разработку и A/B-тестирование в свою повседневную работу
Слишом часто в проектах разработки ПО новый функционал создается в течение нескольких месяцев или лет без всякого подтверждения достижения требуемых бизнес-целей с каждым новым релизом. Например, служит ли конкретный функционал желаемым целям, или даже используется ли он вообще.
Еще хуже, если внесение изменений в компонент, который не работает, может быть отодвинуто на задний план разработкой нового функционала в приложении. Неэффективный компонент так никогда и не будет действовать на полную мощность. В общем случае, как отмечает Джез Хамбл, «самый неэффективный способ протестировать бизнес-модель или идею продукта — создать этот продукт и посмотреть, есть ли на него спрос».
Прежде чем мы встраиваем новую функциональную возможность, мы должны строго спросить себя: а надо ли нам создавать ее и почему? Далее нужно провести наиболее быстрые и дешевые эксперименты, чтобы с помощью исследования пользовательских мнений подтвердить, будет ли реальный компонент приложения соответствовать запланированному результату. Для этого можно использовать такие методики, как разработка на основе гипотез, воронки привлечения клиентов и A/B-тестирование. Эти методики мы более подробно изучим в данной главе. Компания Intuit Inc. — отличный пример того, как организация использует подобные методики для создания популярных продуктов, распространения опыта внутри компании и завоевания своего рынка.
Intuit специализируется на создании продуктов для финансового менеджмента и делового администрирования. Цель — упростить жизнь малого бизнеса, покупателей и профессиональных бухгалтеров. В 2012 г. доход компании составлял 4,5 миллиарда долларов, в ней работали около 8500 сотрудников. Ее основными продуктами были QuickBooks, TurboTax, Mint и до недавнего времени Quicken.
Скотт Кук, основатель Intuit, всегда был сторонником культуры инноваций, вдохновляя команды на экспериментальный подход к разработке программ и убеждая руководство поддерживать их в этом. По его словам, «вместо того чтобы следовать мнению своего босса, стоит сконцентрироваться на поведении реальных участников реального эксперимента и уже затем на основе результатов принимать решения». Это отличный пример научного подхода в разработке ПО.
Кук объясняет, что необходима «такая система, где каждый сотрудник может проводить быстрые эксперименты… Дэн Морер управляет нашим подразделением по работе с потребителями, а оно, в свою очередь, занимается сайтом TurboTax. К тому моменту, как он получил эту должность, мы устраивали примерно семь экспериментов в месяц».
Далее он продолжает: «Создав процветающую культуру инноваций в 2010 г., теперь они проводят по 165 экспериментов в три месяца периода подачи налоговых деклараций. Бизнес-результаты? Показатель конверсии сайта — около 50 %… Членам команды это нравится, потому что теперь их идеи работают на реальном рынке».
Помимо роста показателя конверсии одна из самых интересных деталей этой истории — что в отделе TurboTax проводили эксперименты в периоды максимальной нагрузки на сайт. Десятилетиями в розничной торговле риск влияющих на выручку сбоев во время праздничных сезонов был настолько велик, что с середины октября по середину января мы просто запрещали вносить любые изменения.
Однако, добившись быстрых и безопасных развертываний и релизов, команда TurboTax снизила риски пользовательских экспериментов и внесения изменений настолько, что их можно было проводить и в самые прибыльные периоды наибольшей нагрузки.
Это подчеркивает мысль, что самое ценное для экспериментов время — как раз месяцы и дни интенсивной нагрузки. Если бы команда TurboTax ждала до 16 апреля, когда заканчиваются сроки подачи налоговой документации в США, компания потеряла бы много потенциальных и реальных клиентов: они ушли бы к конкурентам.
Чем быстрее мы экспериментируем, воспроизводим результаты и встраиваем их в наш продукт или сервис, тем быстрее учимся и тем сильнее превзойдем конкурентов. А скорость интегрирования результатов зависит от организации развертывания и выпуска релизов.
Пример компании Intuit показал, что команда TurboTax смогла повернуть ситуацию себе на пользу и в результате захватила рынок.
Краткая история A/B-тестирования
Как показывает история команды TurboTax, определение воронки привлечения клиентов и A/B-тестирование — очень мощные инструменты исследования поведения пользователей. Методики A/B-тестирования появились в прямом маркетинге — одном из двух основных направлений маркетинговых стратегий. Второе направление — массовый маркетинг, или бренд-маркетинг, — часто заключается в том, чтобы разместить перед потенциальными покупателями как можно больше рекламы.
В прошлые эпохи, до электронной почты и социальных сетей, прямой маркетинг сводился к рассылке тысяч открыток и буклетов обычной почтой и к просьбам возможным клиентам принять предложение и перезвонить по указанному телефону, выслать ответную открытку или оставить заказ каким-либо другим способом.
В рамках таких кампаний исследования проводились для того, чтобы определить способ с наибольшим показателем конверсии. Они экспериментировали с изменением подачи предложения, меняя слова, стили, дизайн, оформление, упаковку и так далее, все для того, чтобы понять, как наилучшим образом вызвать желаемые действия покупателя (например, чтобы он позвонил по телефону или заказал товар).
Зачастую каждый эксперимент требовал дизайна и печати нового тиража, рассылки тысяч предложений, ждать ответов приходилось неделями. Каждая попытка обычно обходилась в десятки тысяч долларов и занимала несколько недель или месяцев. Однако, несмотря на все расходы, такое повторяющееся тестирование вполне окупалось, если оно значительно увеличивало показатель конверсии (например, если процент заказавших продукт покупателей увеличивался с 3 до 12 %).
Хорошо задокументированные примеры A/B-тестирования включают в себя сбор средств, интернет-маркетинг и методологию бережливого стартапа. Интересно, что эта методика также использовалась британским правительством для определения того, с помощью каких писем эффективнее всего было собирать просроченные налоги с задерживающих платежи граждан.
Интегрирование A/B-тестирования в тестирование компонентов функциональности
Самая распространенная методика A/B-тестирования в современной практике взаимодействия с пользователем — сайт. На нем посетителям показывается одна из двух страниц, контрольная («А») и альтернативная («B»), выбранная случайным образом. На основе статистического анализа делаются выводы о значимости различий в поведении двух групп пользователей. После этого мы можем установить причинно-следственную связь между внесенным изменением (например, в функциональных возможностях, элементах дизайна, цветах фона) и последствиями (например, коэффициентом конверсии, средним размером заказа).
К примеру, можно провести такой эксперимент: проверить, увеличивает ли доход изменение цвета кнопки «купить». Или замерить, уменьшает ли выручку рост времени ответа сайта (с помощью искусственного замедления его работы). Такой тип A/B-тестирования позволит нам оценить улучшение работоспособности сайта в денежном выражении.
A/B-тесты также известны под такими названиями, как «онлайн-эксперименты в контролируемых условиях» или «сплит-тесты». Эксперименты можно проводить и с несколькими переменными. Благодаря этому мы сможем наблюдать их взаимодействие. Такая методика называется многомерным тестированием.
Результаты A/B-тестирования часто просто поразительны. Ронни Кохави, выдающийся инженер и директор отдела анализа и проведения экспериментов компании Microsoft, заметил: после «оценки тщательно продуманных и поставленных экспериментов, проведенных с целью улучшить какой-либо ключевой показатель, выяснилось, что только одна треть действительно помогла улучшить этот показатель!». Другими словами, воздействие двух третей новых компонентов функциональности было либо незначительным, либо вовсе отрицательным. Кохави отмечает, что все эти новшества казались хорошими и обоснованными идеями, что еще раз подчеркивает преимущество пользовательского тестирования перед интуицией и экспертными оценками.
Выводы из данных Кохави ошеломляют. Если мы не исследуем поведение пользователей, вероятность того, что разрабатываемая нами функциональность бесполезна или наносит вред компании, равна двум третям. И это не считая того, что сам код усложняется, увеличиваются затраты на его поддержку, а вносить изменения становится все труднее. Кроме того, усилия, затраченные на создание таких элементов функциональности, могли бы быть потрачены на что-то действительно полезное (то есть это альтернативные издержки). Джез Хамбл в связи с этим пошутил: «Если довести эту мысль до крайности, то компании и заказчикам было бы выгоднее отправить всю команду в отпуск, чтобы она не занималась разработкой бесполезных компонентов».
Лекарство от этого — интеграция A/B-тестирования в проектирование, разработку, тестирование и развертывание элементов функциональности. Осмысленное исследование поведения пользователя и постановка экспериментов помогут нам достичь намеченных целей и занять прочные позиции на рынке ПО.
Интегрируйте A/B-тестирование в релизы
Быстрое и многократное A/B-тестирование возможно в том случае, если мы можем быстро и без усилий развертывать наш код, используя переключатели функциональности для отключения ненужных компонентов и отправляя в эксплуатацию несколько версий кода одновременно для разных сегментов заказчиков. Для этого нужна полезная телеметрия на всех уровнях стека приложения.
С помощью переключателей мы можем контролировать процент пользователей, участвующих в эксперименте. Например, пусть одна половина будет контрольной группой, а другая будет видеть следующее предложение: «Заменить в вашей корзине товары, в данный момент отсутствующие, на похожие». Мы будем сравнивать поведение экспериментальной группы (видящей предложение) и контрольной (не видящей), измеряя, например, количество покупок за одну сессию.
Компания 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 %».
Исследовательский подход к разработке требует не только разбивать задачу на небольшие подзадачи (требования или пожелания пользователей), но также убеждаться, что каждая подзадача приводит к ожидаемому исходу. Если этого не происходит, мы исправляем план работ и ищем другие пути.
Практический пример
Удвоение роста доходов благодаря экспериментированию с циклом быстрых релизов, Yahoo! Answers (2010 г.)
Чем быстрее мы сможем встраивать обратную связь в продукт или сервис, поставляемый нашим клиентам, тем быстрее будем учиться и тем значительнее окажутся результаты нашей деятельности. То, насколько сильно короткие циклы влияют на результат работы, можно проследить на примере компании Yahoo! Answers, когда она перешла от одного релиза каждые шесть недель к нескольким релизам за одну неделю.
В 2009 г. Джим Стоунхэм занимал должность директора подразделения Yahoo! Communities. В него входили Flickr и Answers. До этого он отвечал за работу Yahoo! Answers. Конкурентами были такие сервисы вопросов и ответов, как Quora, Aardvark и Stack Exchange.
В то время у сервиса Answers было примерно 140 миллионов посетителей в месяц, свыше 20 миллионов активных пользователей, отвечающих на вопросы на более чем 20 языках. Однако рост доходов и числа пользователей прекратился, а показатели активности пользователей сокращались.
Стоунхэм отмечает: «Yahoo! Answers был и остается одной из самых больших социальных игр во всем интернете. Десятки миллионов участников активно пытаются набрать уровни, давая качественные ответы быстрее, чем другие пользователи сайта. У нас было много возможностей подправить игровую механику, петли виральности и другие способы взаимодействия в сообществе. Когда имеешь дело с человеческим поведением, нужно уметь устраивать быстрые тесты, чтобы увидеть, что пришлось людям по душе».
Стоунхэм продолжает: «Эти эксперименты очень хорошо делали компании Twitter, Facebook и Zynga. Они устраивали эксперименты как минимум дважды в неделю, даже разбирали и анализировали изменения, сделанные до развертывания, чтобы убедиться, что они все еще на правильном пути. Вот он — я, управляющий крупнейшим сайтом вопросов и ответов на всем рынке, желающий внедрить быстрое и многократное тестирование функциональности. Но мы не можем выпускать релизы чаще раза в четыре недели. А другие на этом же рынке получают обратную связь в десять раз быстрее, чем мы».
Стоунхэм отмечает, что сколько бы заказчики и разработчики ни говорили о важности телеметрии, без частых экспериментов (каждый день или каждую неделю) они всего лишь фокусируются на компонентах функциональности, а не на результатах клиента.
Когда команда Yahoo! Answers смогла перейти на еженедельное развертывание, а затем и на несколько развертываний в неделю, ее способность экспериментировать с функциональными возможностями сильно выросла. Впечатляющие достижения и новый опыт за следующие 12 месяцев регулярных экспериментов увеличили количество посещений на 72 %, активность пользователей возросла втрое, а команда удвоила доход. Чтобы укрепить успех, она сосредоточилась на оптимизации следующих показателей.
• Время до первого ответа. Как быстро появился ответ на вопрос пользователя?
• Время до лучшего ответа. Как быстро сообщество присудило награду за лучший ответ?
• Количество плюсов на один ответ. Сколько плюсов было поставлено за ответ?
• Вопросы/неделя/пользователь. Сколько ответов давали пользователи?
• Уровень повторного поиска. Как часто посетители были вынуждены повторять поиск, чтобы найти нужный ответ? (Чем ниже, тем лучше.)
Стоунхэм подводит итог: «Это были как раз знания, необходимые, чтобы завладеть рынком, — и они изменили не только скорость наших компонентов функциональности. Из команды наемных работников мы превратились в команду заказчиков. Когда двигаешься с такой скоростью и каждый день смотришь на числа и результаты, уровень вовлеченности в работу меняется радикально».
Заключение
Для успеха нужны не только быстрое внедрение и быстрые релизы, но и умение побороть конкурентов в проведении экспериментов. Такие методики, как разработка на основе гипотез, определение и измерение воронки привлечения клиентов и A/B-тестирование, позволяют безопасно и без усилий экспериментировать с поведением пользователей, пробуждая творческий и инновационный подход к работе и создавая новый опыт на уровне всей компании. И хотя преуспеть — важно, новые знания, полученные благодаря экспериментам, дают работникам контроль над целями организации и удовлетворенностью клиентов. В следующей главе мы рассмотрим и создадим процессы проверки, анализа и координации для улучшения качества текущей работы.
