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

Создать и купить

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

«Высокотехнологичные компании постоянно обсуждают, какие микросервисы создавать, а какие покупать, – говорит Эштон Катчер, инвестировавший в десятки стартапов и записавший на свой счет несколько крупных коммерческих побед, в первую очередь сервисы Airbnb, Spotify и Uber. – Полагаю, что та часть ПО, которую вы не создаете, так же важна, как и часть, создаваемая самостоятельно. Единственное, что компании должны неизменно создавать сами, так это ключевые элементы их бизнеса. Люди очень часто занимаются созданием того, что уже существует в виде продукта, который можно сравнительно дешево купить или использовать по лицензии. Нужно ли создать собственную систему учета трудозатрат и начисления заработной платы? Я бы никогда не попытался перестраивать компании Twilio, Slack или Gusto».

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

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

Дифференциацию невозможно купить. Ее можно лишь создать самостоятельно.

Но есть и хорошие новости: создавать ПО стало намного проще. Когда-то, до появления зрелой цепочки поставок ПО, выходом обычно была покупка готовых решений, поскольку решиться на создание собственных было слишком сложно. Чтобы создавать ПО, компании нужно было подняться до уровня Microsoft или Oracle. Но теперь, благодаря третьей великой эре программного обеспечения и цифровой цепочке поставок, создание ПО не просто возможно, а необходимо. Эту необходимость диктует конкурентная динамика.

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

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

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

Теоретически в один прекрасный день софтверная компания сможет создать приложение, вообще не написав собственного кода, а просто скомпоновав микросервисы, созданные другими компаниями. Фактически это идея компании, которая оценивается на рынке в $1 млрд или больше, но управляется одним человеком – разработчиком, чье приложение выстроено на основе коммерческих микросервисов. Такого пока не произошло, но это лишь вопрос времени. Процесс, который мы называем «написание ПО», может стать в значительной степени процессом объединения фрагментов кода – точно так же, как Dell собирает из готовых компонентов персональный компьютер или шеф-повар делает особенное блюдо из готовых ингредиентов. В действительности написание программы может вскоре оказаться таким легким делом, которое под силу любому человеку без специальной подготовки в области компьютерных наук.

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

Точно так же, как и Apple, разработчики теперь сочетают собственное ПО с готовыми микросервисами, предоставляемыми другими. Хороший пример – Uber. То, что вы называете «приложение Uber», на самом деле представляет собой набор примерно из 4000 микросервисов, некоторые из которых разработаны инженерами Uber, а многие предоставляются внешними операторами облачных платформ. Когда пассажир звонит водителю, его команда мгновенно перемещается с главного экрана Uber на наши серверы Twilio, и мы направляем вызов водителю. Но это все невидимо ни для пассажира, ни для водителя – они лишь знают, что Uber позволяет им связаться друг с другом. Платежи обрабатываются другим микросервисом, в то время как конвертация валют осуществляется микросервисом Tincup, который Uber разработала самостоятельно.

Именно так все новые компании в Кремниевой долине создают свое ПО, быстро превращающееся в стандарт для традиционных компаний, таких как банки, розничные продавцы и авиакомпании.

Спросите своих разработчиков, какие сервисы вам нужно покупать

Некоторые компании считают, что такие услуги, как вычисления, хранение данных, платежи или связь, являются основными и не могут передаваться на аутсорсинг. Например, я знаю розничные компании, которые на заре существования облака отказались использовать платформу AWS, поскольку розничный бизнес Amazon был их конкурентом. Однако компании с таким отношением к делу уходят на второй план. Именно когда конкуренция становится более жесткой, компании должны сосредоточиться на том, что дифференцирует бизнес. Покупка готовых решений даже у самого опасного конкурента – как раз то, что позволяет получить шанс на победу. Вот почему вы смотрите фильмы и видеопрограммы на сервисе Netflix, который конкурирует с Amazon Prime Video, – а ведь Netflix является крупным и публичным клиентом платформы AWS. Вот почему в Twilio мы видим, как крупные операторы используют наши сервисы для контакт-центров, рассылки уведомлений клиентам и многого другого. Часто решения не использовать облачные сервисы принимаются на самом верху из-за… ошибочной стратегии компании. Я полагаю, что это неразумно.

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

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

Джо пришел на нашу ежегодную конференцию клиентов в 2012 г., тогда называвшуюся TwilioCON, с целью выяснить, что Twilio вообще делает и как он нас уничтожит. Там он познакомился с сотнями других наших пользователей и получил представление о том, сколько компаний используют Twilio для создания инноваций в сфере обслуживания клиентов. Здравый смысл у Джо возобладал, и на обратном пути он написал меморандум, в резюме которого говорилось: «Мы не отказываемся от Twilio, мы перемещаем всю свою деятельность в облачные сервисы Twilio». И в последние годы RealPage поступает именно так.

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

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

Часть II
Как понять и мотивировать своих разработчиков

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

Глава 3
Привет! Я – Джефф, и я – разработчик

Каждые две недели мы собираем группу новых сотрудников 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, заставшего мир врасплох, и я оказался одним из миллионов, впервые открывших для себя интернет в эти месяцы.

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

Но еще более интересными оказались «динамические» сайты, которые только начали появляться в то время – они не просто отображали контент. Amazon.com позволял просматривать книги и даже покупать их! Сайты 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 г. было бы очень трудно сделать в интернете, а просто устроить их бесплатную раздачу. Рекламный рынок был намного больше рынка конспектов лекций, поэтому мы могли бы получать выгоду от размещения рекламы местных и национальных компаний на конспектах.

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

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

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

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

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

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

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