Привет! Я — Джефф, и я — разработчик

Каждые две недели мы собираем группу новых сотрудников Twilio. Я провожу с ними получасовое рабочее собрание — и начинаю его так: «Привет! Я — Джефф, и я — разработчик программного обеспечения». Все они знают меня как генерального директора и основателя компании, но я по-прежнему считаю себя разработчиком. В очень многих компаниях цифровой эры существует разрыв между руководителями и разработчиками, фактически осуществляющими цифровую трансформацию. Я надеюсь, что эта книга поможет устранить его, позволив разработчикам, менеджерам и руководителям говорить на одном языке. Как генеральный директор публичной компании и разработчик я смотрю на вещи иначе, чем большинство руководителей, как, впрочем, и большинство разработчиков. Я вижу проблемы и успехи сотрудничества между менеджерами и разработчиками с двух сторон. Чтобы понять идею «Спросите разработчика», полезно познакомиться с моей карьерной эволюцией. Хотя сегодня я генеральный директор, я начал свою трудовую жизнь как программист-самоучка и создатель ПО. Я хочу выделить поворотные моменты моей жизни, которые привели к методологии «Спросите разработчика».

Я вырос в пригороде Детройта, в городке под названием Уэст-Блумфилд. Моя мать была преподавателем математики, а отец — рентгенологом. В начале 1980-х гг. рентгенология была полностью аналоговой. Больница получала от компании Kodak коробки, где было порядка десятка листов пленки, разделенных прокладками из белой плотной бумаги. В больнице бумагу просто выбрасывали — имейте в виду, это было до того, как переработка отходов набрала силу, — и мой отец приносил ее домой и складывал в аккуратную стопку у себя в комнате.

По выходным, когда нам было скучно и хотелось посмотреть телевизор, отец говорил: «Давай сделаем проект!» Мы вытаскивали коробку, полную листов разного размера, и он продолжал: «Что бы ты хотел сделать?» Я говорил что-нибудь вроде: «Давай сделаем робота», или «Давай сделаем видеомагнитофон»», или «Давай сделаем рентгеновский аппарат» — и мы принимались за работу. Например, мы складывали из бумаги коробку размером примерно с видеомагнитофон, а потом я рисовал фломастером кнопки «Воспроизведение», «Пауза», «>>», «<<» и т.п. Я рисовал порт для загрузки кассеты Betamax — да, у нас дома был видеомагнитофон формата Betamax! И всегда, когда мы заканчивали процесс создания, я задавал вопрос, которого боялся мой отец: «Папа, как мы можем сделать так, чтобы это действительно работало?» Если бы отец обладал способностями папы Карло, создавшего Буратино, то он бы, наверное, смог оживить видеомагнитофон, робота… да что угодно, созданное в этот день. Но, увы, оживить наши «проекты» он не мог, и это расстраивало нас обоих.

Так или иначе, мне захотелось создавать. Мне нравилось, что можно просто взять инструменты и материалы и создать что-то. Даже если это что-то не работало… до поры до времени.

В 1983 г. мы приобрели наш первый компьютер, Apple IIe, и я открыл для себя бейсик — простой язык программирования, на котором можно попросить компьютер сделать то, что вы от него хотите. Я начал с глупостей элементарного программирования, вроде:

10 PRINT “Hello World”

20 GOTO 10

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

В 1990 г. наша семья приобрела свой первый персональный компьютер — 386DX с рабочей частотой 20 МГц компании CompuAdd. Это был зверь — огромный бежевый ящик, весивший не меньше 13 кг. На протяжении многих лет я копался во внутренностях этой машины, обновляя железо и софт с Windows 3.0 до 3.1. Периодически я решался на глупости, например удалял на диске C файл command.com или баловался с текстом файла autoexec.bat. К счастью, мой дядя Джерри жил в нашем квартале по соседству, и я мог сбегать к нему, чтобы скопировать его файл autoexec.bat и вернуться к делу.

Я стал тем парнем, который «разбирается в компьютерах». Когда кто-нибудь спрашивал меня, почему у него не работает мышь или почему не загружается компьютер, я обычно не знал конкретного ответа, но зато мог просто залезть в компьютер и устранить проблему. И действительно, я не делал хуже! С компьютером 386DX я научился копаться в железе и программах и баловаться с ними. Я осознал, что даже если испортишь программу, то ее всегда можно исправить. Во многом в этом и заключается суть создания ПО.

