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

Так же, как и многие другие процессы в Amazon, которые мы обсуждаем в этой книге, процесс Bar Raiser изменился. В то время как основные элементы не изменились с ростом Amazon, многие команды вносили корректировки в определенные части, чтобы решать конкретные проблемы. Не бойтесь делать то же самое.

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

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

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

На момент окончания работы над этой книгой (июнь 2020 года) движение Black Lives Matter беспрецедентным образом ставит вопросы расизма, разнообразия, справедливости и инклюзивности на передний план нашего национального диалога. Достижение многообразия рабочей силы, трудящейся на справедливой и инклюзивной основе, стало сегодня одной из наиболее важных целей для любой компании или организации. В этой книге мы не ставим перед собой задачу предложить решение, поскольку нам ничего не известно о существовании ни проверенного процесса, ни дорожной карты для достижения этой цели. Однако мы можем предположить, что процесс Bar Raiser может быть эффективным компонентом целостного, долгосрочного плана по достижению многообразия, справедливости и инклюзивности.

Процесс Bar Raiser разработан для того, чтобы свести к минимуму личные предубеждения и довести до максимума количество удачных решений по найму, отталкиваясь при этом от качеств каждого кандидата, и того, как эти качества соответствует Принципам Лидерства. Как говорилось ранее в этой главе, личная предубежденность возникает естественным образом при бессистемном процессе интервьюирования и найма. Этапы процесса Bar Raiser, такие как:

• телефонный опрос до проведения интервью;

• заблаговременная подготовка к интервью, которая включает в себя составление вопросов, основывающихся на поведенческих проявлениях;

• обязательное письменное стенографирование интервью;

• повторное чтение стенограмм после интервью (перед проведением оценки);

• построение итоговых совещаний на основании стенограмм интервью;

• проведение итоговых совещаний;

• принятие решения о приеме на работу кандидата на основании Принципов Лидерства – все это шаги, направленные на устранение личной предубежденности. Очевидно, что участие в процессе неоднородной группы людей уменьшит шанс закрасться червячку неосознанной предвзятости.

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

Процесс Bar Raiser сыграл важную роль в укреплении ключевого Принципа Лидерства Amazon «Привлечение и развитие лучших сотрудников». Он показал себя как масштабируемый способ выявления и привлечения руководителей, которые сами по себе играют важную роль в росте и расширении Amazon по всему миру.

Очень важно, что процесс найма Amazon имеет эффект маховика – чем дольше он используется, тем больше дивидендов приносит. В идеале планка по-прежнему должна быть установлена выше возможного, настолько, чтобы сотрудники, в итоге, могли сказать себе: «Я рад, что тогда присоединился к команде. Если бы я проходил собеседование сегодня, я не уверен, что меня взяли бы на работу!»

3
Организация
Отдельное однопотоковое руководство

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

«Лучший способ провалить изобретение чего-либо – сделать это чьей-то дополнительной нагрузкой»[23]23
  Джефф Дайер (Jeff Dyer) и Хал Грегерсен (Hal Gregersen), «Как Amazon продолжает работать “как в первый день”?» Forbes, 8 августа 2017, https://www.forbes.com/sites/innovatorsdna/2017/08/08/how-does-amazon-stay-at-day-one/#efef8657e4da.


[Закрыть].

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

ДИРЕКТОР X (человек, наиболее информированный о новой инициативе): «Как вы знаете, в этом проекте много подвижных частей. На данный момент мы выявили пять нерешенных проблем, которые нам мешают. Это…»

ДЖЕФФ (перебивая): «Прежде чем мы перейдем к этим вопросам, не мог бы кто-нибудь сказать мне, кто является самым старшим однопотоковым лидером по этой инициативе?»

ВИЦЕ-ПРЕЗИДЕНТ ПОДРАЗДЕЛЕНИЯ (ВП1) (после долгой паузы): «Я».

ДЖЕФФ: «Но вы отвечаете за все подразделение. Я хочу, чтобы вы сосредоточились на производительности всей вашей группы, и это включает в себя гораздо больше, чем одна эта инициатива».

ВП 1 (пытается принять удар на себя): «Тогда это, должно быть, я».

ДЖЕФФ: «Итак, это все, над чем вы и ваша команда работаете каждый день?»

ВП 1: «Ну, нет. Единственный человек, который работает над этим полный рабочий день, – это один из наших менеджеров по продукту, но у нас есть много других людей, которые помогают нам по совместительству».

