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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 4
Код – это творчество

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

АНТУАН ДЕ СЕНТ-ЭКЗЮПЕРИ

Если вы – руководитель, то наверняка вам приходится проводить много времени со своей командой по продажам и у вас есть хорошее представление о том, как менеджеры по продажам делают свою работу и что их мотивирует. Вы видите, что менеджеры по продажам любят одерживать победу и что ваш подход к структурированию процесса продаж и вознаграждениям создает условия для соперничества. Успешных менеджеров по продажам превозносят как героев, и руководители знают их по именам. Однако я обнаружил, что очень редкие руководители хорошо понимают, что заряжает разработчиков. Как и большинство людей, разработчики любят побеждать, но их работа имеет свой характер. Если вас интересует, почему так трудно найти и удержать отличных разработчиков – таких, как в компаниях Facebook, Amazon и Google, – то попробуйте для начала понять, что их мотивирует. Если вам интересно, почему «простые» изменения на вашем сайте или в мобильном приложении отнимают так много времени, то попробуйте вникнуть в процесс взаимодействия разработчиков и менеджеров. Если вы создадите среду, которая позволит разработчикам удовлетворить свой профессиональный зуд, они поразят вас результатами. Но для начала все же необходимо понять, что мотивирует разработчиков – вопреки распространенному мнению, их мотивация больше связана с творчеством, чем с математикой. Дело в том, что код – это творчество.

Если вы хотели записать песню 30 лет назад, то вам нужно было «заявить о себе» – стать вхожим в студию звукозаписи, чтобы вам выделили дорогое студийное время, сделали CD и выпустили в радиоэфир. В год это удавалось сделать лишь небольшой кучке вокальных групп, и шансы на музыкальный успех были у вас невелики, несмотря на все таланты. Большинству претендентов не оставалось ничего другого, кроме занятия своей обыденной работой. То же самое происходило и в киноиндустрии. Честолюбивые кинематографисты переезжали в Голливуд и годами работали официантами в поисках своего звездного часа. Голливуд выпускал всего около сотни полнометражных фильмов в год, и конкуренция за участие в их создании была жесткой. Система не раз отвергала даже очень талантливых кинематографистов, в большинстве своем они возвращались домой, а их мечты «покорить Голливуд» так и оставались мечтами.

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

За $299 любой начинающий кинорежиссер может купить Final Cut Pro – то же самое программное обеспечение, которое используется при монтаже голливудских фильмов, – и получить доступ к миллиарду зрителей через YouTube. За $199 музыканты могут купить ту же самую программу Logic Pro X, что использует Бейонсе для записи своих альбомов, и бесплатно распространять свою музыку на платформе SoundCloud.

И это происходит сплошь и рядом. Монтеро Ламар Хилл, он же Lil Nas X, молодой человек в возрасте 19 лет, купил музыкальный трек в интернете за $30, наложил на него текст и в декабре 2018 г. разместил песню “Old Town Road” на платформе SoundCloud. Она стала сверхуспешной и была воспроизведена онлайн более миллиарда раз. Она также установила новый рекорд по числу недель на вершине хит-парада еженедельника Billboard и в 2019 г. была признана песней года на церемонии вручения наград музыкального телеканала MTV. В числе других примеров – комик Джо Роган, запустивший бесплатный подкаст в 2009 г. и год спустя подписавший контракт на $100 млн со Spotify, а также восьмилетний Райан Каджи, который зарабатывает, по данным Forbes, $26 млн в год на YouTube-канале Ryan ToysReview, где он, как вы уже догадались, обозревает игрушки.

То же происходит и с другой группой творческих людей – разработчиками. Софтверная инфраструктура была невероятно дорогой, а теперь она дешева или даже бесплатна для начинающих. Не нужно больше покупать огромные серверы или арендовать ресурсы в дата-центре. Существует целый набор инструментов, которые можно взять в готовом виде и использовать в своих приложениях: сервисы Amazon или Microsoft – для обработки и хранения информации, Google – для работы с географическими картами, Twilio – для связи, Stripe – для осуществления платежей. У любого подростка есть доступ к тем же основным строительным блокам, что и у крупнейших компаний мира.

