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

Практический пример

Удвоение роста доходов благодаря экспериментированию с циклом быстрых релизов, 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 %, активность пользователей возросла втрое, а команда удвоила доход. Чтобы укрепить успех, она сосредоточилась на оптимизации следующих показателей.

• Время до первого ответа. Как быстро появился ответ на вопрос пользователя?

• Время до лучшего ответа. Как быстро сообщество присудило награду за лучший ответ?

• Количество плюсов на один ответ. Сколько плюсов было поставлено за ответ?

• Вопросы/неделя/пользователь. Сколько ответов давали пользователи?

• Уровень повторного поиска. Как часто посетители были вынуждены повторять поиск, чтобы найти нужный ответ? (Чем ниже, тем лучше.)

Стоунхэм подводит итог: «Это были как раз знания, необходимые, чтобы завладеть рынком, — и они изменили не только скорость наших компонентов функциональности. Из команды наемных работников мы превратились в команду заказчиков. Когда двигаешься с такой скоростью и каждый день смотришь на числа и результаты, уровень вовлеченности в работу меняется радикально».