Но лишь поступив в колледж, я по-настоящему проникся интересом к программированию. Когда я поступил в Мичиганский университет в 1995 г., большинство сокурсников упивались прелестями обретенной в 18 лет свободы: вечеринки, алкоголь, девчонки, парни… Но что действительно взволновало меня, так это разъем локальной компьютерной сети в моей комнате в общежитии! Впервые у меня был доступ к постоянному интернет-подключению со скоростью 100 Мбит/с, что намного превосходило наше домашнее коммутируемое подключение со скоростью 28 800 кбит/с. Первое, что я сделал после того, как попрощался с родителями, — загрузил по протоколу FTP копию браузера Netscape Navigator 1.0.

Прощайте, сетевые сервисы America Online, здравствуй, «настоящий» интернет! Это случилось буквально через несколько недель после первоначального публичного размещения акций компании Netscape, заставшего мир врасплох, и я оказался одним из миллионов, впервые открывших для себя интернет в эти месяцы.

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

Но еще более интересными оказались «динамические» сайты, которые только начали появляться в то время — они не просто отображали контент. позволял просматривать книги и даже покупать их! Сайты Yahoo, Lycos и AltaVista искали все что угодно. На MapQuest можно было найти любую точку планеты и получить пошаговые инструкции!

Самым удивительным в этих сайтах было то, что кто-то мог написать программу для них. Но теперь, в отличие от эпохи компьютера Apple II, любой пользователь интернета мог взаимодействовать с кодом. Я мог обратиться уже не только к своим родителям, а к огромной аудитории — написать нечто, что могли бы использовать миллионы людей. Внезапно это стало реальностью. Это была не игрушка для ребенка, а реальный мир.

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

Летом 1997 г., после двух лет изучения курса информатики, я попал на стажировку в компанию Citysearch в Пасадене, штат Калифорния, расположенной в горах к северо-востоку от Лос-Анджелеса. Citysearch имела один из первых крупных сайтов. Ее продуктом был «путеводитель по городу», рассказывающий обо всем, что можно сделать в вашем городе. Незадолго до моего приезда в июне 1997 г. компания перестроила систему управления контентом (CMS), которая позволила ей обновить сайт, и эта новая версия имела новый формат файлов. (Да, данные хранились в файлах и даже не в базе данных!) В первый же день мой менеджер приветствовал меня и изложил задание: мне нужно было преобразовать файлы из старого формата в новый. Он выдал мне компьютер, описания старых и новых форматов файлов и выделил рабочее место.

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

В результате я приходил каждый день на стажировку, сидел за своим столом с 9:00 до 17:00 и копался в интернете. Я изучил новый язык программирования Cold Fusion, набиравший популярность у создателей интернет-приложений. Тем летом я вернулся в Анн-Арбор с желанием начать свое дело.

Я всегда полагал, что лучший способ узнать что-то новое — это взять обязательство перед «клиентами» и заставить себя учиться новому. Поэтому вместе с друзьями, разделявшими мое увлечение интернетом, — Брайаном Левином и Майклом Красманом, — я стал придумывать интернет-продукты, которые можно было бы создать. У нас родился целый ряд идей, но лишь одна из них воплотилась в жизнь.

По всему кампусу в Анн-Арборе были расклеены рекламы компаний, занимающихся конспектированием. Эти небольшие фирмочки с названиями вроде «Грустные конспекты», «Превосходнейшие конспекты» или «Конспекты высшего уровня» работали в копировальных центрах по всему кампусу. Примерно за $50 за курс в семестре вы могли купить конспекты у какого-нибудь очень умного, прилежного студента — ну, знаете, парня в первом ряду аудитории — и учиться по его конспектам, а не по своим собственным, но дрянным. Заплатив $50, после каждой лекции вы тащились по снегу через весь город, чтобы забрать физическую копию конспектов. Эти услуги были довольно популярны, особенно у тех, кто посещал вводные лекции, которые могла слушать тысяча первокурсников.

Мы с Брайаном и Майком решили, что интернет будет лучшим каналом получения этих конспектов, нежели хождение по снегу несколько раз в неделю. Вы можете сидеть в удобной комнате общежития и просматривать свои конспекты в интернете… При большом числе студентов, слушающих сравнительно немногочисленные мегакурсы («Психология», «Экономика» и т.д.), нам требовалось очень немного тех, кто пишет конспекты, чтобы покрыть потребности почти всех первокурсников, а их было 5000, если взять Университет штата Мичиган. А ведь такие услуги пользовались популярностью практически во всех колледжах и университетах. Мы прикинули «на салфетке» и обнаружили, что вся «индустрия» конспектов — это колоссальный рынок размером $15 млн. Поэтому мы решили не продавать конспекты, что в 1997 г. было бы очень трудно сделать в интернете, а просто устроить их бесплатную раздачу. Рекламный рынок был намного больше рынка конспектов лекций, поэтому мы могли бы получать выгоду от размещения рекламы местных и национальных компаний на конспектах.

