Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон
Шрифт:
Интервал:
Закладка:
Происхождение команды на две пиццы
На рубеже тысячелетий Amazon была быстрорастущим стартапом, но ее обновление начало замедляться. По словам тогдашнего директора по информационным технологиям (а ныне – члена правления компании Twilio) Рика Далзелла, кодовая база была невероятно запутанной, а в разработке продукта было несколько крупных направлений вроде обзора и поиска, обработки заказов и корзины покупок. Работа замедлялась, а с кодом становилось работать все сложнее, поскольку им занималось слишком много людей. Помимо проблем с кодом, наблюдался избыток тех, кто принимает решения, – и они вмешивались в работу каждого, поскольку все было тесно взаимосвязано. Как вы понимаете, это сильно напрягало инженеров и менеджеров по продукту, которые пытались реализовать свои идеи, но больше всего это обескураживало генерального директора Amazon Джеффа Безоса.
Почти каждый год Джефф брал неделю на то, чтобы оторваться от дел и спокойно поразмышлять о бизнесе. Эти ежегодные «мозговые штурмы» давали время переосмыслить существующие принципы и завершались обычно появлением ряда одностраничных документов с новыми идеями, которые представлялись команде руководителей. Рик рассказывает, как в 2001 г. Джефф отправился в свой ретрит, озабоченный проблемой замедления темпов обновления. Вернулся он с простой идеей: если создать небольшие команды, дать им свои задачи и сделать владельцами кода, то они снова смогут действовать подобно стартапам, как на заре существования Amazon, когда, по воспоминаниям Джеффа, всю команду можно было накормить двумя пиццами. Но для совместной работы требовалась масса API, обеспечивавших взаимодействие. Это позволило бы действовать независимо, а взаимоотношения команд регулировались бы технологией. Так одностраничный документ дал начало «командам на две пиццы». Рик вернулся к своим подчиненным и в течение недели превратил идею Джеффа в шестистраничный рабочий план, который Amazon быстро приняла.
Команды на дюжину рогаликов
Мы в Twilio к тому времени уже начали преобразовывать компанию в небольшие команды, а разговор в 2012 г. с Дэйвом Шаппеллом лишь укрепил меня во мнении, что это лучший путь масштабирования компании без потери существующих преимуществ.
В самом начале существования в Twilio было всего три разработчика (они же основатели) – это Эван, Джон и я. При таких размерах мы могли держать весь бизнес в голове. В любой момент мы могли выдвинуть новую идею, написать код, поддержать клиентов по электронной почте или телефону, оплатить счета и даже съездить в магазин Costco, чтобы купить канцелярские принадлежности. Мы постоянно создавали демонстрационные приложения поверх наших API и поэтому знали, как обслуживаются наши клиенты. Осуществляя клиентскую поддержку, мы инстинктивно понимали, чего хотят добиться клиенты, где мы дали промашку и куда нужно инвестировать.
Один раз, помню, клиент сообщил в Twitter о нашей ошибке, и я за пять минут написал исправление, но отложил его внедрение на день, поскольку не хотел, чтобы мы казались слишком маленькой компанией. Это было просто исправление ошибки, но случалось, что мы брали идеи клиентов и превращали их в целостные продукты за несколько дней. Одним из них является наша система «субаккаунтов», позволяющая разработчикам сегментировать использование сервисов Twilio на пакеты. Это полезно для софтверных компаний, создающих на основе Twilio свои продукты для многочисленных клиентов. Мы поняли, что такая функция будет полезна, и я написал ее за ночь и добавил на следующий день.
Когда Эвану, Джону и мне нужно было принять решение, мы обычно делали это быстро. Ежедневно мы вплотную занимались переговорами с клиентами, обсуждением архитектуры нашего ПО и совмещением его частей. Мы могли представить, чем обернутся наши решения со временем. Хотя у каждого из нас была своя специализация (Эван писал программы поддержки вычислительной техники, Джон создавал базовые сервисы, а я – API и программы для работы с интернетом и выставления счетов), мы знали достаточно много, чтобы действовать как единый мозговой центр. Когда вы держите всю картину в голове и работаете вместе каждый день, то можете добиваться результата невероятно быстро. В этом сила небольшой команды – в ней нет промежуточных звеньев; вы просто решаете проблемы клиентов напрямую.
В этом и заключается магия, которая делает стартапы такими особенными и продуктивными: у них очень низкие расходы на управление, затраты энергии на координацию ничтожны, а сотрудники имеют сильную внутреннюю мотивацию, поскольку они близки к клиентам и, следовательно, к своей миссии. Успех или провал стартапов зависит от множества факторов, но мотивации и скорости у них обычно хватает. Кому бы не хотелось иметь такую энергию в своем бизнесе? Я ни разу не встречал руководителя, который не хотел бы, чтобы его сотрудники обладали такой внутренней мотивацией и стремлением к успеху, но то, как мы обычно структурируем компании, убивает эти качества. Наши организационные структуры отделяют сотрудников от клиентов, наши процессы принятия решений заставляют сотрудников чувствовать себя лишенными власти, а целью компании становится успех, а не обслуживание клиентов. Почти все компании по мере своего роста в той или иной степени действуют именно так.
В первое время наша троица начинала рабочую неделю с совещания в понедельник, и я по пути на работу покупал нам рогалики, точнее, три рогалика. По мере того, как росла наша компания, увеличивалось и число присутствующих на совещаниях в понедельник, а вместе с этим и количество рогаликов. Вскоре я покупал полдюжины рогаликов, затем дюжину, потом две дюжины, три… С ростом объема закупок рогаликов мне становилось все труднее и труднее держать весь бизнес в голове (как, впрочем, и нести рогалики). Кроме того, я заметил, что наш
