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

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

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

1. У команды была четко определенная цель. Например, команда намеревается ответить на вопрос: «Сколько запасов данного продукта следует покупать Amazon и когда нам следует его покупать?»

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

3. Показатели, используемые для измерения хода работы, были согласованы. Например, количество отображаемых страниц продуктов, имеющихся на складе, разделенное на общее количество отображаемых страниц продуктов, составляет 60 %, а стоимость хранения запасов составляет 40 %.

Важно отметить, что конкретные действия команды для достижения цели на встрече не обсуждались. Это было делом команды – определиться с планом самостоятельно.

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

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

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

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

Хорошо подготовленная «команда на две пиццы» имела еще одно важное преимущество. Она лучше корректировала курс: выявляла и исправляла ошибки по мере их появления. В письме акционерам от 2016 года, хотя Джефф и не говорил прямо о «командах на две пиццы», он предположил, что

«большинство решений, вероятно, следует принимать при наличии примерно 70 % желаемой информации. Если вы ждете 90 %, в большинстве случаев вы, вероятно, медлите. К тому же, в любом случае, вам нужно уметь быстро распознавать и исправлять плохие решения. Если вы умеете корректировать курс, то ошибиться может быть дешевле, чем вы думаете, а медлительность наверняка обойдется дорого»[29]29
  Джефф Безос (Jeff Bezos), «Письмо к акционерам», 2016, Первый день, https://www.sec.gov/Archives/edgar/data/1018724/000119312517120198/ d373368dex991.htm.


[Закрыть].

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

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

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

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

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

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

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

Во-первых, команды тратили неоправданно большое количество времени, пытаясь понять, как построить наиболее значимую функцию приспособленности. Должна ли это быть формула типа 50 % для показателя A плюс 30 % для показателя Б плюс 20 % для показателя В? Или это должно быть 45 % для показателя A плюс 40 % для показателя Б плюс 15 % для показателя В? Вы можете себе представить, как легко было потеряться в этих дебатах. Эти обсуждения стали менее полезными и крайне отвлекающими – просто еще один спор, в котором людям нужно было выигрывать.

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

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

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

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

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

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

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

То, что первоначально называлось лидером «команды на две пиццы» (2PTL), превратилось в то, что теперь известно как однопотоковый лидер (STL). STL расширяет базовую модель отдельных команд, чтобы обеспечить их ключевые преимущества в любом масштабе, необходимом для проекта. Сегодня, несмотря на свой первоначальный успех, мало кто в Amazon все еще говорит о «командах на две пиццы».

Мы говорим, что STL больше и лучше, но лучше чего именно? Безусловно, это лучше по сравнению с «командой на две пиццы», из которой она выросла, но лучше ли это чем другие альтернативы? Чтобы ответить на этот вопрос, давайте рассмотрим более распространенный подход к разработке чего-то нового.

Обычно руководитель, которому поручено продвигать какое-либо новшество или инициативу, обращался к одному из своих подчиненных, возможно, к директору или старшему менеджеру, который мог нести ответственность за пять из всех 26 инициатив данного руководителя. Этот руководитель просил директора указать одного из тех непосредственных подчиненных – скажем, менеджера проекта, – который добавит проект в свой список дел. Менеджер проекта, в свою очередь, просил технического директора посмотреть, сможет ли одна из их команд разработчиков втиснуть эту работу в свой план работ по разработке. Старший вице-президент Amazon по устройствам Дэйв Лимп красиво резюмировал, что может произойти дальше:

«Лучший способ потерпеть неудачу в изобретении чего-то – сделать это чьей-то подработкой»[30]30
  Дайер и Грегерсен, «Как Amazon продолжает работать “как в первый день”?»


[Закрыть].

Amazon на собственном горьком опыте узнал, как отсутствие однопотокового лидера может помешать им в реализации новых инициатив. Одним из примеров является Fulfillment by Amazon (FBA). Первоначально он назывался как Self-Service Order Fulfillment (самообслуживание при выполнении заказов) (SSOF), и его цель заключалась в том, чтобы предлагать торговым компаниям складские и транспортные услуги Amazon. Вместо того чтобы самостоятельно заниматься хранением, сбором, упаковкой и доставкой, торговые компании отправляли товары на Amazon, и мы занимались логистикой оттуда. Руководители команд розничной торговли и ведения бизнеса думали, что это большая и интересная идея, но более чем за год она не получила большой популярности. Это всегда было «вот-вот», но на самом деле ничего так и не произошло.

Наконец, в 2005 году Джефф Уилке попросил Тома Тейлора, тогдашнего вице-президента, отказаться от других обязанностей и дал ему разрешение нанять и укомплектовать команду. Только тогда SSOF взлетел, превратившись в итоге в Fulfillment by Amazon. FBA был запущен в сентябре 2006 года и имел огромный успех. Сторонним продавцам это понравилось, потому что, предложив им складские помещения для их товаров, Amazon превратила их складские помещения в переменные издержки, а не в постоянные. FBA также позволил сторонним продавцам воспользоваться преимуществами участия в Prime, что, в свою очередь, улучшило клиентский опыт для покупателей. Как сказал Джефф в письме к акционерам: «Только за последний квартал 2011 года сервис Fulfillment by Amazon от имени продавцов отгрузил десятки миллионов товаров»[31]31
  Джефф Безос (Jeff Bezos), «Письмо к акционерам», 2011, https://www.sec.gov/Archives/edgar/data/1018724/000119312512161812/d329990dex991.htm.


[Закрыть].

Руководители, которые пытались запустить этот сервис до того, как его взял на себя Том Тейлор, были исключительно способными людьми, но, из-за того, что они выполняли другие свои обязанности, у них просто не хватало пропускной способности для управления тем несметным количеством деталей, которые охватил FBA. Запуск FBA был бы, в лучшем случае, намного медленнее и сложнее, если бы Джефф Уилке не освободил Тома, чтобы тот сосредоточился только на одном проекте. Концепция однопотокового лидера еще не была официально внедрена в Amazon, но Том стал важным предшественником.

Другой важный компонент модели STL – это отдельная однопотоковая команда, управляемая однопотоковым лидером вроде Тома. Как объясняет Джефф Уилке: «Отдельная означает почти такую же отделенность в организационном плане, как API-интерфейсы соотносятся с программным обеспечением. Однопотоковый означает, что они не работают больше ни с чем»[32]32
  Тейлор Соупер (Taylor Soper), «Совет по руководству: как Amazon сохраняет концентрацию, конкурируя в таком большом количестве областей одновременно», Geek Wire, 18 июля 2017, https://www.geekwire.com/2017/leadership-advice-amazon-keeps-managers-focused-competing-many-industries/.


[Закрыть].

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

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

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

сохраняйте упорство в общем видении вопроса и гибкость в деталях.

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