Мы решили назвать наше предприятие , зарегистрировали доменное имя и приняли неофициальный слоган: «Мы не одобряем пропуск занятий. Мы просто помогаем тем, кто пропустил их». Как вы можете догадаться, услуга оказалась очень популярной. Какой студент не хотел бы получить бесплатные конспекты лекций, не выходя из комнаты в общежитии? Вскоре мы распространили свою деятельность на второй кампус — Университета штата Мичиган, а затем и на кампусы всей большой десятки университетов Среднего Запада.

Осень 1998 г. принесла бум доткомов. Возможность принять участие в нем была слишком заманчива, чтобы упустить ее. Мои соучредители и я бросили учебу, чтобы посвятить развитию компании все свое время. Мы вложили $1 млн от друзей и наших семей и расширяли офис три раза за полгода, поскольку постоянно нанимали друзей по колледжу и даже взрослых, пожелавших присоединиться к нашему делу. Мы переименовали компанию в , а летом 1999 г. привлекли $10 млн от известной венчурной компании Кремниевой долины Venrock Associates и перевели нашу компанию, 50 человек, из Мичигана в Кремниевую долину. Мы продолжали расти. У нас появилась команда профессиональных управленцев, которые, честно говоря, были в первую очередь заинтересованы в продаже компании. Что и было сделано.

В январе 2000 г. мы продали с расчетом акциями другой компании, работающей со студентами колледжей , которая только что подала заявку на публичное размещение акций. Однако CollegeClub отозвала свою заявку, чтобы завершить приобретение Versity, и к тому времени, когда они снова подали ее — в апреле 2000 г., — время было упущено, пузырь доткомов лопнул, и компания теряла порядка $30 млн в месяц. В августе 2000 г. она объявила о банкротстве. Наши акции ничего не стоили.

Всего за полтора года мы прошли путь от небольшого проекта, придуманного нами во время учебы, до компании, которую инвесторы оценивали в $150 млн в преддверии публичного размещения акций на бирже, и предприятия, которое снова ничего не стоило. Это была каноническая история взлета и падения доткомов. Оглядываясь назад, я вижу, что эта затея была абсолютным дерьмом. Нам было по 21 году, мы действовали без бизнес-модели, но получали от инвесторов миллионы долларов. За время жизни компании мы потратили более $10 млн и получили доход порядка $14 000. Но доход не был целью — инвесторы о нем не спрашивали, а члены совета директоров не задумывались. Все, о чем кто-либо заботился, это привлечение клиентов. А тут мы были на коне — нашу аудиторию составляли миллионы студентов колледжей, которые посещали наш сайт еженедельно и даже ежедневно. Здесь мы выполнили свой план и даже перевыполнили его. Несмотря на неудачу с доткомами, у меня появился интерес к предпринимательству. Я также узнал, что в случае неудачи можно очень многому научиться и настроиться на следующий шаг. Закончилась ли моя карьера? Нет, она только начиналась.

Примерно в то же время мой друг Джефф Флюр написал бизнес-план для компании под названием Idrenaline Inc. Идея состояла в создании сайта, где люди могли покупать и продавать билеты на мероприятия — спортивные состязания, концерты и многое другое, — не обращаясь к спекулянтам. Так вот, у Джеффа и его соучредителя Эрика Бейкера был бизнес-план, и они начали искать инвесторов, хотя 2000 г. был не лучшим временем для вложений в доткомы. Джефф и Эрик были банкирами и никогда не управляли компанией. Идея выглядела очень заманчиво, а у меня не было никакого желания оставаться в CollegeClub, поэтому я согласился присоединиться к ним в качестве первого директора по технологиям и помочь в создании сайта, формировании команды разработчиков и вообще запуске бизнеса. Мы понимали, что нам нужно более интересное название, и Джефф предложил словосочетание Liquid Seats, которое у меня ассоциировалось с жидким стулом. Мой друг Дейв Брюан, руководивший маркетингом в Versity, также присоединился к Idrenaline в качестве главы отдела маркетинга. Он придумал название StubHub. Джефф также нанял Мэтта Левенсона, важную фигуру в истории методологии «Спросите своего разработчика», о котором еще будет сказано в этой главе, в качестве операционного директора.

Была середина 2000 г., и мы отчаянно пытались успеть к началу осеннего сезона Национальной футбольной лиги. Это был безумный рывок. Мы занялись поиском путей получения первой партии билетов и привлечения покупателей. Используя свой старый опыт видеосъемки, я сделал рекламный видеоролик и попытался организовать что-то вроде вирусного маркетинга. Мне еще не приходилось создавать коммерческий сайт, писать код для онлайн-оплаты кредитной картой и вообще задумываться о том, как работают аукционы, но именно это делало процесс захватывающим. Я собрал небольшую команду, перед которой стояла задача запустить сайт в сентябре — от написания первой строки кода до запуска сайта у нас было примерно шесть недель. Неистовое напряжение в стремлении запустить StubHub стало настоящим откровением. Мне понравилась та быстрота, с которой мы взяли идею, создали первую версию сайта и передали ее в руки клиентов. С такой скоростью мы могли дорабатывать сайт непрерывно.

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

