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

Что происходит, когда вы позволяете разработчикам быть творческими людьми? Эштон Катчер и Деми Мур создали некоммерческую организацию Thorn, работающую на основе высоких технологий.

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

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

Эштон понимает, как работают инженеры и как их мотивировать, лучше большинства венчурных капиталистов (и, безусловно, большинства актеров – собратьев Эштона по первой профессии!). Именно поэтому венчурный фонд A-Grade Investments, созданный им в 2010 г., вырос, по данным Forbes, с $30 млн до $250 млн, обеспечив Катчеру репутацию выдающегося венчурного инвестора. Он инвестировал в такие успешные компании, как Warby Parker, Spotify, Skype и Airbnb. Одной из его лучших инвестиций было вложение $500 000 в Uber в 2011 г.

Все это неудивительно, учитывая, что Катчер в свое время изучал биохимическую инженерию в Айовском университете. «Когда я учился на техническом факультете, – рассказывал он мне, – один из профессоров часто говорил: “Ученые находят проблемы, а инженеры решают проблемы”. Именно так я всегда смотрел на разработчиков. Они решают проблемы. Они садятся и рассматривают проблему, а затем находят наиболее эффективный способ ее решения».

Сначала Thorn обратилась за помощью к другим высокотехнологичным компаниям в районе Залива. «Нам было известно, чего мы не знали, – говорит Катчер. – Мы не всегда знали, как решить проблемы. Но мы пошли к группе талантливых разработчиков и сказали: “Послушайте, это преступление [сексуальная эксплуатация несовершеннолетних] переместилось в интернет. Нам нужно выяснить, как превратить этот криминальный интернет-бизнес в плохой. Для этой работы требуются механизмы. Но нам нужны идеи – какие именно механизмы необходимо создать”».

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

Такая идея была вынужденной – как и большинство некоммерческих организаций, Thorn располагала ограниченными средствами. Хакерские марафоны стали частью исследований и разработок в Thorn. «Мы просто описываем четыре или пять проблем и говорим: “Попробуйте решить проблему”», – утверждает Катчер. Thorn продолжает использовать хакерские марафоны для расширения своей работы и даже создала собственную специализированную команду инженеров и программистов, занимающуюся разработкой механизмов для прекращения сексуального насилия над детьми в интернете.

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

Задумайтесь над этим. Вы когда-нибудь добровольно делали свою повседневную работу в выходные бесплатно, просто из энтузиазма? Вы знаете бухгалтеров, которые занимаются ведением счетов как хобби по выходным? Некоторые, возможно, это делают, но, думается, немногие. Занимаются ли стоматологи своими профессиональными творческими идеями между делом? (Боже, надеюсь, что нет!) Для разработчиков код – это больше чем работа, это творчество. Когда разработчики не могут реализовать свое творческое начало на работе, они находят для самовыражения другие места. У многих из них имеются сторонние проекты и даже стартапы.

Техническое образование Катчера позволяет ему доверять разработчикам и понимать, что они прекрасно справятся с решением бизнес-задач. Но что, если вы не инженер? Что ж, этот подход также работает, даже если вы – президент Соединенных Штатов.

В 2014 г. Эвану Куку, моему другу и соучредителю Twilio, после его ухода из компании позвонил Тодд Парк, покидающий пост директора по технологиям США. Тодд спросил Эвана, могут ли они встретиться, но никаких подробностей не сообщил. Эвана заинтриговал почтовый адрес Тодда на домене whitehouse.gov, и он представил через архаичную и небезопасную электронную почту свою личную информацию для проверки анкетных данных. В назначенный день он появился в отеле Fairmont в Сан-Франциско, одетый в светло-коричневые джинсы и дешевый блейзер, самые близкие к настоящему костюму предметы в его гардеробе.

