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

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

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

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

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

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

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

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

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

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

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

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

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

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