Именно тогда меня пригласил на обед Кевин О’Коннор, основатель и генеральный директор ведущей рекламной сети в интернете той эпохи, компании DoubleClick. Они фактически создали основы баннерной рекламы и представляли первую волну монетизации интернета. Кевин был бизнес-ангелом для Versity, и мы не теряли связи. Во время обеда я сказал ему, что хотел бы заняться чем-нибудь новым, а он ответил, что с удовольствием стал бы сотрудничать со мной. Я подкатился с предложением к Мэтту Левенсону, который работал и в Versity, и в StubHub.

Мы перебрали чуть ли не тысячу идей, исследовали около полусотни самых достойных из них и написали без малого 20 бизнес-планов, но в конце концов идея пришла с неожиданной стороны. Мэтт вырос в Санта-Барбаре, штат Калифорния, и был свидетелем взрывного роста популярности экстремальных видов спорта — скейтборда, серфинга, сноуборда и трюкового велоспорта. Однако товарами для подобных видов спорта торговали исключительно мелкие семейные магазинчики. Это хорошо, пока спорт является нишевым, но, как только он становится массовым, у покупателей, на взгляд Мэтта, появляется желание ходить в гипермаркеты с предсказуемым временем работы, с хорошей политикой возврата товаров и с широким выбором, т.е. пользоваться всем тем, что предлагает интернет-магазин REI для спорта на открытом воздухе. Мы принялись за работу, гадая, как должен выглядеть такой магазин для экстремальных видов спорта.

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

Однако меня одолевали сомнения. Я спросил Мэтта, зачем разработчику вроде меня открывать магазин товаров для экстремальных видов спорта, если сам я не занимаюсь ни одним из них. Мы обсудили технологию, которая будет обеспечивать высокий уровень обслуживания покупателей и преимущества создания розничного магазина с нуля в 2001 г. без каких-либо устаревших технологий. Мы могли создать все, что хотели, чтобы порадовать наших клиентов и повысить эффективность работы магазинов. Эта идея заинтриговала меня, поэтому я сел в машину с Мэттом, и мы вернулись в солнечную Калифорнию — на этот раз в Лос-Анджелес, который является средоточием всех экстремальных видов спорта.

Я и Мэтт принялись за работу. Мы остановились на названии Nine Star, которое мне не понравилось, но оно было лучше нашего рабочего названия Rough Riders. После приобретения помещения Мэтт и наша команда сосредоточились на оборудовании магазина и доставке товаров в него, а я занялся созданием программного обеспечения для поддержки работы магазина. Для меня это был уникальный шанс понять, как действует вся технология розницы, и создать нечто более удобное, чем есть в большинстве магазинов. За свою жизнь я бывал в бесчисленных розничных магазинах и тысячи раз видел, как кассиры пользовались лазерным сканером, считывали мои кредитные карты и печатали чеки. Теперь мне предстояло погрузиться в эту тему и узнать, как работает вся эта технология. Что происходит, когда лазерный луч попадает на штрихкод на наклейке на товаре? Какая информация вообще закодирована на магнитной полоске кредитной карты? Откуда ящик кассы знает, когда ему открыться?

Я оформил все это как веб-приложение, поскольку интернет был тем, что я знал. На языке PHP я создал полную систему обслуживания кассовых терминалов — ПО, используемое в розничной торговле для оплаты покупок, приема наличных денег и кредитных карт, печати чеков и многого другого. Из-за того, что я создал цельную систему, у меня была возможность достраивать ее и менять по собственному желанию. Когда нам понадобилась членская программа, я легко встроил ее в систему. Каждого нового клиента мы спрашивали, не хочет ли он стать членом нашего клуба. Если он соглашался, кассир вводил его имя и адрес электронной почты и делал снимок маленькой веб-камерой. Через 30 секунд из кассы выскакивала полноцветная членская карточка. Подростки были от этого в восторге! Карточки Nine Star очень смахивали на кредитные карты. Мы решили, что участники будут получать «возврат» в размере 20% от суммы, потраченной ими за год, который становится доступным в феврале (когда мы освобождали склад от оставшихся после рождественских праздников запасов). Я встроил в систему обслуживания кассовых терминалов возможность использования «возвращенных денег».

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