Его и еще нескольких человек (как он узнал позже, это были специалисты высшего уровня из компаний Amazon, Apple и Facebook) провели в пентхаус с потрясающим видом на залив Сан-Франциско. Их встретили Тодд и Меган Смит, бывшая вице-президент Google, которая только что сменила Тодда на посту директора по технологиям США. Тодд и Меган объяснили, что они создают новую организацию – Цифровую службу США. Им требовалась небольшая команда лучших специалистов из Кремниевой долины, которая могла бы из Вашингтона руководить перестройкой важнейших секторов цифровой инфраструктуры правительства.

Затем в лучах заходящего солнца над мостом Бэй-бридж они увидели, как президентский вертолет Корпуса морской пехоты и конвертоплан V22 Osprey приблизились к городу и приземлились на аэродроме Крисси-Филд.

На дворе стоял февраль 2015-го, и последние полтора года были для Белого дома мучительными. В конце 2013 г. правительство представило с большой помпой сайт HealthCare.gov, но он сразу же рухнул. Это был огромный удар по репутации правительства и в особенности президента Барака Обамы, который сделал реформу здравоохранения главным вопросом своего президентства. Тодд и его коллеги привлекли нескольких инженеров из Кремниевой долины для восстановления сайта и сумели стабилизировать его функционирование.

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

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

Вот почему Эвана и остальных пригласили на эту встречу.

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

Поэтому Меган выбрала другой подход. Она подошла к окну и показала через залив на Ричмондские верфи. Именно там, сказала она, Соединенные Штаты во время Второй мировой войны строили грузовые суда класса Victory – чудо техники, способное двигаться быстрее немецких подводных лодок. Она сказала, что Эван и другие участники встречи похожи на инженеров, которые спроектировали эти корабли Victory и позволили стране одержать победу во Второй мировой войне.

Затем дверь в зал открылась, в нее вошел президент Обама и сказал просто и эффектно: «Ваша страна нуждается в вас». Затем он обошел всех присутствующих и обратился лично к каждому: «Объясните, почему вы не можете переехать в Вашингтон и послужить своей стране? Что-то не так с вашей работой? Хотите, я позвоню кому надо? Я могу позвонить кому угодно». Никто из пятерых не попросил Обаму позвонить. Никто не стал искать причину, чтобы отказаться от работы. Затем они сделали групповое фото, и Обама исчез за дверью вместе со своей свитой.

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

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

Организация Эштона Катчера Thorn обратилась к разработчикам за помощью из-за того, что у нее не было другого выхода, Обама – потому что оказался в кризисной ситуации. Но эффективные компании превращают методологию «Спросите своего разработчика» в повседневную практику, открывая разработчикам простор для творчества. Отличный пример реализации этого подхода – Basecamp, небольшая, но процветающая софтверная компания из Чикаго, в которой работают около 60 сотрудников.

Джейсон Фрайд и его соучредитель Дэвид Хайнемайер Хенссон управляют Basecamp почти как лабораторией, занимающейся изучением таких способов работы, которые делают сотрудников счастливыми и позволяют выполнять работу наилучшим образом. Дэвид, который подписывается как DHH, – разработчик, получивший известность после создания широко используемого фреймворка для веб-программирования Ruby on Rails. Помимо прочего, он и Джейсон много пишут об организации работы. Вместе они опубликовали две книги о разработке ПО и три книги о современном рабочем месте под названием «Remote: офис не обязателен»[2]2
  Фрайд Д., Хенссон Д. Х. Remote: Офис не обязателен. – М.: Манн, Иванов и Фербер, 2021.


[Закрыть], «Rework: бизнес без предрассудков»[3]3
  Фрайд Д., Хенссон Д. Х. Rework: Бизнес без предрассудков. – М.: Манн, Иванов и Фербер, 2010.


[Закрыть] и «Не сходите с ума на работе»[4]4
  Фрайд Д., Хенссон Д. Х. Не сходите с ума на работе, или Как создать спокойную компанию. – М.: Манн, Иванов и Фербер, 2019.


[Закрыть]. Они любят делиться своими идеями и даже предлагают однодневные семинары, где учат тому, как принять неортодоксальный подход Basecamp к управлению компанией.

