Текст книги "Стратегия Amazon. Инструменты бескомпромиссной работы на впечатляющий результат от топ-менеджеров Amazon"

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

Организационная структура раздувалась по мере того, как мы создавали команды для каждой новой категории продуктов, географического положения и функции (например, Бытовая электроника, Amazon Japan, Графический дизайн). Когда компания была меньше, вы могли бы попросить о помощи (например, проверить ваш проект на наличие ошибок) у тех, кто был поблизости – часто все знали друг друга довольно хорошо. При масштабировании эта же задача стала длительной и трудоемкой. Вы должны были выяснить, с кем вам нужно поговорить, находится ли их офис в вашем здании и кому они подчиняются. Может быть, вы бы и сами нашли их, но вам нужно было спрашивать своего менеджера, который, в свою очередь, спрашивал своих менеджеров или коллег, и каждый шаг требовал времени. Если вам повезло, вы находили бы нужного человека (или его менеджера) и просили бы выслушать свое предложение и выделить ресурсы для вашего проекта. Часто эти люди одновременно делали то же самое для своих собственных проектов. В любом случае они могли не захотеть отвлекаться ради вас. Вам часто приходилось бы делать это несколько раз для одного конкретного проекта и часто безуспешно.

Если у вашей команды были ресурсы, в которых нуждались другие люди, такие запросы также могли прийти и вам, иногда их было множество за одну неделю. Вам нужно было сопоставить каждый из них с имеющимися у вас приоритетами, а затем решить, какие запросы (если таковые имеются) вы могли бы поддержать, исходя из вашего собственного мнения об их достоинствах. Чтобы понять, сколько сопротивления испытывал рядовой проект Amazon от этих растущих организационных зависимостей, вам нужно умножить эти усилия в пять или десять раз. Как и в случае с нашим программным обеспечением, многие организационные структуры стали тесно связанными и сдерживали нас.

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

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

В конце концов, мы поняли, что все это межкомандное взаимодействие на самом деле вовсе не нуждалось в улучшении, оно нуждалось в устранении. На каком камне это было высечено, что в каждом проекте должно участвовать так много отдельных субъектов? Дело не в том, что у нас было неправильное решение; скорее, мы пытались решить совсем не ту проблему. У нас еще не было нового решения, но мы наконец поняли истинную суть нашей проблемы: постоянно растущие затраты на координацию между командами. Эту перемену в нашем мышлении, конечно, спровоцировал Джефф. За время моей работы в Amazon я много раз слышал, как Джефф говорил, что, если мы хотим, чтобы Amazon был местом, где создатели могут создавать, нам нужно исключить общение, а не поощрять его. Когда вы рассматриваете эффективное взаимодействие между группами как «дефект», решения ваших проблем начинают выглядеть совершенно не так, как обычно. Он предложил, чтобы каждая команда разработчиков программного обеспечения создала и четко задокументировала набор прикладных программных интерфейсов (API[26]26
  API – это набор процедур, протоколов и инструментов для создания приложений и инструкция того, как должны взаимодействовать программные компоненты.


[Закрыть]) для всех своих систем/служб. Другими словами, концепция Джеффа заключалась в том, что нам нужно сосредоточиться на слабо связанном взаимодействии через машины с помощью четко определенных API, а не через людей с помощью сообщений электронной почты и совещаний. Это позволит каждой команде действовать автономно и двигаться быстрее.

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