Разработчику необходима глубокая концентрация, чтобы держать всю систему в голове. Это называется потоком — такое состояние, когда разум погружен в проблему и вы выполняете невероятные объемы работы. Погружение в базу исходного кода, понимание того, как определенная часть кода должна работать, требует невероятной концентрации. А возможности сосредоточиться при работе в подсобке спортивного магазина как раз и не хватало. Мы сделали все доступные пространства в магазине пригодными для катания, чтобы дети могли носиться по магазину как по скейт-парку. Им это нравилось, а я ненавидел такой подход. Меня постоянно отвлекали громкие звуки и крики работников магазина.

Однажды, когда я был глубоко погружен в свои мысли, один из сотрудников магазина забежал в подсобку. Он похлопал меня по плечу.

— Эй, чувак. Сайт не работает?

Я снял наушники, раздраженный тем, что мне помешали.

— Ты спрашиваешь меня об этом или сообщаешь это мне?! — прорычал я.

Парень медленно попятился, и до меня дошло, во что я превратился: я был сварливым компьютерщиком в подсобке, с которым никто не хотел разговаривать. Именно тогда стало ясно, что мне не место в магазине.

Работая над всеми этими крутыми технологиями в Nine Star, я наблюдал, как из неизвестности поднимается Google и превращается в высокотехнологичного гиганта, как с каждым днем росла Amazon, добавляя на сайт новые категории товаров. Компании, пережившие крах доткомов, начали определять нашу жизнь. Я хотел вернуться в компьютерные технологии, а не в подсобку спортивного магазина. Кроме того, в Nine Star было плохо с деньгами. Все наши средства уходили на закупку товаров. Мы с Мэттом не получали зарплату уже три года, и это оборачивалось очень плохим состоянием моего банковского счета и превышением лимитов по кредитным картам. В забегаловке Subway через дорогу от Nine Star каждый день после 17:00 проходила акция «Два по цене одного», и я покупал там сэндвич за $3,99 на ужин и оставлял второй сэндвич на обед на следующий день. В какой-то момент у мексиканской сети фастфуда Baja Fresh на сайте появился купон на бесплатную тарелку буррито. Это было еще на заре интернета, и, похоже, в Baja Fresh не понимали, что веб-купон можно распечатывать сколько угодно раз. Мэтт и я ели бесплатные буррито два раза в день почти три месяца, пока нас не поймали. Такая вот предпринимательская деятельность.

Размышляя о том, что делать дальше, я подбивал итоги. Итак, я участвовал в создании трех стартапов. Я подключался к процессу в самом начале, когда несколько человек в гараже (или в моем случае в спортивном магазине) пытались сделать что-то из ничего. Но у меня не было опыта работы в большой компании, кроме той летней (на самом деле однодневной) стажировки в Citysearch. Если я захочу однажды создать значимую компанию, то мне нужно узнать, как работают крупные компании. Что работало хорошо? К чему мне следует стремиться в своем следующем стартапе? Что перестает работать, когда компании становятся большими? Каких ловушек следует избегать? Мне нужно было узнать, как работает бизнес, как управлять, руководить и масштабировать быстрорастущую организацию. Стартап — это просто быстрый забег, но как работают реальные компании? Я хотел это выяснить. Также не помешало бы получить зарплату и пополнить свои финансы.

Осенью 2004 г. я принял предложение от платформы AWS и переехал в Сиэтл. Я всегда работал в ничего не имеющих стартапах с теми исполнителями и бюджетами, какие удалось добыть. А теперь это была совершенно другая история — работа в компании мирового уровня и со специалистами мирового класса. Я узнал, как работают такие крупномасштабные системы. Я узнал о технологиях, которые компания разработала, чтобы совладать с масштабами Amazon, о распределенных системах, согласованном хешировании, идемпотентности, теореме Брюера. Все это выходило далеко за пределы того, с чем я имел дело раньше. В момент моего приезда в Сиэттл в AWS, где я стал менеджером по продукту, там трудилось около 30 человек, располагавшихся на шестом этаже Тихоокеанского медицинского центра — старой больницы в стиле ар-деко, которая была преобразована в головной офис компании Amazon. Джефф Безос работал на седьмом этаже, и, если вы оказывались рядом с ним, это означало, что он заинтересован в вашей работе. AWS была его любимым детищем — именно поэтому мы и находились на шестом этаже.

