Поддержка внедрения инноваций и ускорение с помощью небольших команд Amazon

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

Джефф писал: «Установление высокой планки в нашем подходе к найму персонала было и будет оставаться важнейшим элементом успеха Amazon.com».

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

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

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

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

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

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

Эта гипотеза нашла подтверждение в исследованиях, посвященных трудовым ресурсам: исследование Gallup о состоянии рабочих мест в Америке показало, что в компаниях со штатом менее 10 сотрудников уровень вовлеченности составляет 42 % и выше, в то время как средний уровень вовлеченности в крупных организациях составляет менее 30 %.

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

► Послушайте подкаст: C-Suite Strategies for Leading Significant Change (о стратегиях для руководителей высшего звена по управлению значительными изменениями)

Небольшие команды (так называемые «команды на две пиццы») – это не только размер в контексте организации процессов, но и стимулирование ответственности и независимости на командном уровне.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Amazon и AWS существует множество различных повествований. Некоторые из них посвящены запуску новых продуктов, например документа PR/FAQ (т. е. документа о пресс-релизах / вопросах и ответах), который является результатом подхода «работа в обратном направлении». Остальные предоставляют собой операционные бизнес-обзоры (часто еженедельные, ежемесячные и ежеквартальные), благодаря которым обеспечивается анализ ключевых показателей, тенденций, противоречий, рисков и возможностей, возникающих в команде компании, а также управление ими.

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

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