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

Именно тогда меня пригласил на обед Кевин О’Коннор, основатель и генеральный директор ведущей рекламной сети в интернете той эпохи, компании 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. Удивительно, но домен Twilio.com был доступен всего за $7, и я купил его. Вот и все. Мы выбрали название для своей компании.

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

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

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

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

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