Мы создавали продукты не для потребителей, а для разработчиков вроде меня. Люди, с которыми я работал, действительно изобретали что-то новое. Переосмыслялось все без исключения — продукты, маркетинг, даже ценообразование. Мой напарник по офису Дейв Барт был первым менеджером по перспективному продукту под названием Simple Storage Service, или сокращенно S3, призванного революционным образом преобразовать рынок цифровых хранилищ. Я был назначен на продукт, который позже получил название Flexible Payment Service (FPS). Цель этого платежного сервиса состояла в том, чтобы позволить разработчикам принимать платежи в своих собственных приложениях. Точно так же, как S3 давал разработчикам доступ к облачному хранилищу данных, FPS давал разработчикам доступ к платежной инфраструктуре, которой пользовался крупнейший сайт электронной коммерции в мире. Мы, бывало, шутили, что S3 не зря называют простым сервисом хранения данных, а FPS — гибким платежным сервисом. Наш продукт был в конечном счете слишком сложным и с трудом запускался. Тем не менее это был удивительный опыт. Несмотря на то что Amazon казалась мне огромной компанией, сама она считала себя стартапом. Вся компания была разделена на небольшие команды «на две пиццы», каждая из которых работала как крошечный стартап. В них был дух срочности и энергия, а то, что делалось, имело значение. Там изобретали будущее — вы должны делать все, чтобы ваши технические специалисты обрели именно такое чувство.

Помимо прочего, в компании Amazon меня поразило то, насколько большим влиянием и свободой в принятии решений пользуются разработчики. Во главе многих проектов в то время были не бизнес-руководители, а ведущие инженеры. Неофициально программу S3 возглавлял директор по технологиям Amazon Ал Вермюлен. Моим проектом FPS руководил инженер по имени Викас Гупта, который создал большую часть розничных платежных систем Amazon. Бизнес-руководители, такие как Энди Джесси, обеспечивали общее руководство, но на деле создавали среду для процветания технических лидеров и повышения стоимости бизнеса. Этот опыт укрепил мою веру в разработчиков как в великих потенциальных бизнес-руководителей — основополагающий элемент методологии «Спросите своего разработчика».

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

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

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

Когда я покинул Amazon в середине 2006 г., у меня не было никакого плана, кроме желания найти свою следующую идею. Чтобы сэкономить деньги, я съехал с набережной в центре города с прекрасным видом на залив Пьюджет-Саунд в маленькую квартиру в Юниверсити-Дистрикт — той части города, где проживают студенты Вашингтонского университета. Студенческая квартплата была гораздо более доступной для того, кто не получал твердой зарплаты. Опыт работы в Amazon показал мне, насколько легко стало создать софтверный стартап. Раз собственный дата-центр или серверы больше не нужны, то можно обойтись гораздо меньшими средствами и сконцентрироваться на самом важном — на клиенте и на решении его проблемы. В моей голове крутилась куча идей. Одна была связана с новым способом создания резервных копий, другая — с помощью людям трансляции видео из дальних уголков земного шара через одноранговую сеть. Мне предстояло решить, за что именно взяться, а для этого нужно было пообщаться с потенциальными клиентами.

Когда вы предлагаете потенциальным клиентам идею нового продукта, происходит одно из двух, особенно если эти клиенты ваши знакомые. Если им действительно нравится идея и кажется, что она решает некую проблему в их жизни, то они задают вопросы вроде такого: «Позволяет ли ваша идея делать то-то или то-то?» Они пытаются применить ваше решение к своей проблеме, и это хороший знак. Если они не видят в вашей идее решения какой-то важной проблемы, то разговор идет по-другому. Собеседники просто стараются быть вежливыми и говорят: «О, это звучит прекрасно…» — и замолкают. После нескольких секунд неловкого молчания они меняют тему: «Ну, что вы там говорили насчет “Детройтских тигров”?» И это не очень хороший знак.

Многие мои презентации заканчивались разговорами о «Детройтских тиграх», но я потратил на них всего несколько недель и ноль долларов, так что все было в порядке.

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

Я понял вот что: в каждой из трех моих предыдущих компаний мы использовали мощь программного обеспечения для создания великолепных продуктов и отличного обслуживания клиентов. Хотя характер бизнеса был очень разным — распространение конспектов лекций, вторичный рынок спортивных и концертных билетов, традиционный магазин инвентаря для экстремальных видов спорта, — везде требовалось создание ПО для обслуживания клиентов. Мощь ПО я видел в той быстроте, с которой можно было взять идею и донести ее до клиентов. Когда клиенты получали возможность опробовать эту идею, от них поступали отзывы о том, что хорошо, а что плохо. Это создавало почву для реализации следующей идеи и т.д. При желании можно было выпускать новую версию продукта хоть каждый день. Именно итеративный процесс делает программное обеспечение таким эффективным. Это благодаря ему мы запустили StubHub за шесть недель и я мог улучшать систему обслуживания кассовых терминалов в магазине Nine Star в режиме реального времени.

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

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

