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

Методология эджайл (гибкая адаптивная разработка), как и ее близкая родственница, технология бережливого производства (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».