Это привело к возникновению процесса под названием New Project Initiatives (NPI) (Инициативы для новых проектов), задача которого заключалась в расстановке глобальных приоритетов. Не глобальных в смысле географического расширения, а, скорее, для того чтобы решить, какие проекты стоит реализовывать немедленно, а какие могут подождать. Такая расстановка приоритетов действительно оказалась очень сложной. Что важнее – запуск проекта по снижению затрат на доставку, добавление функции, способной увеличить продажи в категории одежды или приведение в порядок старого кода, без которого мы не можем обойтись? Так много чего было неизвестно и так много долгосрочных прогнозов нужно было сравнить. Могли ли мы быть уверены в объеме экономии средств? Знали ли мы, насколько продажи могут вырасти с этой новой функцией в предполагаемых обстоятельствах? Как мы могли оценить финансовую окупаемость реструктурированного кода или стоимость неизвестного количества перебоев в работе, если бы старый код начал давать сбои? Каждый проект был сопряжен с риском, и большинство из них конкурировало за одни и те же скудные ресурсы.

В то время NPI был лучшим решением для продуманного ранжирования наших общекорпоративных предложений и выбора лучших их них. Это никому не нравилось, но для нашей организации тогда это было неизбежным злом.

Вот как работал NPI: раз в квартал команды представляли проекты, которые, по их мнению, стоило бы реализовывать, и для которых потребовались бы ресурсы извне, что в основном было характерно почти для любого масштабного проекта. Подготовка и отправка запроса на NPI занимали довольно много времени. Нужно было предоставить:

• «одностраничник» – письменное изложение сути идеи;

• приблизительный состав вовлеченных команд;

• модель принятия потребителем, если она применима;

• отчет о прибылях и убытках;

• объяснение того, почему для Amazon было бы стратегически важно немедленно приступить к этой инициативе.

Даже простое предложение идеи требовало значительных ресурсов.

Небольшая группа просматривала все материалы, представленные на NPI. Проект мог не пройти отбор в первом раунде, если он не был как следует описан, не отвечал основной цели компании, не представлял приемлемого соотношения затрат/выгод или очевидно не оправдывал ожиданий. Наиболее многообещающие идеи переходили в следующий раунд для выполнения более детального технического и финансового анализа. Этот шаг обычно происходил в режиме реального времени в конференц-зале, где руководитель из каждой основной области мог проанализировать заявку на проект, задать любые уточняющие вопросы и дать оценку того, сколько ресурсов из их области потребовалось бы для завершения проекта в том виде, в котором он представлен. При рассмотрении полного списка проектов обычно присутствовало 30 или 40 участников, что означало долгие-долгие совещания – брр!

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

«Поздравляем, ваш проект был одобрен! Другие команды, которые нужны вам для завершения вашего проекта, тоже готовы приступить к работе».

«Плохая новость в том, что ваш проект не был выбран, но хорошая новость в том, что ни один из утвержденных проектов NPI не требует работы от вас».

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

Многие проекты NPI были представлены с большой погрешностью, то есть с бесполезно широким диапазоном потенциальных затрат и прогнозируемой прибыли. «Мы ожидаем, что эта функция принесет от 4 миллионов долларов в худшем случае и до 20 миллионов долларов в лучшем, и ожидаем, что на ее разработку уйдет от 20 до 40 человеко-месяцев». Сравнивать проекты с такими предварительными расчетами непросто.

Самой сложной задачей для многих проектных команд было точное прогнозирование поведения потребителей. Снова и снова мы убеждались, что потребители вели себя не так, как мы себе это представляли на этапе разработки, особенно в отношении совершенно новых функций или продуктов. Даже самые строгие прогнозы поведения потребителей могли оказаться ошибочными, что приводило к долгим, энергичным обсуждениям, которые всегда казались недостаточно убедительными. (См., например, нашу историю с Fire Phone во введении ко второй части. Мы не действовали из принципа: «Это барахло, но мы все равно собираемся это выпустить». Мы многого ждали от продукта, в который вложили массу времени и денег!)

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

В общем, процесс NPI не был горячо любим. Если вы упомянете NPI в разговоре с любым Амазонцем, который прошел через него, вы, вероятно, увидите в ответ гримасу и, возможно, услышите пару страшилок. Иногда вам везло, ваш проект одобряли, и вы могли двигаться вперед достаточно гладко. Однако вашим планам слишком часто мешали. Вместо того чтобы выполнять жизненно важную работу над чем-то, за что вы отвечаете, вам поручали поддерживать проект другой команды, и при этом заботиться обо всем, что осталось на вашей тарелке. «Быть от-NPI-енным», как мы это называли, означало, что ваша команда не получала ничего, буквально делая все.