Каждый раз, когда возникали подобные проблемы, я обращался к компаниям, которые знали, как работает связь, таким как Cisco и AT&T. Если я удостаивался ответного звонка из их отдела продаж (мы были для них мелюзгой), то мне говорили, что все сделают, но для этого нам нужно протянуть медные провода от их канала связи до нашего дата-центра, затем установить специальное оборудование и купить массу программ. Но эта технология не делала того, что мы хотели от нее, сразу после покупки. Нужно было нанять еще кучу профессионалов в области телекоммуникаций, чтобы они все наладили и организовали. В общем, это удовольствие обходилось в миллионы долларов и занимало два года. А в итоге вы получали не то, что нужно.

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

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

Я разговаривал с потенциальными клиентами — разработчиками программного обеспечения. Я спрашивал: «Если бы у вас был API, который позволял бы инициировать или принимать телефонные звонки из вашего приложения и делать такие вещи, как воспроизведение аудио, чтение текста или осуществление конференц-связи, вы бы нашли ему применение?»

Сначала они говорили: «О, это интересно… Что насчет “Детройтских тигров”?» Но потом, примерно через минуту, до них доходило: «Погоди, та идея насчет телефона, а мог бы я… уведомлять людей об отправке их посылки?» И я с энтузиазмом отвечал: «Да! Да, можно!»

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

В конце 2007 г. я связался с моим первым сотрудником в Versity, а затем и в StubHub Джоном Уолтуисом, чтобы узнать, чем он занимается и интересна ли ему моя идея. Затем я созвонился с Эваном Куком, одним из моих преподавателей в Мичиганском университете, с которым я поддерживал связь и время от времени обсуждал бизнес-идеи. Все были в восторге, и общение с клиентами подтверждало, что интерес есть и у них, поэтому в январе 2008 г. мы сфокусировались исключительно на этой идее.

Для начала нам нужно было придумать название компании. Я — твердый сторонник уникальных названий, которые ни с чем не спутаешь. Мы начали вслух подбирать что-то созвучное слову telephone: Teliph, Teliphoo, Tilapia. Нет, ничего не звучит, а последнее вообще название рыбы. Мы продолжили свое упражнение. Наверное, это выглядело забавно со стороны, но нам было все равно. Минут через 20 я выдал: «Twili, Tweli, Twilio». Последнее вроде бы перекликалось со словом telephone. Удивительно, но домен был доступен всего за $7, и я купил его. Вот и все. Мы выбрали название для своей компании.

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

Сначала мы просто выясняли основы функционирования телекоммуникационной системы, а затем писали первую версию Twilio. Наше ПО обобщало сложность, накопленную в индустрии за столетие, и представляло ее в виде простого API для разработчиков. Такой интерфейс позволяет веб-разработчикам делать то, что им нужно в телекоммуникационной системе, без необходимости изучения языка, на котором говорит телекоммуникационная отрасль. Они просто пишут код на обычных языках вроде Ruby, Python, JavaScript или Java и используют его для создания приложений, способных совершать и принимать телефонные звонки.

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

Тем не менее на венчурных инвесторов наш прототип впечатления не произвел. Нам отказывали раз 20. Денег не хватало настолько, что в 2008 г., когда мы с Эрикой поженились, нам пришлось продать свадебные подарки и отнести деньги в банк. Инвесторы могли и не верить в Twilio, но я верил и мои соучредители тоже. Мы не собирались сдаваться. Мы не сомневались, что наш продукт понравится клиентам.

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

Истоки методологии «Спросите своего разработчика»

Оглядываясь назад, я понимаю, что это мой собственный опыт и люди, с которыми я работал, помогли мне увидеть взаимосвязь между бизнесом и программным обеспечением, между бизнесменами и разработчиками. Во-первых, создав четыре стартапа, я узнал, что разработка программного обеспечения в целом не такое уж сложное дело, а вот создать правильную программу трудно. Таким образом, быстрые итерации, эксперименты и тесный контакт с клиентами являются обязательным условием инноваций. Во-вторых, насмотревшись на крупные компании вроде Amazon, а также крошечные стартапы вроде StubHub, я понял, что ключевым аспектом создания инноваций является корпоративная культура и что эта культура идет сверху. И в-третьих, мне стало ясно, что отношения между разработчиками и бизнесменами, хотя это и не очевидно, имеют решающее значение для решения бизнес-проблем с помощью технологий. Этот последний пункт — самый важный вывод из данной главы.

