Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [65]

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

Глава 8 Небольшие команды и «однопоточные» лидеры

Многие проблемы очень трудно решить «сверху вниз».

МЕГАН СМИТ, ДИРЕКТОР ПО ТЕХНОЛОГИЯМ США

В 1998 г. мой друг Дэйв Шаппелл (нет, не комик Дэйв Шаппелл!) стал примерно сотым сотрудником молодой компании Amazon.com. Он помог запустить Amazon Marketplace, Amazon Associates, Amazon Auctions и некоторые другие платформы. Именно он пригласил меня в AWS в 2004 г. К тому времени в компании работало уже примерно 5000 человек, а Дэйв покинул Amazon, чтобы основать стартап TeachStreet. Восемь лет спустя, в 2012 г., Amazon приобрела этот стартап, и Дэйв снова оказался в этой компании, где к тому времени работало более 75 000 человек.

Вскоре после его возвращения в Amazon в 2012 г. я позвонил ему с простым вопросом: «Чем, на твой взгляд, отличаются три компании – Amazon со 100, с 5000 и теперь с 75 000 сотрудников?» Он задумался на несколько мгновений, а затем сказал следующее: «Знаешь, это одна и та же компания. То же чувство срочности. Та же быстрая походка сотрудников. Тот же интеллект. Это потрясающе». В 1998 г. в офисе Amazon в Сиэтле был один этаж, полный сотрудников, полный суеты и энергетики, свойственной для стартапа. В 2012 г. картина осталась той же, только таких этажей, занятых стартапами Amazon, было почти тысяча по всему миру. Способность Amazon масштабировать свою культуру с таким размахом действительно поражает.

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

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

То же самое можно сказать и о небольших командах в крупной компании, и именно поэтому они имеют решающее значение. Структура Amazon, состоящая из команд численностью не более 10 человек, позволяет масштабировать компанию без потери чувства срочности, сфокусированности и качества талантов, характерных для стартапа. Помимо прочего, она не затрудняет сотрудничество, которое только усиливается с увеличением размера компании. Сложность координации деятельности компании по мере ее роста возрастает почти экспоненциально. Если вы сталкиваетесь с подобным в своей компании, знайте: в этом не ваша вина, это простая математика. Координация команды из 10 человек требует 45 связей между людьми, из 100 человек – почти 5000 связей, а из 1000 человек – почти 500 000. Amazon со штатом 75 000 человек в 2012 г. могло бы потребоваться 2,8 млрд связей, что сделало бы ее в 500 000 раз более сложной и запутанной по сравнению с компанией из 100 человек, которой она была вначале. Но этого не случилось. Это по-прежнему та же компания – современное чудо, построенное на основе небольших команд.

Происхождение команды на две пиццы

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

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