То же касается и распространения. Разработчикам больше не нужно заключать сделку с издателем ПО, получать место на полке в магазине CompUSA или добиваться предустановки приложения на мобильном телефоне. Любой может разместить разработанное приложение в сервисе, подобном App Store, точно так же, как любой может разместить свое видео на YouTube. Веб-разработчик может купить рекламу в Google с помощью своей кредитной карты всего за несколько центов за клик.

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

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

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

Сервис Instagram был создан двумя инженерами и продан Facebook за $1 млрд, когда в компании было всего 13 сотрудников. У двух создателей приложения WhatsApp в штате было всего полсотни работников, когда они продавали свою компанию Facebook за $19 млрд. Несколько лет назад два разработчика отправились на хакерский марафон в Нью-Йорк с идеей создать приложение для групповых сообщений. Используя Twilio, они написали первую версию за один 18-часовой спринт. Они назвали это приложение GroupMe и через 15 месяцев продали его Microsoft за $80 млн.

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

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

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

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

Случайные наблюдатели часто упускают из виду то, что важнее всего: разработчики наделены полномочиями и свободой. Не просто свободой распоряжаться рабочим временем или определять форму одежды, а свободой творчества.

Когда вы представляете себе разработчиков, то вместо Уркела, Шелдона или Денниса Недри думайте о Патрике Маккензи, Райане Лесли, Лие Калвер и Чаде Этцеле.

Патрик Маккензи работает в компании Stripe и более известен в интернете как Patio11 – под этим ником он выступает на самом популярном сайте для разработчиков Hacker News, где обсуждаются вопросы, связанные с профессией. Там он давно считается одним из самых высокорейтинговых комментаторов, и не зря. Для своего сайта Kalzumeus.com Патрик написал ряд самых проницательных и занимательных эссе о том, каково это – быть программистом. Он живет в Японии, где работал корпоративным программистом, а потом начал собственное дело, выпустив два простых онлайновых приложения – одно для создания карточек лото для учителей, а другое для напоминаний о встречах. Это обеспечило ему финансовую независимость. Патрик – классический эрудит. Он говорит по-испански и по-японски, может разобраться в сложностях налогового кодекса США, а однажды очень ярко описал четкую работу японских систем оповещения во время землетрясения 2011 г.: «Случившееся было – и я говорю это без малейшего преувеличения – одним из триумфов человечества. Каждый инженер в этой стране должен ощущать себя существом высшего порядка».

Райан Лесли – рэпер и продюсер, номинированный на музыкальную премию «Грэмми», предприниматель и, конечно, разработчик программного обеспечения. В 14 лет на академическом оценочном тесте он набрал 1600 баллов. Он рано оставил школу, поступил в Гарвард, где изучал политологию и макроэкономику, и окончил его в 19-летнем возрасте. Попутно он освоил сферу музыкального продюсирования, а после окончания университета заключил контракт со звукозаписывающей компанией Universal Motown. Его альбом 2009 г. “Transition” достиг четвертой строчки в американских хит-парадах R&B. Но когда он попросил у лейбла список своего фэн-клуба, там только пожали плечами – они просто не знали о нем. Что это за компания, у которой нет никаких связей с клиентами? Ее точно нет среди тех, кто может выжить в цифровой экономике. Это был бизнес, который созрел для цифровой революции, и Райан решил, что именно он должен осуществить эту революцию. Он научился программировать и создал SuperPhone – продукт, позволяющий людям искусства напрямую взаимодействовать со своей аудиторией.

Приложение SuperPhone позволяет Райану публиковать свой номер телефона на концертах, на своем сайте и в социальных сетях – и, когда люди звонят или пишут на этот номер, он добавляет их к миллионам своих поклонников. SuperPhone – это приложение для управления взаимоотношениями с клиентами на основе текстовых сообщений. Когда Райан выпускает новый сингл или объявляет о новых концертах, он может напрямую написать об этом поклонникам. Это ПО помогло ему заработать миллионы долларов на альбомах и сувенирной продукции! Более того, SuperPhone превратилось в самостоятельный бизнес с финансированием от некоторых из лучших венчурных капиталистов Кремниевой долины и штатом из 12 человек. У SuperPhone около 2000 клиентов, начиная от артистов вроде Майли Сайрус и 50 Cent и заканчивая крупными розничными продавцами электроники и брендами люксовых часов, – все они используют SuperPhone для построения близких отношений с клиентами. Райан не просто рэпер – он также разработчик, венчурный предприниматель и программист, который использует ПО для решения проблем. «Это был большой риск, – говорит он. – Работа с ПО изменила мою жизнь. Мы действительно верим в возможности, которые открывает ПО».