Процесс NPI снижал моральный дух. Но выяснение того, как «поднять моральный дух» – не Амазонское дело. У других компаний есть проекты и группы по подъему морального духа с такими названиями, как «Клуб развлечений» и «Комитет по культуре». Они рассматривают моральный дух как проблему, которую необходимо решить с помощью спонсируемых компанией развлечений и социального взаимодействия.

Подход Amazon к моральному духу заключался в привлечении талантов мирового класса и создании среды, в которой у них была бы максимальная свобода изобретать и создавать вещи, чтобы радовать клиентов.

Но вы не сможете этого сделать, если каждый квартал какой-нибудь безликий процесс, такой как NPI, разрушает ваши лучшие идеи.

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

Мы задали себе вопрос: «Как нам это сделать?» Дело не в том, что участники NPI – да и DB Cabal, в сущности, тоже – не оправдали ожиданий или имели гнусные мотивы. Все они были первоклассными, талантливыми, трудолюбивыми людьми, которые плыли против сильного течения зависимостей. Если вы столкнулись с проблемой, которая растет в геометрической прогрессии, встречное решение с равной, но противодействующей силой просто блокирует вас в условиях растущих затрат – это тупиковая стратегия. Нам нужно было найти какой-нибудь способ остановить волну проблем, и мы, наконец, поняли, что самый эффективный способ сделать это – признать, что предположение, в соответствии с которым мы действовали, было ошибочным. В итоге Amazon придумал способ обойти проблему, подавив зависимости в зародыше.

Видя, что наших лучших краткосрочных решений будет недостаточно, Джефф предложил не искать новые способы управления зависимостями, а придумать, как избавиться от них. По его словам, мы могли бы сделать это, реорганизовав инженеров-программистов в более мелкие команды, которые были бы, в сущности, автономными и только в незначительной степени связаны с другими командами и только в тех случаях, когда это неизбежно. Эти, в значительной степени независимые команды, могли бы выполнять свою работу параллельно. Вместо того чтобы лучше координировать свои действия, они могли бы меньше координировать и больше создавать.

Теперь мы подошли к самой сложной части – как именно мы могли бы осуществить такой тектонический сдвиг? Джефф поручил ИТ-директору Рику Далзеллу разобраться. Рик попросил всех сотрудников компании представить свои идеи и объединил их, а затем вернулся с четко сформулированной моделью под названием «команда на две пиццы», о которой люди будут говорить долгие годы. Модель получила такое название, потому что численность команды не должна превышать то количество людей, которые могли бы досыта наесться двумя большими пиццами. Рик считал, что, располагая сотнями таких «команд на две пиццы», мы будем внедрять инновации в поразительном темпе. Эксперимент начнется в подразделении, занимающемся разработкой продуктов, и, если он сработает, то будет распространен и на остальную часть компании. Он описал основные характеристики, рабочий процесс и менеджмент следующим образом.

«Команда на две пиццы» будет:

• Небольшой. Не более чем десять человек;

• Автономной. У них не должно быть необходимости координировать свои действия с другими командами для выполнения своей работы. Имея новую сервисно-ориентированную архитектуру программного обеспечения, любая команда могла просто сослаться на опубликованные прикладные программные интерфейсы (API) для других команд. (Подробнее об этой новой архитектуре ПО будет рассказано ниже);

• Оцениваться с помощью четко определенной «функции приспособленности». Это сумма взвешенного ряда показателей. Пример: команда, отвечающая за расширение выбора товаров в какой-либо категории продуктов, может быть оценена по тому:

1) сколько новых отдельных позиций товара было добавлено за период (вес 50 %),