Впервые я осознал значимость отношений между бизнесменом и разработчиком еще в 2004 г. в Nine Star, магазине товаров для экстремальных видов спорта в Лос-Анджелесе, открытым мной вместе с бывшим коллегой по компаниям Versity и StubHub Мэттом Левенсоном. В Versity Мэтт руководил нашей деятельностью в кампусах. Он отвечал за организацию работы в десятках, а затем и в сотнях кампусов. Он нанимал менеджеров, которые подбирали тех, кто пишет конспекты, и формировали маркетинговые команды. На пике деятельности Versity у нас работало порядка 15 000 студентов колледжей, с которыми, как известно, трудно поддерживать отношения и состав которых почти полностью обновлялся каждый семестр. Управлять деятельностью в таком масштабе можно было только с помощью ПО. Но Мэтт был абсолютным технофобом. Когда он пришел в Versity, я выдал ему ноутбук и определил адрес электронной почты, но он сказал, что ему это не нужно.

— Мэтт, ты будешь управлять тысячами людей на всей территории Соединенных Штатов. Как ты собираешься делать это без электронной почты?

— Я просто буду звонить им, — ответил он.

Как мог парень, отказавшийся пользоваться ноутбуком и электронной почтой, работать в высокотехнологичной компании? Однако Мэтт работал, в этом ему помогал наш уникальный способ сотрудничества, который я позднее стал называть методологией «Спроси своего разработчика».

Время от времени Мэтт обращался ко мне с какой-нибудь проблемой по работе, которую ему нужно было решить. В Versity он пытался превратить менеджеров кампуса — как правило, аспирантов, желавших подработать, — в отличных руководителей. Это было сложно уже потому, что конспекты писали 10 000 студентов, а число самих конспектов доходило до сотни тысяч в каждом семестре. Все начиналось с того, что нужно было выяснить, кто из студентов делает работу хорошо, а кто — нет. Я тогда был директором по технологиям, поэтому однажды Мэтт пришел ко мне и спросил: «Как нам выяснить, какие конспекты наши пользователи считают хорошими?» Чтобы решить этот простой вопрос, мы выработали рейтинговую систему, похожую на ту, что eBay использует для оценки покупателей и продавцов. (Сегодня рейтинги в интернете обычное дело, но тогда это была довольно новая концепция.) Через несколько дней мы сделали приложение для каждого комплекта конспектов, позволяющее пользователям оценивать конспекты по пятибалльной шкале. Это приложение хранило оценки пользователей в базе данных и создавало отчет в режиме реального времени о том, какие конспекты были замечательными, а какие — паршивыми.

Затем Мэтт спросил: «Раз мы знаем рейтинг каждого комплекта конспектов, можем ли мы ежедневно рекомендовать менеджерам кампусов, что делать с точки зрения управления студентами, которые пишут конспекты?» Мы взяли рейтинг конспектов и некоторые другие параметры и создали ежедневный отчет с ключевыми показателями работы порядка 50 студентов и «рекомендуемым действием», которое варьировало от «Ничего не делать» до «Отправить благодарность по электронной почте», «Отправить отзыв по электронной почте» и «Уволить». Рекомендуемое действие выбиралось автоматически, и после того, как менеджер кампуса просмотрел и одобрил его, система сама выполняла нужное действие. За исключением, конечно, увольнения — для этого система создавала список тех, кому нужно позвонить и лично сообщить плохие новости. (Мы не были чудовищами!) У нас в системе даже имелось около десятка шаблонов писем, поэтому студенты никогда не получали одну и ту же похвалу или отзыв дважды. Мы называли это приложение «Робоменеджер», и оно позволяло нашим менеджерам кампуса управлять своей командой, тратя на это не больше пяти минут в день.

Такой способ управления использовался и в Nine Star. Однажды Мэтт спросил: «Знаешь что? Мне хотелось бы стимулировать продавцов в зависимости от количества посетителей, которых им удалось превратить в покупателей. Можно ли как-то подсчитать, сколько человек проходит через дверь, используя инфракрасные счетчики? А потом могли бы мы соотнести это с объемом продаж на кассовых терминалах и выяснить, каков наш коэффициент превращения посетителей в покупателей?»

«Думаю, можно, — сказал я. — Не знаю пока, как именно. Но это действительно интересно. Дай мне подумать».

Итак, я отправился изучать системы подсчета людей — те штуковины с датчиком освещенности на двери магазина. Я обнаружил, что у этих систем есть API. Это означало, что можно написать приложение, которое будет взаимодействовать с датчиками и получать от них данные. Я написал еще одну программу, которая получала данные от системы обслуживания кассовых терминалов, а затем соединил обе программы. Вуаля! Мы получили примитивную систему расчета коэффициента конверсии в нашем магазине. Затем я написал программу, которая сделала данные о коэффициенте конверсии посетителей доступными для наших сотрудников во внутренней компьютерной сети магазина. Теперь у нас был новый показатель, который мы могли использовать для измерения результатов торговли.

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

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

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

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

Отправить