Как в Amazon улучшили эджайл-принципы | Большие Идеи

・ Управление изменениями
Статья, опубликованная в журнале «Гарвард Бизнес Ревью Россия»

Как в Amazon
улучшили эджайл-принципы

Что делать, если гибкие методы разработки не позволяют добиться успеха

Авторы: Билл Карр , Колин Брайар

Как в Amazon улучшили эджайл-принципы
Фото: Piotr Cichosz / Unsplash

читайте также

Выйти из себя: долго и дорого

Владимир Рувинский

Культурные различия: как пройти по минному полю

Эрин Мейер

Неиспользованные купоны не пропадут даром

Венкатесан Раджкумар,  Фаррис Пол

Почему подход Джобса работает не для всех

Джереми Корст,  Кимберли Уитлер

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

Эджайл — эффективный метод разработки продуктов, но многие компании злоупотребляют им, пытаясь заменить им тщательное планирование и подготовку. Можно добиться большего, если совместить эджайл с другим подходом, с которым мы познакомились, работая в Amazon. Принцип «работы начиная с конца» (working backwards) может компенсировать недостатки эджайл на самых важных ранних этапах.

Эджайл-компании могут слишком увлечься

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

Поэтому нужно разработать прототип, или минимально жизнеспособный продукт (MVP). С помощью серии спринтов (которые длятся, как правило, по две недели) команда разработчиков собирает продукт, который уже можно показать клиентам и получить от них какую-то реакцию. Если идея провалится, то, по крайней мере, вы узнаете об этом быстро и без лишних трат — и в процессе, возможно, обнаружите новую идею. А если идея окажется успешной, можно быстро выпускать новые итерации, чтобы создать еще более качественный продукт.

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

Вместо того чтобы сразу разработать потенциальный продукт (как это предлагает эджайл-подход), компания решила «торопиться медленно». Генеральный директор Джефф Безос часто называл себя «директором по замедлению»: когда его команды слишком быстро переходили к работе над кодом, не определив проблему клиента и не найдя элегантное решение-продукт, он вмешивался и останавливал их.

При «работе начиная с конца» сначала нужно составить полное представление о предлагаемом продукте и сформулировать его в виде письменного пресс-релиза. Разработчики и продакт-менеджеры считали это неправильным и даже противоестественным: им хотелось поскорее начать писать код. Команды тратили на пресс-релиз о запуске по несколько недель или даже месяцев — и параллельно разрабатывали FAQ, чтобы объяснить коллегам, клиентам и начальству, как Amazon сможет реализовать это прекрасное предложение по доступной, но выгодной цене. И только когда эти документы устраивали менеджеров, можно было начинать писать код и собирать продукт.

Методология прижилась, и в Amazon до сих пор работают начиная с конца: сначала думают, как порадовать покупателей, даже если прямо сейчас у них нет необходимых возможностей для этого продукта. Электронная книга Kindle, облачные сервисы AWS, голосовой ассистент Echo и Alexa — все они родились из работы «начиная с конца», когда у Amazon еще почти не было опыта в производстве девайсов или создании серверов для хостинга. Тем не менее все эти продукты стали хитами. Постепенно у каждого из них появились конкуренты, но все они сохраняют большую долю рынка.

Скорость — это не главное

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

Во-первых, вместо того чтобы тратить время и силы на развитие новых навыков, они используют те навыки, которые у них уже есть. Они признают свои ограничения, что автоматически ограничивает потенциал их роста.

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

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

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

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

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

Таким образом, лучшее решение — это сочетать эджайл с чем-то вроде «работы начиная с конца». Например, в Amazon научились использовать «работу начиная с конца» при формулировании идей, а затем разрабатывать и выпускать продукт по методике эджайл. Если даже такой гигант, как Amazon, может так легко менять курс, то и стартапам это по силам.

Об авторах

Колин Брайар (Colin Bryar) работал в Amazon с 1998 по 2010 год, стал там техническим вице-президентом и поработал техническим советником Джеффа Безоса. Теперь работает консультантом топ-менеджеров. Соавтор книги «Working Backwards: Insights, Stories and Secrets from Inside Amazon».

Билл Карр (Bill Carr) работал в Amazon с 1999 по 2014 год, в том числе на позиции вице-президента по цифровым медиа. Теперь работает консультантом топ-менеджеров. Соавтор книги «Working Backwards: Insights, Stories and Secrets from Inside Amazon».