Фрайд говорит, что их метод – делиться проблемами. «Мы просто говорим своей команде: “Вот идея, вот примерно то, куда мы хотим пойти или что хотим создать. Ваша задача в том, чтобы взяться за этот вопрос и разобраться в нем”. Здесь хватает места для самостоятельности и автономии. Люди сами решают, как справиться с проблемой. Мы можем вносить свой вклад, но проект принадлежит им. А можно было бы самим влезть в детали, установить, что в решении задачи должно иметься 42 шага, а затем выдать 42 задания и сказать: “Не ломайте головы, просто делайте то, что вам говорят”». Они объясняют, откуда взялась идея, и могут примерно обрисовать своей команде свой замысел, буквально на лекционной доске, но это все.

Так политика Фрайда выглядит с тех пор, как он в 1999 г. стал соучредителем компании, первоначально называвшейся 37signals. «Я никогда не считал, что нужно просто класть работу людям на тарелочку, – говорит он. – Вы должны позволить им творить самостоятельно. Именно для этого вы их и нанимаете. Если вы влезаете в каждую мелочь, то в конечном итоге у вас остаются те, у кого нет головы. А они разве могут сделать что-то на отлично? Я предпочитаю нанять способных людей и позволить им самим решать проблемы».

Фрайд и DHH никогда не публиковали данных о размерах бизнеса Basecamp, но у них около полумиллиона подписчиков в Twitter, они написали книгу о том, как мало делают своими руками, а DHH известен своей коллекцией гоночных автомобилей – полагаю, бизнес идет у них неплохо. Если они доверяют разработчикам самые важные проблемы, то я уверен, это получится и у вас. У меня, например, получилось.

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

После запуска Twilio нашими первыми продуктами стали Twilio Voice и Twilio Phone Numbers. Разработчикам нужно было заставить систему передавать разговор – отсюда наш голосовой продукт, а также им требовались телефонные номера для установления связи – поэтому у нас есть API для покупки телефонных номеров, первоначально по почтовым индексам в США, а затем и в сотне стран по всему миру. Конечно, некоторые клиенты хотели использовать уже имеющийся номер телефона, поэтому мы разрешили им переходить со своим номером на Twilio. Возможно, вам уже приходилось переносить свой номер телефона при смене оператора мобильной связи.

Честно говоря, переход со своим телефонным номером к другому оператору в США та еще морока. Эта процедура была поспешно введена в действие операторами связи в 1997 г. в ответ на закон о телекоммуникациях 1996 г. и с тех пор не претерпела значительных улучшений. В целом это процесс, выполняемый персоналом оператора связи вручную. И поскольку оператор теряет деньги с уходом номера, у него есть прямой интерес создавать сложности и тянуть время.

Поначалу работа по переносу клиентских телефонных номеров легла на плечи нашего первого наемного сотрудника Лизы Уайтекамп. Лиза была мастером на все руки. Я перетянул ее из валютного департамента Wells Fargo, где она координировала торговлю. Какую бы проблему я ей ни подкидывал, она моментально разбиралась в ней. А в период становления компании таких проблем масса. У нас одной из них был перенос телефонных номеров.

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

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

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

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

Стало очевидно, что работа по переносу номеров должна быть не ручной, а максимально автоматизированной. И это нужно было сделать еще вчера.

Поскольку Лиза была знакома с процессом переноса номеров, лучше нее никто не знал, как его автоматизировать. Крис Коркоран был новым инженером в команде, но уже проявил способность находить сквозные решения проблем. Хотя он совсем недавно получил степень по информатике в Массачусетском университете, ему уже удалось пройти стажировку в NASA и поработать в Google. Ему дали прозвище Озон из-за инициалов CFC, совпадающих с химическим обозначением фреона – разрушителя озонового слоя Земли.

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

В первый момент они оторопели, но потом принялись за работу. Лиза продемонстрировала Озону несколько операций по переносу номеров, проработав все детали вместе с ним. Затем она передала ему клавиатуру и заставила выполнить с десяток таких операций – мы называем это «прогулка в обуви клиента». После того, как Озон прочувствовал проблему, она спросила его: «Ну вот, можно создать программу, которая будет делать это?»

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

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

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

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