ДЖЕФФ (нетерпеливо): «Есть ли у менеджера проекта все навыки, полномочия и люди в команде, чтобы выполнить эту задачу?»

ВП 1: «Нет, не совсем, поэтому мы планируем нанять директора, который возглавит это».

ДЖЕФФ: «Сколько телефонных интервью и собеседований вы провели на данный момент для поиска этого нового директора?»

ВП 1: «Ну, эта вакансия еще не открыта. Нам еще нужно сформулировать должностные обязанности. Итак, ответ – ноль».

ДЖЕФФ: «Тогда мы обманываем себя. Эта инициатива не перейдет в «зеленую зону», пока не появится новый руководитель. Вот реальное препятствие, с которым столкнулась эта инициатива. Давайте сначала разберемся с ним».

ВП 1 отправляет лаконичное электронное письмо руководителю отдела по подбору персонала с заголовком: «Открыть вакансию директора для управления проектом X…»

* * *

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

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

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

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

Для начала немного предыстории. С 1997 по 2001 год выручка Amazon выросла более чем в 21 раз – от 148 миллионов долларов до более чем 3,1 миллиарда долларов[24]24
  Статистические данные, полученные из открытых финансовых отчетов Amazon 1997 и 2001 годов, https://press.aboutamazon.com/news-releases/news-release-details/amazoncom-announces-financial-results-fourth-quarter-and-1997; https://press.aboutamazon.com/news-releases/news-release-details/amazoncom-announces-4th-quarter-profit-exceeds-sales-and-profit.


[Закрыть]. Рост числа сотрудников, клиентов и почти всего остального имел схожую траекторию. Инновации также внедрялись с бешеной скоростью. Amazon быстро превратился из небольшой компании, которая продавала только книги – и только в Соединенных Штатах – в международную компанию с логистическими операциями в пяти странах, продавая почти все, что можно было купить в Интернете.

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

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

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

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

Я почувствовал на себе проблему с зависимостями в Amazon в первую неделю работы. Наша группа, возглавляемая Ким Рахмелер, отвечала за управление проектами и программами крупных инициатив. Проекты, которыми занималась наша группа, включали в себя запуск наших музыкального (CD) и видео– (VHS/DVD) направлений бизнеса, запуск новых интернет-сайтов в Великобритании и Германии, а также некоторые другие крупные внутренние проекты. Для достижения ключевой бизнес-цели нашим инициативам требовалась координация от нескольких команд.

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

Узнав больше о программе Associates, я быстро понял, что это потенциально очень прибыльный бизнес. В то время было уже 30 000 аффилиатов, и программа быстро росла. Аффилиаты проявили творческий подход с использованием простого набора инструментов, которые мы им предоставили, и обеспечивали постоянно растущий процент общего трафика и продаж для Amazon. Я считал, что программа Associates может стать еще большим вкладчиком в бизнес, но нам придется внести несколько изменений, чтобы реализовать ее огромный потенциал.

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

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

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

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

Программный код был не единственной технической зависимостью, с которой мы столкнулись. Нам также необходимо было внести изменения в основную реляционную базу данных[25]25
  Реляционная база данных – база данных, структурированная для распознавания взаимосвязей между хранимой информацией, такой как клиенты, заказы и отправки товаров.


[Закрыть], от которой зависели все операции Amazon. База данных была названа acb, сокращенно от amazon.com books. Если бы acb когда-нибудь вышла из строя, большая часть операций компании остановилась бы – ни покупок, ни заказов, ни выполнения заказов – до тех пор, пока мы не откатили бы назад это изменение и не выполнили перезапуск.

В качестве жизненно важной меры предосторожности была создана руководящая группа для анализа каждого предложенного изменения в acb, утверждения этого предложения (или отклонения его), а затем определения наилучшего времени для его реализации. Общеизвестным и метким названием этой группы было «DB Cabal» («Совет по базам данных») и состояла она из трех руководителей высшего звена – технического директора, главы команды администрирования баз данных и главы команды обработки данных.

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

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

Запуск нашего проекта был успешным. Но я заметил, что в тех областях, где мы сами контролировали процессы, то есть в отчетности, бухгалтерском учете и изменениях в оплате, а также в нашем маркетинговом плане, мы могли двигаться быстро. А в тех областях, где нам нужно было внести очень незначительные изменения в Obidos и acb, мы двигались крайне медленно. Почему так? Зависимости.

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