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

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

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

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

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

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

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

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

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

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

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

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