Джин Ким - Руководство по DevOps

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

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

В следующей главе мы исследуем, как телеметрия может помочь основанной на выдвижении гипотез разработке и A/B-тестированию и как проводить эксперименты, помогающие быстрее добиться целей компании и завоевать рынок.

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

Еще хуже, если внесение изменений в компонент, который не работает, может быть отодвинуто на задний план разработкой нового функционала в приложении. Неэффективный компонент так никогда и не будет действовать на полную мощность. В общем случае, как отмечает Джез Хамбл, «самый неэффективный способ протестировать бизнес-модель или идею продукта — создать этот продукт и посмотреть, есть ли на него спрос».

Прежде чем мы встраиваем новую функциональную возможность, мы должны строго спросить себя: а надо ли нам создавать ее и почему? Далее нужно провести наиболее быстрые и дешевые эксперименты, чтобы с помощью исследования пользовательских мнений подтвердить, будет ли реальный компонент приложения соответствовать запланированному результату. Для этого можно использовать такие методики, как разработка на основе гипотез, воронки привлечения клиентов и A/B-тестирование. Эти методики мы более подробно изучим в данной главе. Компания Intuit Inc. — отличный пример того, как организация использует подобные методики для создания популярных продуктов, распространения опыта внутри компании и завоевания своего рынка.

Intuit специализируется на создании продуктов для финансового менеджмента и делового администрирования. Цель — упростить жизнь малого бизнеса, покупателей и профессиональных бухгалтеров. В 2012 г. доход компании составлял 4,5 миллиарда долларов, в ней работали около 8500 сотрудников. Ее основными продуктами были QuickBooks, TurboTax, Mint и до недавнего времени Quicken [133].

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

Кук объясняет, что необходима «такая система, где каждый сотрудник может проводить быстрые эксперименты… Дэн Морер управляет нашим подразделением по работе с потребителями, а оно, в свою очередь, занимается сайтом TurboTax. К тому моменту, как он получил эту должность, мы устраивали примерно семь экспериментов в месяц».

Далее он продолжает: «Создав процветающую культуру инноваций в 2010 г., теперь они проводят по 165 экспериментов в три месяца периода подачи налоговых деклараций. Бизнес-результаты? Показатель конверсии сайта — около 50 %… Членам команды это нравится, потому что теперь их идеи работают на реальном рынке».

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

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