Как в Amazon улучшали принципы agile

Гибкая адаптивная разработка (agile) – эффективный метод разработки продуктов, но им нельзя злоупотреблять, пренебрегая тщательным планированием и подготовкой. Компания Amazon, в которой мы работали, совместила agile с другим подходом – с принципом работы «начиная с конца» (working backwards). Он компенсирует недостатки agile на самых важных ранних этапах.

Не увлекаться

Считается, что agile – идеальная методика, чтобы вести разработку с нуля, ведь если еще нет продукта, сложно опросить о нем клиентов или посмотреть, как они будут с ним работать.

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

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

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

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

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

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

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

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

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

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

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

Таким образом, лучшее решение – это сочетать agile с чем-то вроде работы «начиная с конца». В Amazon научились использовать работу «начиная с конца» при формулировании идей, а затем разрабатывать и выпускать продукт по методике agile. И это оказалось эффективно.

Об авторах: Колин Брайар – бывший технический вице-президент и технический советник Джеффа Безоса, работал в Amazon с 1998 по 2010 г., Билл Карр – бывший вице-президент по цифровым медиа, работал в Amazon с 1999 по 2014 г.

Статья впервые опубликована в «Harvard Business Review Россия». Оригинал статьи здесь