2) сколько единиц этих новых отдельных позиций было продано (вес 30 %),

3) сколько просмотров страниц получили эти отдельные элементы (вес 20 %);

• Отслеживаться в режиме реального времени. Оценка команды по ее функции приспособленности будет отображаться в режиме реального времени на информационной панели рядом с результатами всех других «команд на две пиццы»;

• Вести определенное направление бизнеса. Команда будет нести ответственность за все аспекты своей области деятельности, включая разработку, технологию и результаты коммерческой деятельности. Этот сдвиг парадигмы устраняет часто слышимые отговорки, такие как: «Мы создали то, о чем нас попросили парни из коммерческой группы, они просто попросили не тот продукт» или «Если бы техническая команда действительно выполнила то, что мы просили, и они сделали бы это вовремя, мы бы достигли своих показателей»;

• Работать под руководством талантливого руководителя широкого профиля. Такой руководитель должен обладать глубокими техническими знаниями, понимать, как проводить наем инженеров-программистов и менеджеров по продукту мирового класса, а также обладать отличным профессиональным суждением;

• Самоокупаемой. Работа команды будет кормить ее;

• Предварительно одобренной С-группой. С-группа должна утвердить формирование каждой «команды на две пиццы».

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

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

Когда «команды на две пиццы» заменили одну большую структуру чем-то более быстрым и гибким, назрела аналогичная реорганизация для большей части архитектуры программного обеспечения: в ней тоже нужно было реализовать концепцию «автономности», сформулированную Риком. В интервью Джиму Грею в 2006 году технический директор Amazon Вернер Фогельс вспомнил еще один переломный момент:

Мы прошли период серьезного самоанализа и пришли к выводу, что сервис-ориентированная архитектура даст нам такой уровень независимости, который позволит быстро и независимо создавать многие программные компоненты. Кстати, это было задолго до того, как понятие «сервис-ориентированный» стало модным. Для нас сервисная ориентация означает инкапсулирование данных с помощью бизнес-логики, оперирующей этими данными, с единственным доступом через опубликованный сервисный интерфейс. Прямой доступ к базе данных извне запрещен, а обмен данными между сервисами отсутствует[27]27
  Джим Грэй (Jim Gray), «Разговор с Вернером Фогелем», Журнал acmqueue 4, № 4 (30 июня 2006): https://queue.acm.org/detail.cfm?id= 1142065.


[Закрыть].

Это непросто объяснить инженерам, не занимающимся программным обеспечением, но основная идея такова: если несколько команд имеют прямой доступ к общему блоку программного кода или некоторой части базы данных, они замедляют друг друга. Независимо от того, разрешено ли им изменять способ работы кода, изменять порядок организации данных или просто создавать что-то, используя общий код или данные, каждый рискует, если кто-то внесет изменение. Управление этим риском требует много времени на координацию. Решение состоит в том, чтобы инкапсулировать, то есть передать владение данным блоком кода или части базы данных одной команде. Любой другой, кому нужно что-то из этой изолированной области, должен сделать хорошо документированный сервисный запрос через API[28]28
  Том Киллалеа (Tom Killalea), «Скорость в разработке программного обеспечения», acmqueue 17, № 3 (29 июля 2019): https://queue.acm.org/detail.cfm?id=3352692.


[Закрыть].

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

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

Сегодня преимущества архитектуры на основе микросервисов хорошо известны, и этот подход принят во многих технологических компаниях. Эти преимущества включают повышенную гибкость, производительность разработчиков, масштабируемость и улучшенную способность устранять и восстанавливать системы после сбоев. Кроме того, с помощью микросервисов становится возможным создавать небольшие автономные команды, которые могут взять на себя какой-либо уровень ответственности за свой программный код, что невозможно при монолитном подходе. Переход на микросервисы снял оковы, которые мешали командам разработчиков программного обеспечения Amazon двигаться быстро, и позволил перейти к небольшим автономным командам.