Войти в систему
Войти с помощью соц. сетей:
Если ты хочешь построить корабль, не надо созывать людей, планировать, делить работу, доставать инструменты. Надо заразить людей стремлением к бесконечному морю. Тогда они сами построят корабль.
Если вы — руководитель, то наверняка вам приходится проводить много времени со своей командой по продажам и у вас есть хорошее представление о том, как менеджеры по продажам делают свою работу и что их мотивирует. Вы видите, что менеджеры по продажам любят одерживать победу и что ваш подход к структурированию процесса продаж и вознаграждениям создает условия для соперничества. Успешных менеджеров по продажам превозносят как героев, и руководители знают их по именам. Однако я обнаружил, что очень редкие руководители хорошо понимают, что заряжает разработчиков. Как и большинство людей, разработчики любят побеждать, но их работа имеет свой характер. Если вас интересует, почему так трудно найти и удержать отличных разработчиков — таких, как в компаниях 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, где обсуждаются вопросы, связанные с профессией. Там он давно считается одним из самых высокорейтинговых комментаторов, и не зря. Для своего сайта Патрик написал ряд самых проницательных и занимательных эссе о том, каково это — быть программистом. Он живет в Японии, где работал корпоративным программистом, а потом начал собственное дело, выпустив два простых онлайновых приложения — одно для создания карточек лото для учителей, а другое для напоминаний о встречах. Это обеспечило ему финансовую независимость. Патрик — классический эрудит. Он говорит по-испански и по-японски, может разобраться в сложностях налогового кодекса США, а однажды очень ярко описал четкую работу японских систем оповещения во время землетрясения 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% — любители пешего туризма!
У таких разработчиков «Требования к продукту» с подробным описанием того, что именно нужно создать, убивают львиную долю творческого потенциала. Вот почему мой главный совет руководителям, отправляющимся в поездку по Кремниевой долине, таков:
«Делитесь с разработчиками проблемами, а не решениями».
А потом с изумлением наблюдайте, что произойдет: качество ПО улучшится, продолжительность цикла его создания резко сократится, пользователи будут довольнее, а ваши разработчики проработают в компании дольше. Я никогда не встречал бизнес-менеджера, который отказался бы от всего вышеперечисленного.
Что происходит, когда вы позволяете разработчикам быть творческими людьми? Эштон Катчер и Деми Мур создали некоммерческую организацию 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, после его ухода из компании позвонил Тодд Парк, покидающий пост директора по технологиям США. Тодд спросил Эвана, могут ли они встретиться, но никаких подробностей не сообщил. Эвана заинтриговал почтовый адрес Тодда на домене , и он представил через архаичную и небезопасную электронную почту свою личную информацию для проверки анкетных данных. В назначенный день он появился в отеле Fairmont в Сан-Франциско, одетый в светло-коричневые джинсы и дешевый блейзер, самые близкие к настоящему костюму предметы в его гардеробе.
Его и еще нескольких человек (как он узнал позже, это были специалисты высшего уровня из компаний Amazon, Apple и Facebook) провели в пентхаус с потрясающим видом на залив Сан-Франциско. Их встретили Тодд и Меган Смит, бывшая вице-президент Google, которая только что сменила Тодда на посту директора по технологиям США. Тодд и Меган объяснили, что они создают новую организацию — Цифровую службу США. Им требовалась небольшая команда лучших специалистов из Кремниевой долины, которая могла бы из Вашингтона руководить перестройкой важнейших секторов цифровой инфраструктуры правительства.
Затем в лучах заходящего солнца над мостом Бэй-бридж они увидели, как президентский вертолет Корпуса морской пехоты и конвертоплан V22 Osprey приблизились к городу и приземлились на аэродроме Крисси-Филд.
На дворе стоял февраль 2015-го, и последние полтора года были для Белого дома мучительными. В конце 2013 г. правительство представило с большой помпой сайт , но он сразу же рухнул. Это был огромный удар по репутации правительства и в особенности президента Барака Обамы, который сделал реформу здравоохранения главным вопросом своего президентства. Тодд и его коллеги привлекли нескольких инженеров из Кремниевой долины для восстановления сайта и сумели стабилизировать его функционирование.
Но этот случай заставил всех осознать, насколько устарела техническая инфраструктура правительства для реализации ключевых приоритетов президентской администрации. Проблемы были повсюду — в Пентагоне, Администрации малого бизнеса, министерствах образования, здравоохранения и социальных служб, Администрации общих служб, Министерстве внутренней безопасности… Там существовали тысячи систем и миллиарды строк кода, мешанина из безумных программных решений, «заплаток» и временных решений, большая часть которых была настолько старой, что никто не помнил, откуда она взялась или кто ее создал.
Правительство столкнулось с той же проблемой, что и компании, — все возрастающая доля деятельности правительства зависела от программного обеспечения, а благодаря таким компаниям, как Spotify, Uber и Facebook, граждане уже имели представление о том, как должны выглядеть высокие стандарты обслуживания. Кроме того, существовали серьезные проблемы, связанные с неэффективностью и низким качеством, когда речь заходила о приобретении и внедрении нового ПО. Многомиллиардные контракты обычно доставались одним и тем же компаниям, которым требовались годы на выполнение проекта, хотя индустрия высоких технологий уже давно поняла, как быстро и недорого создавать высококачественное ПО. Новой игрушкой стал сайт, стоимость которого исчислялась миллиардами. Но по крайней мере он работал!
Вот почему Эвана и остальных пригласили на эту встречу.
Тодду и Меган нужно было завоевать расположение разработчиков, но у них не было нужных рычагов. Эти разработчики могли работать где угодно. Плюс их нельзя было мотивировать деньгами, поскольку финансовые предложения правительства не шли ни в какое сравнение с зарплатами в Кремниевой долине.
Поэтому Меган выбрала другой подход. Она подошла к окну и показала через залив на Ричмондские верфи. Именно там, сказала она, Соединенные Штаты во время Второй мировой войны строили грузовые суда класса Victory — чудо техники, способное двигаться быстрее немецких подводных лодок. Она сказала, что Эван и другие участники встречи похожи на инженеров, которые спроектировали эти корабли Victory и позволили стране одержать победу во Второй мировой войне.
Затем дверь в зал открылась, в нее вошел президент Обама и сказал просто и эффектно: «Ваша страна нуждается в вас». Затем он обошел всех присутствующих и обратился лично к каждому: «Объясните, почему вы не можете переехать в Вашингтон и послужить своей стране? Что-то не так с вашей работой? Хотите, я позвоню кому надо? Я могу позвонить кому угодно». Никто из пятерых не попросил Обаму позвонить. Никто не стал искать причину, чтобы отказаться от работы. Затем они сделали групповое фото, и Обама исчез за дверью вместе со своей свитой.
Через два месяца Эван прибыл в Вашингтон — это был его первый рабочий день в Цифровой службе США, офис которой располагался в двух кварталах от Белого дома. Следующие три года он провел в Цифровой службе США и говорит, что это был один из лучших этапов его карьеры.
А теперь задумайтесь о том, что сделал и чего не сделал Обама. Он не сказал Эвану и остальным, чтобы они переехали в Вашингтон и там довели код до совершенства. Он поделился с профессионалами проблемой, и большой проблемой: «Программное обеспечение правительства США нуждается в улучшении, и я хочу, чтобы вы сделали это». Иначе говоря, он поделился проблемой, обратился непосредственно к творческой стороне личности разработчиков: как они будут строить высокие технологии для правительства? Какие проблемы они могли бы решить, если бы их поддержал президент? Он заставил их понять, что ему нужны их ум и воображение, а не только умения в области кодирования. Возможностей было очень много — «это среда со множеством целей», как любит говорить Эван.
Организация Эштона Катчера Thorn обратилась к разработчикам за помощью из-за того, что у нее не было другого выхода, Обама — потому что оказался в кризисной ситуации. Но эффективные компании превращают методологию «Спросите своего разработчика» в повседневную практику, открывая разработчикам простор для творчества. Отличный пример реализации этого подхода — Basecamp, небольшая, но процветающая софтверная компания из Чикаго, в которой работают около 60 сотрудников.
Джейсон Фрайд и его соучредитель Дэвид Хайнемайер Хенссон управляют Basecamp почти как лабораторией, занимающейся изучением таких способов работы, которые делают сотрудников счастливыми и позволяют выполнять работу наилучшим образом. Дэвид, который подписывается как DHH, — разработчик, получивший известность после создания широко используемого фреймворка для веб-программирования Ruby on Rails. Помимо прочего, он и Джейсон много пишут об организации работы. Вместе они опубликовали две книги о разработке ПО и три книги о современном рабочем месте под названием «Remote: офис не обязателен», «Rework: бизнес без предрассудков» и «Не сходите с ума на работе». Они любят делиться своими идеями и даже предлагают однодневные семинары, где учат тому, как принять неортодоксальный подход 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, совпадающих с химическим обозначением фреона — разрушителя озонового слоя Земли.
Я пригласил Озона и Лизу и освободил для них на две недели один из драгоценных конференц-залов в нашем офисе. Я обрисовал им проблему с процессом переноса телефонных номеров и предложил за две недели создать программу, необходимую для его автоматизации. Лиза знала, как осуществляется перенос, а Озон знал нашу программную базу вдоль и поперек. Лиза должна была рассказать Озону все, что знала, и предоставить ему свободу в поисках решения проблемы. А потом я ушел.
В первый момент они оторопели, но потом принялись за работу. Лиза продемонстрировала Озону несколько операций по переносу номеров, проработав все детали вместе с ним. Затем она передала ему клавиатуру и заставила выполнить с десяток таких операций — мы называем это «прогулка в обуви клиента». После того, как Озон прочувствовал проблему, она спросила его: «Ну вот, можно создать программу, которая будет делать это?»
Озон начал моделировать проблему, переспрашивая Лизу: «Это верно?» К концу первого дня у них была собрана основа модели данных. Имея ее, Озон уже мог создать форму, с помощью которой клиенты будут вводить информацию о переносе своих телефонных номеров. Как выяснилось, клиенты нередко предоставляли неверную информацию, которая требовала уточнений. Эта проблема легко решалась с помощью ПО. К концу второго дня у них была рабочая форма для сбора необходимой информации.
Затем Лиза заметила, что если бы оператор мог переносить номера на разных этапах взаимодействия с клиентами, то это значительно ускорило бы работу. Озон сказал, что в типичном процессе разработки ПО добавление такой функции могло занять несколько месяцев. Но в этом случае он смог построить рабочий вариант за час.
Конечно, было бы лучше, если бы мы с самого начала не заварили всю эту кашу. Но такова реальность в быстрорастущем стартапе. Внесу ясность: не в моих правилах запирать разработчика и менеджера по продукту в конференц-зале на две недели и просовывать им пресловутую пиццу под дверь. Это не лучшая управленческая практика. Но данный пример показывает, что могут сделать разработчики, когда они мотивированы. Я приношу свои извинения Лизе и Озону. Но я им очень благодарен.
Проект по созданию программы для переноса телефонных номеров — отличный образец совместного поиска не просто хорошего, а эффективного решения. Предоставить разработчику возможность глубоко понять потребности пользователя, а затем позволить ему удовлетворить их — вот что такое совместное решение проблемы. Лиза помогла Крису понять, зачем нужен код, который он пишет, и проникнуться эмпатией к клиентам, ну а после этого создание приложения стало тривиальным.
Истина заключается в том, что большинство программных средств довольно просты. Это то, что разработчики называют CRUD-приложениями — от слов Create, Read, Update, Delete (создание, чтение, обновление, удаление). Большинство приложений в интернете — это формы, которые позволяют пользователю вводить, изменять, выводить или удалять данные. Почти все сайты или мобильные приложения, которыми вы когда-либо пользовались, на 95% состоят из CRUD-операций. Это вовсе не высшая математика.
Это означает, что время, требующееся для решения проблемы, и качество решения зависят от того, насколько разработчик понимает проблему, как в случае с Озоном. Когда разработчики действительно увлечены работой, включается внутренняя мотивация, которая помогает генерировать новые и еще более творческие идеи. Когда они просто изучают техническое задание, у них нет ощущения связи с теми, кто будет использовать ПО. Код становится громоздким и подверженным ошибкам из-за незнания того, как он будет использоваться. Плюс и сам процесс написания кода занимает целую вечность, поскольку разработчик не увлечен им, а его интуиция спит.
Вот почему, если вы когда-нибудь соприкасались с разработчиками или у вас были команды, создающие ПО для вашего бизнеса, вам приходилось прилагать массу усилий, чтобы ускорить процесс. Но он, похоже, всегда занимает больше времени, чем хотелось бы. Чад Этцель, он же Джаззи Чад, считает это естественным следствием неправильного процесса, в котором менеджеры указывают разработчикам, какие именно решения создавать, а не включают их в процесс на более раннем этапе, когда проблема, подлежащая решению, только еще определяется.
«Руководство компании требует от менеджеров достижения деловых или финансовых целей. Поэтому менеджеры придумывают идею продукта и устанавливают сроки, но они зависят от разработчиков, выполняющих задания. Технической команде тяжело, если кто-то просто приходит и говорит: “Сделай это быстро и к такому-то сроку”, а затем убегает».
Включение разработчиков в процесс обсуждения задания на раннем этапе — это не просто вопрос вежливости и стремление не обидеть. Подобный подход дает реальные преимущества. Как менеджеры могут выдерживать сроки, если они не понимают сути реальной работы, подлежащей выполнению? Что делать, если проблему невозможно решить в установленные сроки? Либо будет урезана функциональность, либо работа будет выполняться в спешке, либо разработчики перегорят и уйдут в другое место. Это нельзя назвать хорошим результатом.
Вместо того чтобы предлагать инженерам какое-то решение, менеджеры по продукту могут поделиться проблемой и попросить их помочь найти самый быстрый способ решения с учетом существующих систем.
«Каждый раз, когда я слышу фразы вроде “Это должно быть сделано быстро” или “Вы можете сделать это за день”, они сводят меня с ума, — говорит Чад. — Дело в том, что, пока не поймешь, как увязать все это, как построена инфраструктура, невозможно представить, сколько времени уйдет на работу. Думаю, что именно из-за этого порою и возникают разногласия между менеджерами и инженерами».
Чад отмечает, что многие разработчики «более глубоко понимают возможности интеграции или технической приемлемости некоторых продуктов либо функций, когда менеджер продукта говорит: “Нам нужна такая-то и такая-то функция”, а инженер отвечает: “Отлично, это займет шесть месяцев, поскольку при данной организации инфраструктуры мы не можем просто добавить эту функцию”. Но тогда менеджер может не до конца понимать, почему это так трудно».
Поиск самого простого технического решения либо кратчайшего пути в конкретной обстановке — это именно то, чем инженеры зарабатывают на жизнь. Это именно то, чему их учат. На самом деле существует так называемый алгоритм Дейкстры, который находит кратчайший путь между несколькими узлами, и все мы хорошо знаем его. Но вместо того чтобы использовать эту возможность, большинство компаний советуют разработчикам забыть о ней. Это почти преступление.
Джаззи Чад настолько талантливый разработчик, что я до сих пор сожалею о нашей неспособности найти достойное применение его творческого воображения, пока он работал в компании Twilio. Он пришелся ко двору в компании Apple, где уже более четырех лет занимается iOS — операционной системой iPhone и iPad.
Чем они его привлекли? Предложением решать проблемы и свободы поиска. Когда он присоединился к Apple, руководство определило Чада в команду специалистов по искусственному интеллекту, где не было разработчиков мобильных приложений его уровня. Затем перед ним поставили задачу: выяснить, как лучше всего заставить помощника Siri делать нечто больше, чем просто голосовое управление. Это Чад разработал все «рекомендации Siri» в вашем iPhone. Чад любит свободу. Вместо того чтобы сказать ему «Этот пиксель идет сюда», его менеджер просто говорит: «Подумай, что ценного Siri может дать клиентам iPhone».
Среди прочего Чад подчеркивает, что менеджеры могут подключать разработчиков к удовлетворению потребностей клиентов и помогать им принимать решение. Высокопрофессиональные менеджеры по продукту — это не промежуточные звенья между потребностями клиентов и разработчиками. На самом деле они устраняют все лишнее — предвзятые решения и ошибочные предположения — и упрощают коммуникацию. Высокопрофессиональные менеджеры по продукту не изолируют разработчика от потребностей клиента — они облегчают ему понимание проблем клиента. Чем больше лишних звеньев между клиентами и разработчиками, тем хуже. Это игра в испорченный телефон, где сообщение передается через такое количество людей, что у разработчиков почти не остается шансов понять клиентов, использующих созданное ими ПО.
Один из экстремальных примеров проблемы «слишком большого числа промежуточных звеньев» приводит Патрик Маккензи (он же Patio11), который работал на японского системного интегратора, предоставляющего аутсорсинговые услуги по разработке ПО японским компаниям, в основном учебным заведениям. Бизнес-модель этой компании переводила проблему «совместного поиска решений» почти на астрономический уровень. В одном особенно неудачном проекте длинная цепочка промежуточных звеньев так достала Патрика, что он ушел не только из фирмы, но и из мира бизнеса на более чем 15 лет.
Один из японских университетов решил автоматизировать ручную систему выставления счетов. В ручном режиме работник сидел за столом с кипой счетов-фактур с левой стороны стола и стопкой банковских выписок — с правой. Он вписывал необходимую информацию в счета-фактуры и ставил печать на тех, что подлежали оплате. Естественно, университет хотел получить программу для выполнения этой операции. Таким образом, администратор в университете направил запрос университетскому закупщику, контактировавшему с представителем фирмы, тот передал техническое задание менеджеру проекта, который переадресовал его менеджеру по продукту, а последний — инженерам.
Задание было таким: разработать компьютерную программу, которая воспроизводит виртуальную стопку счетов-фактур в левой части экрана и виртуальную стопку банковских выписок — в правой. Оператор кликает элемент в левой стопке, затем соответствующий элемент в правой стопке и под конец нажимает клавишу «Enter». Это была в буквальном смысле имитация ручного процесса, но на экране компьютера.
«Наши представители по работе с заказчиками сказали: “Да, мы можем создать такую программу”, а когда это задание дошло до разработчиков, мы опешили: “Да это же, мягко говоря, безумие”».
Ясно же, что компьютер может просто сопоставлять банковские выписки и счета-фактуры автоматически, за миллисекунды без всякого оператора. Но у разработчиков не было возможности пройти всю цепочку промежуточных звеньев в обратном направлении и объяснить этот факт тем, кто будет использовать данную систему.
«Таким образом, от нас требовали создать систему, которая не должна существовать, которую сложнее построить, чем систему “компьютер делает все от начала до конца”, и которая обойдется клиентам дороже. Не говоря уже о том, что там должен сидеть человек, жизнь которого уходит на кликание мышью, — вспоминает Патрик. — Все, что описано в техническом задании, могло быть выполнено компьютером — быстрее, дешевле и лучше».
Столкнувшись с подобным раз, другой, третий, Патрик решил, что с него хватит, и рискнул создать собственную компанию. Понимая, что учителя слабо обеспечены дешевыми программами для школьных занятий, он создал Bingo Card Creator — сайт, где учителя могли оформить подписку за несколько долларов в месяц и создавать пользовательские, как вы уже догадались, карточки лото. Карточки лото — это удобный образовательный инструмент. Учителя в начальных школах делают специальные карточки для уроков, например с произношением или написанием слов. Но они делают это вручную. Когда у вас 30 учеников в классе, вам нужно 30 карточек, сделать которые — трудоемкая задача. Сайт Патрика позволяет задавать слова, цифры или картинки и распечатывать столько карточек, сколько нужно, всего за $30. В конечном итоге у Патрика оказалось более 8000 клиентов, и в пиковый год сайт Bingo Card принес $80 000 дохода и $48 000 валовой прибыли. Это не сделало Патрика богачом, но, когда он подсчитал, сколько времени заняла работа, его зарплата оказалась больше $1000 в час. Неплохо для аудитории и потребности, о которой большинство людей, наверное, даже не задумывалось.
Затем он нацелился на другую клиентуру — профессионалов, имеющих собственное дело. Неявка клиентов к врачам, дантистам и парикмахерам приводила к большой потере дохода. Для небольшого и часто индивидуального бизнеса старая поговорка «время — деньги» в таких случаях очень верна. Патрик создал приложение , еще один SaaS-сайт, для автоматического телефонного напоминания клиентам о встречах. К тому времени, когда Патрик продал этот бизнес, он приносил в среднем шестизначный доход и прибыль. Именно такие проблемы Патрик любил решать, поскольку знал, что его решения облегчают жизнь клиентов.
Интернет в отличие от ушедшей эры коробочного ПО позволил Патрику не только самостоятельно создавать сайты, но и продавать услуги глобальной аудитории, размещая рекламу в Google и Facebook. Он немного платил Google за привлечение клиентов, сам писал код, обеспечивал поддержку пользователей и был компанией в одном лице. Патрик зарабатывал достаточно, чтобы оплачивать счета, и регулярно писал в блоге о своих достижениях. Он полностью устранил промежуточные звенья, отделяющие продукт от клиентов, и показал, почему они не нужны. Но что еще важнее, он продемонстрировал, что разработчик — это больше, чем безответный работник, пишущий код. Это сделало его чем-то вроде знаменитости среди предпринимателей — он показал средний палец «боссам» и обеспечивал себя и свою растущую семью, раскрутив два бизнеса.
Вскоре после появления Twilio Patio11 стал одним из наших самых больших поклонников. Он построил приложение Appointment Reminder, проводившее обзвоны и рассылавшее текстовые напоминания полностью на наших API.
Но тут произошла забавная вещь. Ему, одному из самых известных независимых разработчиков ПО в мире, а может, и самому известному, позвонил соучредитель компании Stripe Патрик Коллисон. Приложение Stripe — это создатель API, как и Twilio, но не в сфере связи, в сфере платежей. С помощью нескольких строк кода разработчик может получать деньги за созданные им программы. На самом деле Patio11 сам пользовался сервисом Stripe для сбора платежей за приложение Appointment Reminder. Хотя Patio11 в частном порядке и публично не раз заявлял, что никогда больше не будет работать на «боссов», Коллисон сделал ему предложение, от которого он не мог отказаться.
Коллисон со своей командой в Stripe работал над новым проектом Atlas, нацеленном на решение проблемы, с которой столкнулись многие его клиенты, а именно сложность создания компании. Stripe была заинтересована в решении этой проблемы, поскольку считала своей миссией увеличение валового внутреннего продукта интернета, а каждая новая интернет-компания означала рост числа транзакций в сети, часть которых проходила через Stripe. Коллисон предложил Patio11 как человеку, имеющему тягу к созданию собственных компаний, поработать в команде вместе с Тейлором Фрэнсисом, который возглавлял Atlas на начальном этапе. Цель заключалась в облегчении создания собственного бизнеса и превращении регистрации в простую процедуру, подобную заполнению онлайновой формы. Вот так компания Stripe зацепила, если можно так выразиться, самого завидного одиночку интернета. (Если вам интересно, скажу, что завидую ей, поскольку сам не смог придумать что-то подобное.)
Atlas — это простое в использовании приложение, упрощающее регистрацию компании и «устраняющее бумажную волокиту, визиты в банк, юридические сложности и многочисленные сборы». За 20 минут предприниматель может создать C-корпорацию в штате Делавэр, открыть банковский счет, получить не только доступ к онлайн-платежам по кредитным картам, но и стартовые кредиты для популярных стартап-сервисов, таких как AWS и Google Cloud.
Пошел бы Patio11, закоренелый независимый разработчик, в крупную компанию, если бы его попросили просто написать код? Вряд ли. Но Коллисон поделился с ним большой, непростой проблемой и предложил решить ее, предоставив ресурсы хорошо финансируемого стартапа Кремниевой долины и поддержку учредителей. Для такого разработчика, как Patio11, это захватывающая задача.
Пол Грэм был в числе основателей компании Y Combinator, одного из самых успешных бизнес-инкубаторов Кремниевой долины и инвесторов. С момента своего создания в 2005 г. Y Combinator профинансировала более 2000 стартапов, в числе которых компании Airbnb, Stripe, DoorDash и Dropbox. Совокупная стоимость стартапов, финансируемых Y Combinator, по состоянию на октябрь 2019 г. превышала $150 млрд. Сам Пол — разработчик, предприниматель и компьютерщик. Он — мыслитель, руководствующийся логическими принципами, который вводит начинающих предпринимателей в курс дела, а затем выпускает их на свободу.
Один из способов, которым Y Combinator находит или даже помогает создавать новые стартапы, — публикация списка проблем, требующих решения. Y Combinator называет этот список «Запрос на стартапы», описывая его так: «Многие из лучших идей, что мы финансировали, были для нас неожиданными. Но есть и очень интересующие нас направления, и мы хотим, чтобы предприниматели подавали на них заявки». Далее приведен обновленный запрос на стартапы, где в общих чертах излагаются некоторые из этих идей. В нем не указано, как именно нужно решать проблемы — это работа для предпринимателей, и обычно техническая. Нередко Y Combinator финансирует несколько компаний, решающих одну и ту же проблему, хотя и разными способами. Вот некоторые примеры.
Традиционные предприятия 2.0
Мы заинтересованы в стартапах, которые используют традиционные коммерческие или торговые площади интересным и эффективным образом. Как известно, компания Amazon выдавливает из бизнеса торговые центры и гипермаркеты. Вместо того чтобы вести проигрышное сражение с Amazon, брендам необходимо переосмыслить использование торговых площадей и играть на своих сильных сторонах. Например, компании Tesla, Warby Parker и Peloton используют традиционные торговые площади в качестве выставочных залов, дополняющих онлайн-каналы продаж. Без хранения товаров торговые площади могут использоваться гораздо эффективнее.
Технологии удаления углекислого газа
Парижское соглашение поставило глобальную цель — не допустить повышения температуры земной атмосферы более чем на 1,5 °C в этом столетии. Простого перехода на возобновляемые источники энергии недостаточно для достижения этой цели. Нам также придется удалять углекислый газ из атмосферы.
Клеточное сельское хозяйство и мясо из клеточной культуры
Последние научные разработки изменили наше представление о производстве белка. Впервые мы можем производить продукты питания, которые с научной точки зрения неотличимы от продуктов животноводства, таких как мясо и молочные продукты. Выращивание настоящего мяса непосредственно из клеточной культуры — это революционная отрасль науки. Мы хотели бы финансировать больше стартапов, выводящих эту отрасль на рынок. Мы также хотим финансировать стартапы, специализирующиеся на масштабировании клеточного сельского хозяйства. Мир получит огромную выгоду от более устойчивого, дешевого и здорового производства мяса.
Защита от фейкового видео
Фейковое видео переживает подъем. Уже существует технология создания фейковых видео, неотличимых от реальности, и скоро она окажется доступной любому человеку со смартфоном. Мы заинтересованы в финансировании технологий, которые дадут общественности инструменты для выявления фейковых видео- и аудиозаписей.
Пол и его команда — инвесторы, и, как и многие другие бизнес-руководители, они сталкиваются с тем, что их собственные инвесторы (партнеры с ограниченной ответственностью) хотят видеть рост прибыли и коммерческий успех. Чтобы добиться этого, Y Combinator напрямую обращается к разработчикам и предпринимателям. Это великолепный подход.
Представьте себе, что все бизнес-руководители используют одну и ту же тактику в своих компаниях — определяют самые серьезные проблемы бизнеса и обращаются к персоналу с «призывом искать решения». Не каждое решение будет правильным или заслуживающим внимания, но, обозначая крупные проблемы, вы даете разработчикам возможность думать о тех же вещах, что и вы.
Хорошо это или плохо, но все мы любим собственные идеи. Что может быть лучше для того, чтобы привить людям чувство собственности, чем предоставление им возможности самим принимать решения? Если сделать это, они сотворят невозможное. Это тот самый процесс, к которому обращаются Пол, Эштон и Обама.
Есть старая история о том, как NASA пыталось разработать ручку, которой астронавты могли бы пользоваться в космосе. Было сложно заставить чернила течь вверх, и подобные ручки продолжали отказывать. Америка потратила миллионы долларов, пытаясь придумать космическую ручку, пока кто-то не понял, как русские решили эту проблему — они использовали карандаши. Это, конечно, байка, но ее по-прежнему можно услышать в софтверном мире. Как и все хорошие байки, она иллюстрирует распространенную ошибку — решение не той проблемы. NASA нужно было ломать голову не над тем, как сделать ручку, которая пишет в невесомости. Проблема заключалась в том, как писать в космосе.
По сути, методология «Спросите своего разработчика» — это предоставление полномочий. Люди в любой сфере деятельности стремятся соответствовать ожиданиям в их отношении. Методология «Спросите своего разработчика» предполагает высокие ожидания в отношении разработчиков, причем это касается не объема написанного кода, а использования изобретательности и созидательной энергии для решения величайших проблем мира. Разработчики могут соответствовать подобным ожиданиям только в случае предоставления им полномочий и широких возможностей. Самое главное — делиться с ними проблемами, а не решениями.
Конечно, столы для настольного тенниса и трехколесные велосипеды — это неплохо, но я убежден, что ключ к созданию инженерной культуры мирового уровня заключается в привлечении разработчиков к решению больших проблем и использовании их воображения в полном объеме. Несложно понять, так или не так обстоят дела в вашей компании. Когда вы встретите разработчика, спросите, чем он занимается и какую проблему клиента собирается решить. Знает ли он это? Спросите, когда он в последний раз общался с клиентом и что при этом чувствовал. Мотивировало ли его это общение? Спросите, что он узнал от клиента такого, что его удивило. Из его ответов вы поймете, действительно ли разработчики занимаются решением проблем клиентов или их просто просят реализовать уже найденные решения.
Войти с помощью соц. сетей: