Такие архитектуры были и остаются ключевым компонентом Agile-системы Amazon. «Большинство людей считают, что самое ценное достижение сервис-ориентированных архитектур – это способность быстрее внедрять инновации, – сказал нам Голдбергер. – Да, все так. Но она также позволяет быстрее останавливать неэффективные инновации. Если вы поручите людям внедрять инновации, не делая ошибок, вы убьете их. Но если вы поручите людям внедрять инновации и не беспокоиться об ошибках, которые можно быстро исправить, они смогут свободно тестировать и обучаться способами, которые близки духу Agile». Джефф говорит о двухсторонних дверях, позволяющих вернуться, если вам не понравится то, что вы увидите с другой стороны. Сервис-ориентированные архитектуры позволили создать тысячи таких дверей.
Одним из самых ранних применений этой архитектурной философии была платформа Marketplace, позволившая компании продавать товары третьих сторон на своем веб-сайте. Ранее Amazon уже дважды пыталась (с помощью аукционов и сервиса zShops) предложить конкурентоспособные альтернативы eBay. Обе попытки провалились. Но сервис-ориентированные архитектуры позволили Amazon создавать отдельные детализированные страницы, которые полностью интегрировали сторонних провайдеров в основной опыт покупок компании. Компания превратила идею «и я тоже» в превосходное предложение. Сегодня на платформе существует более пяти миллионов рыночных продавцов, на которых приходится 53 % продаваемых торговых единиц.
Эта философия также привела к созданию Amazon Web Services. В 2003 году два члена команды разработчиков веб-сайтов Amazon Бенджамин Блэк и Крис Пинкхэм начали работать над способами быстрого и эффективного масштабирования технологической инфраструктуры, чтобы не отставать от стремительного роста компании. Они составили служебную записку, описывающую облачную архитектуру и анализирующую потенциал продажи виртуальных серверов в качестве сервиса. Хотя правление Amazon опасалось, что эта идея слишком далека от основной концепции розничной торговли компании, Безосу понравилось, что она может помочь любому, даже студенту в общежитии, начать новый бизнес. В 2006 году Amazon официально перезапустила Amazon Web Services. С тех пор в нем был создан новый стратегический механизм, который обеспечивает значительный рост доходов и прибыли компании, а также способствует важным для всего мира прорывам в облачных вычислениях.
Несмотря на предпринимательские ценности и принципы, которые пронизывали компанию, ее организационная структура долгое время оставалась очень похожей на структуру большинства организаций. В начале 2002 года Безос решил это изменить. Он официально предложил масштабировать Agile-команды, хотя называл их «командами на две пиццы» и был в значительной степени равнодушен к конкретным методам или фреймворкам, которые они используют. Его идея состояла в том, чтобы строить все предприятие вокруг небольших автономных групп, постоянно решающих самые крупные проблемы, применяя Agile-методы. Каждая команда должна была состоять из десяти человек, чтобы всех можно было накормить двумя пиццами, когда сотрудники работают допоздна. Альянсы могли соревноваться друг с другом. Они создавали свои функции пригодности: уравнения, помогающие им и другим (особенно Безосу) измерять их прогресс.
Голдбергер вспоминает, с каким рвением люди работали в этих группах «на две пиццы». «Эти команды великолепны. Они устраняют ненужную иерархию и позволяют людям напрямую сотрудничать друг с другом и с клиентами. Большинство людей, которых я знал, хотели попробовать работать в таких командах. Имена тех, кто попробовал, помечали значком пиццы в онлайн-каталоге, что считалось почетным знаком».
Команды «на две пиццы» возникли и закрепились в инновационных отделах, например, в технологии, но не в таких департаментах, занимающихся рутинными операциями, как бухгалтерия. Функции пригодности нигде и никогда не становились популярными и в основном игнорировались. Amazon не завершила реструктуризацию всего предприятия вокруг «команд на две пиццы», но они стали основными механизмами внедрения инновационных идей. Компания управляет тысячами из них, и они стали основной частью культуры.
В 2004 году, спустя десять лет после основания компании, Amazon также изменила свой подход к финансированию инновационных инициатив и обсуждению предложений. Сегодня каждый план и каждое предложение, особенно для «команд на две пиццы», начинается с шестистраничной служебной записки. Она открывается стратегическим пресс-релизом на одной или двух страницах о преимуществах инициативы для клиентов. Подобно пользовательским историям в любом Agile-бэклоге, такие пресс-релизы описывают целевых потребителей, выгоды, которые они хотят получить, разочарования, которые они испытали в связи с предыдущими решениями, и преимущества нового подхода Amazon. Предложение также включает в себя по крайней мере четыре или пять страниц часто задаваемых вопросов (FAQs), начиная с самых сложных, например, как работает инновация. Иногда могут присутствовать приложения и примерные схемы или рисунки, изображающие клиентов, использующих решения. Хотя эти предложения первоначально назывались записками на шесть страниц, многие руководители теперь называют их «PR/FAQ», и они могут занимать пятнадцать или более страниц.
Голдбергер до сих пор помнит свое первое предложение на шести страницах. Он подготовил презентацию в PowerPoint, но за неделю до сдачи документа узнал, что это должна быть записка. «Это было трудное обсуждение, – рассказывает он. – Неуютно себя чувствуешь, сидя в течение тридцати-шестидесяти минут, пока все читают твою записку. Затем начинают поступать вопросы в случайном порядке. Если вы не в теме, вас разоблачат в течение нескольких минут. Безос может в мгновение ока распознать заученный ответ. Вы должны быть экспертом, а не просто компетентным докладчиком». Однако больше всего Голдбергер ценил в шестистраничных записках, что они укрепляли ориентацию Amazon на клиентов. «Что я помню, – сказал он нам, – так это то, как они заставляли себя чувствовать. Они заставляли нас всех задуматься о том, что мы на самом деле пытаемся сделать. Работа в обратном направлении от клиента заставляет вас думать о каждом действии как об услуге клиенту. И поскольку многие предложения направлены на улучшение внутренних бизнес-процессов и технологий, это заставляет вас думать обо всех, с кем вы работаете, как о клиентах. Я знал, что на мне лежит реальная ответственность, и в какой-то момент чувство ответственности у меня действительно появилось».
Другие руководители согласны с Голдбергером, в том числе Надя Шурабура, один из руководителей Amazon с 2004 по 2012 год. «Каждая часть системы компании уравновешивает и усиливает другие ее части, – сказала она. – В основе системы лежит одержимость клиентами. Amazon может допускать микроменеджмент, но одержимость клиентами, как правило, важнее. Лично я предпочитаю страсть безразличию. Руководители не говорят людям, что делать. Они говорят: “Вы отвечаете за этого клиента, и у него есть проблема. Что вы собираетесь с этим делать?” Шестистраничные записки обеспечивают ресурсы для инноваций, оценивая проблему со стороны клиентов. За время работы в Amazon я написала сотни шестистраничных записок и прочла еще тысячи. В ходе обсуждений не тратится время на то, что хотят сказать докладчики. По возможности каждая минута используется для переосмысления клиентского опыта. Затем “команды на две пиццы” сосредотачиваются на том, чтобы разработать творческие решения для клиентов, при этом они самодостаточны, полностью привержены и наделены полномочиями. Все команды, как говорят в Amazon, “однопоточные”, т. е. они не могут быть многозадачными. Одна команда – одна проблема. Сервис-ориентированные архитектуры позволяют им собирать данные о клиентах из любого места и тестировать решения в любом месте, не дожидаясь одобрения иерархий. Система работает, чтобы сделать всех лучше».
Amazon продолжает расширять и совершенствовать свои инструменты для масштабирования и повышения гибкости. Сможет ли компания добиться успеха в будущем? Безос не знает, и мы не знаем. В ноябре 2018 года он сказал своим сотрудникам: «Amazon не настолько велика, чтобы никогда не провалиться… На самом деле, я предсказываю, что однажды Amazon потерпит поражение. Компания обанкротится. Посмотрите на крупные компании, продолжительность их жизни, как правило, составляет тридцать с лишним лет, а не сто с лишним». Секрет отсрочки этой кончины заключается в том, чтобы компания сосредоточилась на клиентах и не смотрела лишь внутрь себя. «Если мы начнем фокусироваться на себе, а не на наших клиентах, это будет началом конца. Мы должны стараться отсрочить этот день».[5]
Опасности сложной системы реальны даже для Amazon. Изменения в законодательстве могут привести к разрыву отношений. Рост может замедлиться, что повлияет на цену акций и суммы вознаграждений «звездных» сотрудников. Микроменеджмент и бюрократия усилятся, подавляя инновации. Недавнее снижение удовлетворенности клиентов может превратиться в долгосрочные тенденции. Однако мы знаем не так много компаний, которые усерднее, чем Amazon, работают над поддержанием постоянного баланса и над гармонизацией своей системы для адаптации к непредсказуемым рынкам.
Правила пути к Agile
Большинство компаний, успешно использующих Agile, включая Amazon и другие упомянутые в этой книге организации, развивают необычный набор возможностей. Они позволяют им реализовывать Agile, не попадая в ловушки и не увлекаясь причудами, которые преследуют других потенциальных практиков гибкости. Четыре из них особенно важны, настолько важны, что мы считаем их правилами пути к Agile, навыками и атрибутами, которые приведут вас туда, куда вы хотите прийти.
Вы не можете рассматривать возможность использования масштабированного Agile, если вообще не можете использовать Agile. Как уже отмечалось, Agile-команды – это инструменты, используемые для разработки инновационных решений, когда то, что нужно получить, и как это следует сделать, расплывчато и непредсказуемо. Их основная цель – это изменение бизнеса при помощи инноваций – создания новых продуктов, услуг или клиентского опыта (для внешних клиентов), совершенствования процессов и технологий, чтобы помочь операционным сотрудникам предоставлять решения этим внешним клиентам. В центре Agile находятся команды.