В 2006 г. Лия Калвер получила степень по информатике в Миннесотском университете и переехала в Кремниевую долину. На сегодняшний день она создала сама или совместно с другими учредителями три компании. Первые две были приобретены у нее, и теперь она управляет компанией Breaker с семью сотрудниками, которая продает программы для подкастов. Помимо стартапов, Лия была разработчиком в компаниях Medium и Dropbox. По ее словам, как предприниматель она реализует свой потенциал в полной мере. Она постоянно учится разрабатывать продукты, управлять сотрудниками и вести бизнес. «Что мне нравится в стартапах, так это сложность их развития. Многие специальности в сфере ПО слишком просты. Я не чувствую в них вызова. Причина, по которой люди становятся инженерами, заключается в том, что это сложная и приносящая удовлетворение профессия. Плюс мне нравится каждый день делать что-то новое. Это увлекательно – взяться за то, чего не знаешь, затем изучить это и наконец овладеть». Идея непрерывного обучения и расширения горизонтов – как раз то, что я постоянно слышу от выдающихся разработчиков.

Чад Этцель – один из самых креативных разработчиков, которых я встречал в своей жизни. Он умеет слушать клиентов и превращать то, что услышано, в интересные программы. Чад работал последние пять лет инженером по iOS в компании Apple – первое место, где он чувствовал себя как дома после того, как попробовал работать в нескольких компаниях (включая Twilio) в первые девять лет после окончания университета. У него – усы и бородка как у человека искусства, он часто носит щегольскую кепку и отзывается на кличку Джаззи Чад, которая была его ником в конференциях AOL во времена школьной юности. (Он играет на саксофоне достаточно хорошо, чтобы выступать в джаз-клубах Сан-Франциско, и иногда приносит инструмент с собой в офис.) Как и Патрик, Чад обладает отличным чувством юмора, твердым мнением и почти нулевой терпимостью к обману – корпоративному или какому угодно. Его любимое занятие – создание собственных компаний и работа на себя. «У меня была полная автономия, – объясняет он. – Создание чего-то на пустом месте – именно то, что дает мне максимальный запал и энергию. Когда мне указывают, как решить проблему, или говорят “Вот три вещи, которые тебе нужно сделать, и не беспокойся о задании в целом”, у меня пропадает всякий интерес». По словам Чада, он сменил столько мест работы потому, что до Apple ему было очень трудно «найти компанию, которая дает автономию или свободу, позволяющую полностью отдаться делу».

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

Весной 2020 г. компания Twilio опросила около тысячи разработчиков из разных уголков мира, с тем чтобы выяснить, как они сами и их менеджеры оценивают роль разработчиков в компании. Результаты очень показательны. Более 66 % разработчиков сообщили, что оценивают свои творческие способности «выше среднего», но лишь 50 % сказали, что такие способности нужны на их работе. Так как же разработчики используют избыток творческих способностей? Многие находят выход за пределами работы: 48 % сообщили о хобби, где дизайн занимает центральное место (архитектура, разработка мебели, интернет), а 32 % заявили о занятии в свободное время изящными искусствами (живопись, скульптура, керамика). Да, есть еще один разрушающий стереотипы результат опроса: разработчики являются спортсменами: 36 % из них бегуны, 33 % – велосипедисты, 28 % – баскетболисты и 25 % – любители пешего туризма!

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

«Делитесь с разработчиками проблемами, а не решениями».

А потом с изумлением наблюдайте, что произойдет: качество ПО улучшится, продолжительность цикла его создания резко сократится, пользователи будут довольнее, а ваши разработчики проработают в компании дольше. Я никогда не встречал бизнес-менеджера, который отказался бы от всего вышеперечисленного.