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

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

В книге упоминаются социальные сети Instagram и/или Facebook, принадлежащие компании Meta Platforms Inc., деятельность которой по реализации соответствующих продуктов на территории Российской Федерации запрещена.

Переводчик В. Баронин

Редактор В. Ионов

Главный редактор С. Турко

Руководитель проекта Е. Кунина

Дизайн обложки Д. Изотов

Арт-директор Ю. Буга

Корректоры Е. Аксёнова, Т. Редькина

Компьютерная верстка М. Поташкин

Copyright © 1995 by Peter Lynch

The original publisher is Simon & Schuster, Inc.

© 2021 by Jeffrey Lawson

© Издание на русском языке, перевод, оформление. ООО «Альпина Паблишер», 2022

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

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

* * *

О слияниях и поглощениях: жду не дождусь, когда увижу, что же вы создаете

Предисловие Эрика Риса

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

В последние 10 лет я помогал разным компаниям – от стартапов из Кремниевой долины до промышленных гигантов из списка Fortune 50 – повышать шансы на создание подрывных инноваций на основе принципов, изложенных в моей книге «Бизнес с нуля»^[1]. Мне не раз приходилось ловить себя на мысли, что я пытаюсь объяснить цифровую революцию руководителям, которые не понимают сути программного обеспечения. Многие до сих пор верят, что это цунами подрывных изменений обойдет их собственный бизнес. Однажды я работал с группой руководителей высшего звена из крупных ассоциаций больниц, которые отчаянно пытались повысить удовлетворенность своих пациентов, но на протяжении всего нашего общения не переставали находить оправдания низкого качества обслуживания. Ничто из того, что я рассказывал об использовании цифровых инструментов для осуществления трансформации бизнеса, просто не доходило до них. Наконец я спросил: кто из них пользовался приложением Uber или Lyft? Когда все сказали, что являются пользователями этих сервисов, я попросил достать телефоны и посмотреть, как эти приложения показывают, что такси уже в пути и где оно находится. Я попросил их представить, как бы было хорошо с точки зрения качества обслуживания, если бы пациент знал время прибытия медсестры или врача. Создать соответствующее приложение для медицинского персонала не составляет особого труда. Препятствием является только неспособность увидеть связь между программным обеспечением и уходом за пациентами.

Цифровая революция полностью переписывает правила общего менеджмента. Программное обеспечение одновременно снижает транзакционные издержки, разрушает барьеры для входа и ускоряет темпы изменений. Компании и организации, которые не могут справиться с такими темпами и интенсивностью перемен, теряют связь с реальностью. В мире не так много людей, имеющих опыт как в сфере разработки программного обеспечения, так и управления бизнесом. Вот что делает Джеффа Лоусона такой уникальной личностью: он знаком с обоими мирами. Я видел, как руководители крупных компаний невольно подрывают собственный цифровой успех в результате действий (или бездействия), которые нивелируют работу специалистов и убивают инновации.

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

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

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

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

Я имел честь наблюдать, как все созданное Джеффом Лоусоном и его выдающейся командой в компании Twilio реализуется в реальном времени по мере встраивания в наш мир бесчисленными способами, которые мы не прекращаем изобретать. Долгосрочное видение Джеффа и его умение объединять невероятно талантливых людей – вот причины, по которым та невидимая инфраструктура, на которой строится сейчас наша жизнь, работает бесперебойно и четко. Это Twilio позволяет вам написать сообщение водителю Uber или заказать пиццу онлайн. Продукты компании Twilio, встроенные в Hulu, Twitter и Salesforce, помогают общаться и обмениваться информацией. Эти продукты играют важную роль в сфере недвижимости и здравоохранения, а также в многочисленных некоммерческих и благотворительных организациях. Они помогают компаниям, которые раньше не могли даже представить себя цифровыми, осуществить невероятную трансформацию перед лицом жесткой альтернативы – продолжить развитие или погибнуть.

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

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

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

Предисловие переводчика

Со времен первой промышленной революции, т. е. с конца XVIII в., слова, вынесенные в заголовок этого предисловия, означали в первую очередь тех людей, которые двигали вперед научно-технический прогресс. А первые два из них стали официальными названиями профессий и остаются ими по сей день.

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

Уникальность книги Джеффа Лоусона заключается в том, что ее автор, сам профессиональный программист с огромным опытом, написал ее не только и не столько для собратьев-программистов. Вы удивлены? Но принципы инженерной работы в команде, пусть всего только из пары специалистов, с ориентацией на заказчика одинаковы и для разработчиков-программистов в современных США, и для инженеров-механиков в СССР в последней трети XX в. Вы удивлены еще больше? Прочитайте книгу от корки до корки, и вы поймете, что автор, говоря о разработчиках и инженерах, создающих новое ПО, и стратегии их работы, подсознательно обращается ко всем тем, чья карьера связана с техническим созиданием. Терминология значения не имеет… Его взгляды универсальны, но необычны для многих из нас. В частности, он декларирует нечто совершенно странное – идею о том, что разработка ПО должна начинаться с написания грамотного пресс-релиза будущего продукта. И это только один пример нестандартного бизнес-подхода, преподносимого легко и убедительно.

Готовы к неожиданным открытиям в области инженерного процесса? Вперед!

ВСЕВОЛОД БАРОНИН

Пролог
Все началось с билборда

В начале 2015 г. компания Twilio арендовала билборд в Сан-Франциско рядом с Шоссе 101. Билборды технологических компаний давно стали частью ландшафта в районе залива точно так же, как билборды с рекламой фильмов в Лос-Анджелесе. С одной стороны, это повышает узнаваемость бренда, а с другой – является элементом тактики рекрутинга, способом обратить на компанию внимание тысяч инженеров, едущих на работу. Кроме того, в этом есть что-то от стремления показать свое превосходство, поскольку всем нам хочется придумать что-то незаурядное вроде популярной шутки или чего-нибудь такого, что понимают только в Кремниевой долине.

Итак, мы арендовали билборд. Оставалось лишь придумать, что написать на нем. Вокруг этого разгорелись жаркие споры. Некоторые говорили, что нужно поместить на билборд отзывы клиентов. Можно было разместить на нем логотипы известных компаний, использующих нашу облачную коммуникационную платформу, – это как минимум показывало бы, что мы успешны, хотя о нас никто не слышал. В то время наш годовой доход составлял порядка $100 млн, мы готовились выйти на биржу, но не были известным брендом. А все потому, что компания Twilio не продает продукты потребителям. Мы продаем сервис разработчикам программного обеспечения, который позволяет их приложениям передавать голосовые сообщения, SMS, электронные письма и прочее. У нас известные клиенты – Uber, WhatsApp, Lyft, Zendesk, OpenTable, Nordstrom и Nike. Однако наше программное обеспечение прячется внутри сайтов и мобильных приложений. На самом деле если вы являетесь клиентом любой из этих компаний или тысяч других подобных им, то вы, несомненно, пользуетесь Twilio, не подозревая об этом.

Годовая аренда обошлась нам в полмиллиона долларов (да, даже рекламные поверхности в районе залива стоят несуразно дорого!), и теперь требовалось броское послание. Кроме того, существовали сроки, и мы точно знали день, когда рабочие должны были начать монтаж нашей рекламы. Конечно, мы обратились в рекламное агентство, которое подключило к проекту свою лучшую творческую команду и придумало массу идей. Его сотрудники опросили десятки клиентов – разработчиков программного обеспечения, которые использовали нашу платформу для реализации функции коммуникации в своих приложениях. Они переговорили с массой наших сотрудников – «твилионов» (Twilions), как мы их называем, – в стремлении выяснить, что именно делает компанию Twilio особенной. И через несколько месяцев напряженной работы и размышлений устроили большую презентацию. Вы видели эту сцену в сериале «Безумцы» – фирма представляет клиенту (т. е. нам) все блестящие идеи, которые они придумывали. Там были красивые образцы рекламы, которые сопровождались пространными разъяснениями дизайнеров. Это была грандиозная презентация. Однако все, что они предлагали, казалось довольно скучным – нам не понравилось ничего. Дебаты затянулись.

До начала монтажа рекламного плаката оставалось меньше недели, а мы все еще не могли придумать емкий, лаконичный способ выражения того, что делает компания Twilio. К вечеру пятницы у нас так ничего и не родилось, но мы не могли уйти на выходные, не предоставив владельцу билборда эскиз. Мы вместе с директором по маркетингу, креативным директором и директором по производственным вопросам сидели и ломали головы, на какой заурядной рекламной фразе остановиться, когда у меня мелькнула безумная мысль. «Почему бы нам просто не сказать: “Спросите своего разработчика”? – выпалил я. – Как в тех рекламных объявлениях по телевизору, где говорится: “Спросите своего врача, подходит ли вам это лекарство”. А у нас получается: “Спросите своего разработчика, подходит ли вам Twilio”».

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

Вот так мы и выставили наш ярко-красный рекламный щит с тремя словами, написанными гигантскими белыми заглавными буквами: «СПРОСИТЕ СВОЕГО РАЗРАБОТЧИКА». Ниже красовались наш логотип и название компании. Вот и все.

Наш билборд стал сенсацией, по сравнению с другими по крайней мере. «Как Twilio превзошла Хемингуэя» – так называлось эссе Энди Раскина, известного консультанта по маркетингу в сфере высоких технологий. Он намекал на легендарную (хотя, возможно, и вымышленную) историю о том, как Эрнест Хемингуэй поспорил с кем-то на $10, что сможет написать законченный рассказ всего из шести слов, и выиграл пари со следующей фразой: «Продаются детские ботинки. Хорошие и ненадеванные». Раскин говорил, что мы сделали практически то же самое с нашей рекламой из трех слов, создав «блестящий пример того, как с помощью даже очень краткого послания можно поведать емкую и волнующую историю». Не думаю, что Папа Хэм должен уступить свой титул, но, когда твоя реклама вызывает ассоциации с одним из величайших писателей всех времен, ты принимаешь комплимент и не придираешься к его автору.

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

Более того, наше послание работало на двух уровнях.

На одном мы просто говорили, что, хотя вы можете и не знать, чем занимается компания Twilio, «вашему разработчику» это наверняка известно. Мы признавали, что наш бренд известен далеко не всем. Вскоре после этого Twilio стала публичной компанией и была оценена в $2 млрд, которые довольно быстро выросли до $4 млрд. Журнал Forbes поместил нас на обложку, назвав Twilio «самой привлекательной акцией в мире» и заявив, что «компания Twilio – это скрытая сила, стоящая за популярнейшими приложениями».

В 2019 г. наш доход перевалил за $1 млрд. К лету 2020 г. у нас было 190 000 клиентов, а 8 млн разработчиков имели аккаунты на нашей платформе. Наш сервис встроен в тысячи приложений и сайтов. Когда вы пишете водителю Uber из соответствующего приложения – это сервис Twilio. Когда Netflix отправляет вам текстовое сообщение с шестизначным паролем для входа в систему – это опять мы. Когда вы заказываете ужин в DoorDash, уведомление о том, что заказ прибыл, отправляется через Twilio. Понимаете, о чем идет речь? Вы, скорее всего, используете Twilio каждый день, но даже не подозреваете об этом.

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

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

Однако в ряде высокоэффективных технологических компаний разработчики играют огромную роль не только в написании кода, но и в определении стратегии разработки продукта, а также бизнес-стратегии. Они относятся к своим продуктам больше как к произведениям искусства, а не как к поделкам, и в результате удивляют клиентов возможностями цифровых технологий – вспомните об Apple, Google, Spotify и Uber. Компании, которые работают таким образом, привлекают и удерживают самых ценных специалистов, постоянно поражают клиентов инновациями и генерируют высокую прибыль для акционеров. Мышление в духе «Спросите своего разработчика», которое я описываю в этой книге, – способ раскрытия технических талантов, уже опробованный многими гигантами высоких технологий.

Сейчас это важнее, чем было когда-либо раньше.

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

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

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

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

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

Почему это так?

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

«Спроси разработчика» – это не просто набор навыков, это образ мышления. За последнее десятилетие я видел немало людей с таким мышлением в разных функциональных подразделениях – от финансов до поддержки клиентов, от маркетинга до производства, от продаж до разработки продукта, – которые строят цифровое будущее своих компаний. Все они являются создателями. Существует ошибочное мнение, что цифровая революция – дело рук разработчиков. Это не так. Да, компаниям нужны разработчики для создания программного обеспечения. Но в действительности им требуется успешное сотрудничество между всеми функциональными подразделениями и разработчиками программного обеспечения, которые пишут код. Иначе говоря, общие усилия.

Я – разработчик программного обеспечения и пишу коды почти 25 лет, но теперь я еще и генеральный директор публичной компании с несколькими тысячами сотрудников, рыночная капитализация которой летом 2020 г. составила $25 млрд, доход превысил $1 млрд, а число клиентов приблизилось к 200 000. Я все еще пишу коды, но львиную долю времени выполняю функции генерального директора публичной компании. Это ставит меня в уникальное положение, помогая соединить эти две точки зрения и два стиля работы и добиться более гармоничных взаимоотношений между бизнесменами и разработчиками программного обеспечения. В этом и заключается цель настоящей книги: мышление в духе «Спросите своего разработчика» призвано помочь бизнесменам лучше понять технарей и сотрудничать с ними для достижения общих целей.

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

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

Если, на ваш взгляд, технические команды работают усердно, но упускают из виду важные потребности клиентов, то книга «Спроси разработчика» поможет добраться до причин организационных проблем, мешающих пониманию клиентов.

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

Если вы видите необходимость цифровизации и хотите осуществить трансформацию компании, но не знаете, с чего начать, то книга «Спроси разработчика» станет хорошей отправной точкой.

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

Если вы просто не знаете, какие вопросы задавать в быстро меняющемся цифровом ландшафте (а это совершенно обычное дело), то книга «Спроси разработчика» станет отличной отправной точкой для понимания того, что происходит в недрах цифровой революции.

Если вы технический руководитель, пытающийся помочь своим коллегам по бизнесу понять сложности создания отличного программного обеспечения, то книга «Спроси разработчика» даст вам инструменты для укрепления сотрудничества и поможет преодолеть разрыв в понимании с помощью общего языка.

Даже если вы уже далеко продвинулись на пути цифровой трансформации, то книга «Спроси разработчика» поможет вам переосмыслить представление о том, на что способны ваши разработчики.

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

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

Готовы? Вперед!

Часть I
Почему разработчики сейчас важны больше, чем когда-либо

Глава 1
Создать или умереть

Выживают не самые сильные виды и не самые умные, а те, которые наиболее восприимчивы к изменениям.

ЧАРЛЬЗ ДАРВИН. ПРОИСХОЖДЕНИЕ ВИДОВ

В сентябре 2004 г. я поступил на работу в компанию Amazon в качестве менеджера по продуктам и на первом собрании коллектива, на котором мне довелось присутствовать, услышал от основателя и генерального директора Джеффа Безоса то, что навсегда врезалось в память.

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

«Amazon, – сказал он, – не розничный продавец. Мы – софтверная компания».

Это казалось странным, особенно если учесть, что многие сотрудники Amazon в то время были выходцами либо из розничной сети Walmart, либо из Microsoft, занимавшейся программным обеспечением. И те и другие были одинаково удивлены. Но Джефф настаивал на своем. Большинство софтверных компаний тогда продавали ПО на CD-ROM, в коробочном варианте и даже через традиционные магазины CompUSA.

Джефф считал, что Amazon такая же софтверная компания, как Microsoft, Oracle и Adobe. Просто наше программное обеспечение вместо того, чтобы быть продуктом, который мы продаем потребителям, работает за кулисами, позволяя нам доставлять коробки с книгами, музыкой и кучей других вещей к порогу дома покупателя.

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

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

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

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

От центра затрат до центра определения стратегии

Долгое время в большинстве компаний считалось, что ИТ-службы лишь поддерживают программы и серверы в отделах обработки документации или работу персональных компьютеров на рабочих местах. У всех имелись мощные программы для управления финансами и еще более мощные ERP-системы предприятия для отслеживания запасов, поставок и прочего. Но по сути все это предназначалось для учета денег и материалов, т. е. того, что интересно больше всего бухгалтерам. ИТ-служба также обеспечивала персонал компьютерами для выполнения работы и принтерами для распечатки результатов. В 1980‒1990-х гг. ИТ-службы были центрами затрат – они поглощали средства компании, но сами по себе не приносили прибыли. Поэтому многие компании экономили на них и передавали их задачи на аутсорсинг, причем нередко офшорным фирмам, где специалисты обходились дешевле.

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

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

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

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

Компании Uber и Lyft, не имея в собственности ни одного такси, менее чем за пять лет с помощью ПО полностью изменили алгоритм передвижения людей в городах. В свою очередь, Airbnb, не имея в собственности недвижимость, бросила вызов мировой гостиничной индустрии.

Один из моих любимых примеров подобных компаний – производитель матрасов Casper. Эта компания выпускает матрасы и продает их напрямую потребителям через свой сайт. Меня всегда удивляло, почему Casper оказалась в рядах технологических компаний, как ей удается привлекать значительные средства от венчурных инвесторов Кремниевой долины и почему ее оценивают подобно высокотехнологичным компаниям. Есть ли производство менее похожее на высокую технологию, чем изготовление пружин и ткани для сна? Но Casper действительно высокотехнологичная компания. Технология заключается не в самом продукте, а в том, как компания приобретает клиентов и распространяет свои продукты и в конечном счете обеспечивает качество обслуживания на протяжении всего процесса покупки и использования продукта. Благодаря технологии компания может делать все это с размахом и с минимальными вложениями. Она использует стратегии цифрового взаимодействия для обеспечения невероятно быстрого роста. Всего за пять лет с момента основания Casper довела выручку почти до $500 млн с персоналом менее сотни человек. Разительный контраст с крупнейшей в мире компанией по производству матрасов Tempur Sealy, в которой занято 7000 человек, а доход составляет $2,7 млрд. Подумайте о преимуществах, которые дает технология компании Casper: да, Tempur Sealy имеет доход в пять раз больше, но для этого ей требуется в 70 раз больше сотрудников. Победит ли в конечном счете компания Tempur Sealy своего конкурента Casper в его игре, пока трудно сказать, но их война продолжается.

Подобное происходит в каждой отрасли. Возьмите бритвенные приборы: стартап Harry’s бросает вызов общеизвестному бренду Gillette. В сфере инвестиций стартап Robinhood конкурирует с Fidelity, T. Rowe Price и другими институтами с вековой историей. Компания Opendoor перевернула сферу сделок с недвижимостью, изменив процесс покупки и продажи домов. В одной отрасли за другой цифровые компании используют технологию для вывода на рынок новых продуктов и делают это быстрее, дешевле при более высоком качестве обслуживания.

Можно сказать и по-другому: программное обеспечение превратилось из источника затрат в источник прибыли.

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

Вернемся к матрасам. В ответ на успех Casper фирма Tempur Sealy запустила программу Cocoon by Sealy, которая обеспечивает онлайновое обслуживание клиентов по аналогии с Casper. Получай! Империя наносит ответный удар! А теперь подумай о своем банке. Наверное, он предлагает то же самое, что и любой другой банк. Расчетный счет, сберегательный счет – это высококонкурентная сфера. Так что же отличает один банк от другого? Раньше речь шла о качестве обслуживания в отделении банка. Каким оно было? Сотрудники были хорошо одеты и дружелюбны? Вас угощали печеньем? А вашему ребенку предлагали леденец? Но теперь вы не ходите в офис, а просто открываете приложение. Поэтому банкам нужны совершенно новые навыки – навыки разработки ПО. И они не могут просто купить все эти программы у стороннего поставщика. Конечно, в компаниях, предлагающих программы, необходимые банкам для осуществления цифровой трансформации, нет недостатка. Но если бы банки просто покупали одинаковый софт, все они были бы на одно лицо. В конечном счете они должны ориентироваться на потребности клиентов и реагировать на них, быстро создавая собственное ПО.

Компании, приспособившиеся к новой цифровой реальности, будут лучше обслуживать клиентов и таким образом выживут. Но те, кто этого не сделает, умрут. Возможно, кончина не произойдет в одночасье, но она неизбежна. Да, именно так. Не имеет значения, в какой сфере вы ведете бизнес: банковское обслуживание, авиаперевозки, автомобилестроение, страхование, недвижимость, розничная торговля, здравоохранение… Конечно, необходимо также предоставлять отличный продукт или услугу по конкурентоспособной цене. Но на любом рынке в конечном итоге победит компания, обладающая лучшим программным обеспечением. Джефф Иммельт, бывший генеральный директор General Electric и член совета директоров компании Twilio, однажды сказал своей команде в General Electric: «Если мы не станем лучшей технологической компанией в мире, мы обречены. Мы мертвы. Альтернативы этому нет».

«Это стремление к выживанию», – говорит Вернер Фогельс, легендарный директор по технологиям компании Amazon и один из главных архитекторов сетевых сервисов Amazon, крупнейшей в мире платформы облачных вычислений с десятками дата-центров по всему земному шару. Фогельс – человек очень высокого роста, 198 см, сложенный как полузащитник Национальной футбольной лиги США. Он имеет докторскую степень в области компьютерных наук и провел более десятилетия в университетской среде, прежде чем присоединиться к Amazon.

Сегодня он много ездит по миру и помогает традиционным компаниям адаптироваться к цифровой реальности и выжить. Он также играет главную роль в видеосериале под названием «А теперь создавай» (Now Go Build), который Amazon создала в честь компаний, разрабатывающих программное обеспечение. Помощь клиентам идет на пользу самой Amazon. «Наше облако было бы бесполезно, если бы люди не знали, как им пользоваться. Мы должны помогать им с организационными и культурными преобразованиями, а затем показывать, как принять новую технологию», – говорит Фогельс. Большинство компаний приняли облачные вычисления, но им непросто стать организациями, ориентированными на программное обеспечение. «Это самый часто задаваемый вопрос, – утверждает Фогельс. – Клиенты спрашивают нас: “Как нам это сделать?” Они действительно пытаются учиться у таких компаний, как Amazon».

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

Еще одна проблема – скорость. Цифровые компании могут превратить отличную идею в работающий код за считаные недели или даже дни. Они ежедневно представляют новые версии программ. Чтобы идти в ногу с технологиями, традиционным компаниям необходимо ускориться. «Вы больше не можете позволить себе тратить шесть или 12 месяцев на разработку программ перед их запуском», – утверждает Фогельс. Не верите? Спросите у Blockbuster. Спросите у Borders. Спросите у Nokia. Спросите у Yellow Taxi. Эти компании стали жертвами цифровой революции, потому что не успели достаточно быстро адаптироваться к новой реальности.

Как мыслят разработчики программного обеспечения

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

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

Если вдуматься, то компьютер – это машина, выполняющая математические вычисления, с набором подключенных датчиков (входов) и исполнительных механизмов (выходов). Датчики и исполнительные механизмы – единственный способ узнать, что происходит внутри машины, и на историю компьютеров вполне можно смотреть как на непрерывное усложнение датчиков и исполнительных механизмов, которые позволяют нам «вычислять» все в большем и большем масштабе. Первые два десятилетия вычислительной техники, 1950-е и 1960-е гг., были связаны с математическими вычислениями, и мы применяли перфокарты для ввода и вывода цифровых данных. Программы обрабатывали именно эти цифровые данные. Компьютеры использовались практически только для расчета траекторий ракет и государственного долга. В 1960 г. в мире существовало всего несколько тысяч компьютеров. Но после усовершенствования датчиков и исполнительных механизмов появилась возможность вводить в компьютеры текст и применять программное обеспечение к текстовым задачам. В следующие два десятилетия обрабатывались уже тексты, а не только числовые данные. Появление клавиатур и принтеров в 1970-е и 1980-е гг. открыло дорогу текстовым редакторам, настольным издательским системам и электронным таблицам, и персональный компьютер стал атрибутом каждого рабочего места. Прогресс в сфере датчиков и исполнительных механизмов затем позволил оцифровывать аудио– и видеоинформацию. Компьютеры получили сложные графические и звуковые карты, а 1990-е и 2000-е стали годами мультимедиа – они принесли нам звуковые файлы в формате MP3, компьютерные игры и возможность реализации спецэффектов в таких фильмах, как «Парк юрского периода». Сегодня, имея в кармане постоянно включенные смартфоны, мы несем с собой массу датчиков и исполнительных механизмов, постоянно подключенных к интернету, что превращает весь остальной мир в сферу программного обеспечения. Таким образом, 2010-е и 2020-е гг. связаны с вычислениями практически всего сущего. Именно это сделало последнее десятилетие (и сделает следующее десятилетие) таким захватывающим. Набор проблем, к которым можно применить программный образ мышления, растет взрывными темпами.

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

Вспомните, что компания Apple сделала с пультом дистанционного управления телевизора. До того как Apple выпустила медиаплеер Apple TV, приставки снабжались пультом дистанционного управления с чуть ли не сотней кнопок. Некоторые компании даже хвастались в рекламе количеством кнопок. Рядом с каждой кнопкой была надпись «Громкость больше/меньше», «Номер канала больше/меньше», «Избранное», «Картинка в картинке», «Источник сигнала», «Меню» и т. д. Первый пульт Apple TV имел всего семь кнопок. Почему? Потому что все функции медиаплеера Apple TV были заложены в программное обеспечение данного устройства. Это давало Apple возможность учиться у клиентов и постоянно дополнять программное обеспечение новыми функциями. Разработчики не могут улучшать то, что отлито в пластике и металле, – после выпуска изделия с завода его функциональность остается неизменной. Так что решение убрать кнопки с пульта не только эстетично, но и отражает стратегию развития высоких технологий. Когда я впервые увидел минималистичный пульт Apple TV, то подумал: «О, это уже игра на уровне программного обеспечения».

Тот же образ мышления Стив Джобс применил при разработке iPhone в 2007 г. Он высмеивал телефоны с физической клавиатурой, поскольку, по его замечанию, такая клавиатура всегда была на месте независимо от того, нужна она или нет. Такую клавиатуру нельзя обновить, на ней невозможно изменить язык, и, конечно, ее нельзя убрать, когда она не нужна. Физическая клавиатура и зашитый на заводе язык навечно оставались с устройством. Клавиатура iPhone – это программное обеспечение. Она исчезает, когда не нужна, т. е. ее не видно большую часть времени. При необходимости ее можно переключить на эмодзи или другой язык, если вы полиглот. Это означает, что Apple может поставлять одно устройство во все страны мира. Нужный язык – это просто программное обеспечение, а не то, что зашивается только на заводе-изготовителе.

Другой пример – считыватель кредитных карт Square. Традиционные устройства для работы с кредитными картами – солидные конструкции с экраном как у калькулятора для научных расчетов из 1990-х гг. и клавиатурой. Когда появляется новый метод оплаты или экраны с разрешением более чем в сотню пикселей, то подобное устройство приходится менять. Ведь все, что мог делать традиционный считыватель, зашивалось на заводе в пластик и кремний. Считыватель Square – это всего лишь небольшой интерфейс, необходимый для связи физического мира (считывателя магнитной полосы) с миром программного обеспечения. Все остальное делает программное обеспечение, которое компания Square может обновлять еженедельно. Программное обеспечение становится совершеннее с каждой версией – оно получает новые функции, а ошибки в нем исправляются. Считыватель Square может улучшаться и обучаться так же быстро, как и программные средства, потому что его разработчики вложили в программное обеспечение абсолютно все, оставив только минимальную пластиковую конструкцию, необходимую для выполнения работы. С приходом бесконтактных платежей исчезает все большее число физических элементов. Чем меньше вокруг аппаратных средств, тем больше делают программы.

Еще один пример – электромобили Tesla. У обычного автомобиля на приборной панели десятки кнопок. У большинства электромобилей Tesla всего четыре кнопки и два колесика прокрутки на рулевом колесе. Все остальное – это программное обеспечение, работа которого отображается на гигантском экране. На кнопках Tesla даже нет надписей. Это значит, что все можно рассматривать как программное обеспечение, которое обновляется по мере того, как компания Tesla получает отзывы клиентов. Обновляется не только информационно-развлекательная система электромобиля (туда, например, добавили функцию караоке и YouTube), но и важные функции безопасности.

В октябре 2013 г. один владелец Tesla S наехал на камень, который повредил аккумулятор, что вызвало пожар. Система безопасности предупредила водителя о возникшей проблеме, он благополучно съехал на обочину и вышел из машины за несколько минут до того, как пламя охватило электромобиль. Но для компании Tesla это была PR-катастрофа. Чтобы сделать автомобиль безопаснее, конструкторы Tesla решили увеличить клиренс электромобиля на один дюйм при выходе на высокую скорость. В большинстве компаний это потребовало бы отзыва автомобилей, что обошлось бы производителю в десятки или сотни миллионов долларов и создало бы неудобства для владельцев машин. Но Tesla всего лишь произвела рассылку обновления, изменившего параметры подвески электромобиля, и проблема была решена. Вот так работает программное мышление.

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

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

Вот почему нужно придерживаться принципа «Создать или умереть».

Почему покупка программного обеспечения больше не имеет смысла

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

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

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

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

Хуже всего то, что все это отнимает массу времени. Сам процесс покупки занимает вечность, начиная с запроса предложений. У вас уйдут месяцы на изучение предложений и выслушивание презентаций продавцов ПО, надеющихся получить заказ. Вы будете проводить конкурсы для сравнения продуктов, устраивать совещания, запрашивать мнения. А поставщики ПО будут вас соблазнять: «Купите нашу систему управления персоналом, а мы приложим к ней наш CRM-пакет со скидкой». Затем вы убьете не один месяц на переговоры по условиям контракта, и победившая софтверная компания пришлет к вам команду консультантов, которым потребуются месяцы, а иногда и годы на установку ПО. К тому времени, когда оно начнет работать, вы получите продукт, соответствующий вашим потребностям… двухлетней давности! Потрясающе!

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

Не нужно находиться в Кремниевой долине, чтобы стать свидетелем процесса «Создать или умереть». Достаточно обратить свой взор на Нидерланды.

Принцип «Создать или умереть» в банковской сфере

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

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

Али родился в Канаде. Его родители – иранцы, они переехали в Нидерланды, когда ему было семь лет. В девять он начал писать программы, в 12 – инвестировать в акции, а в 16 лет создал собственную компанию. В 2003 г., когда ему был 21 год, он основал компанию TransIP, которая стала третьим по величине в мире регистратором доменов и провайдером хостинга (это, если угодно, голландский аналог компании GoDaddy). Четыре года спустя Али создал крупнейшего оператора дата-центров в Нидерландах – компанию Datacenter Group. В 2012 г., в 30 лет, Али, по его словам, «понял, что любит создавать продукты, которые нравятся людям, и хочет сделать нечто социально важное».

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

Вместо того чтобы пытаться немного улучшить работу банков, Али задался вопросом: «Если начать все с нуля и придумать новый способ покупки вещей, сбережения средств и перевода денег, например, своему другу, то как бы это могло выглядеть?»

Пользовательский интерфейс Bunq сильно напоминает современное приложение для социальных сетей – простое, персонализированное, с яркими вертикальными полосами всех цветов радуги со словом bunq строчными буквами и простым слоганом: «Банк свободных людей». Приложение выглядит вполне уместно рядом с Uber, Waze, Spotify и другими, установленными на iPhone или Android-устройстве. Это не кажется таким уж большим достижением, но при сравнении пользовательского интерфейса Bunq с приложениями большинства банков разница сразу бросается в глаза.

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

Bunq открывает великолепные возможности для путешествий. Если вы отправляетесь в поездку с группой друзей, то можете создать «группу счетов», чтобы отслеживать, кто за что заплатил. Когда после возвращения нужно провести расчеты, вы просто нажимаете кнопку – и все готово. Большинство клиентов Bunq получают дебетовую карту, но этот банк также предлагает единую проездную карту, поддерживаемую MasterCard без месячной абонентской платы и сборов за обмен валюты. Карта действует как дебетовая и привязывается к вашему счету, но может служить и кредитной картой. Поскольку некоторые клиенты не хотят влезать в долг, Bunq уведомляет о состоянии баланса в реальном времени, чтобы люди видели, сколько у них денег, и воздерживались от трат (или пополняли счет).

Клиенты Bunq – это пока в основном молодые люди, увлеченные общественными проблемами. Bunq позволяет клиентам выбирать, что делать с вложенными средствами. Если вы не хотите, чтобы ваши деньги инвестировались в компании, которые выступают против законов по борьбе с изменением климата, Bunq будет следовать вашим инструкциям. Bunq, кроме того, предлагает «Зеленую карту» и отмечает каждую потраченную вами сотню евро высаживанием дерева.

Али сам финансирует весь проект – он вложил в него €45 млн. Самым большим препятствием для него были не технологии, а регуляторы. К 2012 г. в Нидерландах уже 35 лет ни одна компания не получила разрешения на открытие нового банка. «Это было так давно, что все забыли, как выдавать такие разрешения», – говорит Али. Ситуацию осложняло и то, что Bunq был «новым игроком с 20 работниками, трудившимися в пустующем здании, которое находилось неведомо где». Однако регуляторы понимали, что банковский сектор нуждается в новых идеях. Через три года, в конце 2015 г., Bunq получил разрешение на финансовую деятельность. «Удивительно, что мы действительно справились с этой задачей», – утверждает Али.

На создание первой версии программного обеспечения ушел год, причем Али написал 20 % кода сам. В 2016 г. Bunq начал работу, а к концу 2019 г. он уже присутствовал в 30 европейских странах. Весь клиентский сервис заключался в мобильном приложении – у компании до 2019 г. даже не было веб-версии. Bunq работает полностью в облаке, используя, в частности, сервисы Twilio, Amazon Web Services. Компания обходится силами всего 200 сотрудников. Да, всего 200! Это то, что должно ужаснуть традиционные банки, – масштаб и эффективность программного обеспечения Bunq беспрецедентны. Культура компании настолько технологически ориентирована, что Али описывает Bunq как «высокотехнологичную компанию, которая попутно осуществляет банковские операции». До сих пор компания Bunq набирает обороты – это модель цифровой революции в действии, и конкуренты пристально следят за ней.

•••

Один из таких конкурентов находится на другом конце того же города – это банк ING, который был создан в 1743 году и сейчас управляет активами стоимостью более $1 трлн. Это так далеко от стартапа, что дальше некуда, и ING конкурирует с коллегами в отрасли, которая, как известно, скучна, не склонна к риску и сильно зарегулирована. Тем не менее ING стал одной из самых инновационных организаций по разработке программного обеспечения в мире. В последние несколько лет я сотрудничаю с ING и принимаю участие в его трансформации в высокотехнологичную компанию. Одна из причин успеха ING заключается в том, что изменения начались на самом верху – с назначением технически подкованного топ-менеджера Ральфа Хамерса на должность генерального директора в 2013 г.

Несколько лет назад ING радикально преобразовал свою корпоративную культуру. Одно из изменений заключалось в предоставлении разработчикам ПО творческой свободы. Весь банк, начиная с Хамерса, перешел на аджайл-процессы – не только разработчики, а вся организация вплоть до традиционных отделений банка приняла аджайл-методологию. На корпоративном сайте даже появилось видео под названием «Аджайл-методология в ING», демонстрирующее преобразование. Каждое подразделение разбивается на небольшие команды, работающие в режиме двухнедельных спринтов и проводящие ежедневные летучки. Вот так они борются с натиском новых носителей цифровой революции вроде Bunq. Это живая реализация принципа «Создать или умереть» в банковской индустрии. Я видел результаты такого преобразования собственными глазами, когда Twilio работала с небольшой командой разработчиков ПО из ING, которые замахнулись на умопомрачительный проект.

В 2015 г. технический директор ING Тео Фризвейк обратился к нам за помощью в создании новой системы управления для контакт-центров. Тео руководит 40 инженерами, которые обеспечивают функционирование контакт-центров, используемых более чем 10 000 работниками службы поддержки ING по всему миру. На протяжении многих лет ING росла за счет приобретения банков. Все они использовали разные системы управления контакт-центрами. В общем, у ING оказалось 17 видов таких систем, разработанных разными софтверными компаниями. Поддержка этой мешанины превратилась в кошмар. «Девять месяцев в году нам приходилось заниматься разработкой обновлений просто потому, что поставщик перестал поддерживать старую версию ПО, а обновление одного компонента тянуло за собой обновление другого компонента, затем еще одного, и еще… и так до бесконечности», – говорит Тео.

Мало того, что такой букет устаревшего ПО был головной болью для инженеров-программистов, но это также означало, что 38 млн клиентов банка не обслуживались на должном уровне. Долгое время, когда существующее программное решение не имело необходимой функциональности, они реализовывали другое решение, в результате штаты контакт-центров ING непомерно раздулись. Руководство хотело, чтобы команда Тео выбрала одного поставщика решений для контакт-центров и сделала его единым для всей компании, но Тео предложил руководству другую идею: почему бы вместо покупки еще одной монолитной системы в надежде на улучшение ситуации не позволить его команде построить с нуля собственную систему для контакт-центров? Ее можно было бы достраивать по мере необходимости для решения возникающих проблем или для тестирования новых идей. Это потребовало бы вложения средств, но в конечном счете позволило бы ING стать более гибким, что как раз и было одним из главных приоритетов. Руководство ING поначалу отнеслось к предложению без особого любопытства, если не со скептицизмом.

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

На первый взгляд это казалось безрассудством: ПО для контакт-центров не очень привлекательно в разработке, но невероятно сложно. Такое ПО продают компании вроде Avaya и Genesys, имеющие глубокие корни в телекоммуникационной отрасли. Они десятилетиями создавали контакт-центры и съели на этом собаку, а тут какие-то разработчики из ИТ-отдела банка утверждают, что могут создать кое-что получше, чем эти специализированные гиганты.

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

Тео сделал это смелое предложение не на пустом месте – в его основе лежало серьезное исследование. В 2014 г. он начал отслеживать новые софтверные компании вроде Twilio, продающие не готовые приложения, а своего рода строительные блоки, которые разработчики могут комбинировать и создавать собственные приложения (я рассматриваю этот сдвиг на рынке ПО в главе 2).

В 2015 г. Тео и его коллеги отправились в Сан-Франциско для участия в конференции SIGNAL нашей компании Twilio. Они интересовались, можно ли использовать продукты Twilio для создания ПО для контакт-центра. Несколько месяцев спустя команда инженеров Twilio прилетела в Амстердам и провела трехдневный форум с инженерами банка ING. «Мы просто проработали несколько сценариев, которые были вполне осуществимы в идеальном мире, но сложны для реализации в старом мире, – говорит Тео. – За три дня удалось создать гораздо больше, чем можно было ожидать. Это вселило в нас энтузиазм. Мы убедились, что можем создать ПО для контакт-центра и перейти к архитектуре с интерфейсом прикладного программирования и микросервисами».

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

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

Можно сделать важный вывод: если вы хотите стать создателем ПО, вам нужно начать с изменения мышления всей компании.

Недостаточно просто нанять кучу новых разработчиков или изменить процесс их работы. Ничего из этого не сработает, если не изменить корпоративную культуру. Без этого вы просто посадите новое дерево в бесплодную почву. Одна из причин, по которым Тео получил зеленый свет, заключалась в том, что банк ING находился в процессе радикальной перестройки. Подобные инновации были бы невозможны, если бы генеральный директор банка Хамерс не сосредоточился на реализации аджайл-подхода.

Что же касается риска, то Тео говорит, что именно он приносит ему успех. «Я хочу добиться перемен. Я хочу чего-то достичь. Для меня это была большая возможность. А счастья не видать, если не рисковать».

Весной 2016 г. инженеры приступили к работе над проектом под названием Contact Center 2.0. Многие компании добавляли программные продукты Twilio в ПО своих контакт-центров, но никто не строил новый контакт-центр, подобный центру ING. Как говорит Тео, «у нас не было примера для подражания. Подобного сочетания функциональности никто раньше не реализовал, и мне это действительно нравилось». Инженеры были полны энтузиазма и верили, что они могут добиться успеха, но, по словам Тео, «довольно многие скептически смотрели на нашу способность справиться с этим делом».

Летом 2017 г. инженеры начали пилотное тестирование Contact Center 2.0 в нескольких отделениях банка, и этот процесс быстро распространился на все контакт-центры ING в Нидерландах. К концу 2019 г. Contact Center 2.0 использовали 11 000 работников службы поддержки в семи странах – ожидалось, что глобальное развертывание этой системы завершится к концу 2021 г.

Риск тут же начал окупаться. Инженеры непрерывно вносят исправления и обновления, улучшая код еженедельно, и постоянно получают обратную связь от клиентов, т. е. представителей службы поддержки ING, а также конечных пользователей банка. «Все происходит быстро и в реальном времени. Нам не нужно останавливать работу системы для технического обслуживания. Мы можем вносить изменения так часто, как захотим», – говорит Тео.

Кроме того, код более надежен в работе, и представители службы поддержки могут быстрее отвечать на звонки, что сокращает время ожидания. Система настолько хороша, что другие компании теперь обращаются в ING, чтобы узнать, могут ли они тоже создать нечто подобное. Даже инженеры Twilio узнают что-то новое о нашем собственном продукте, наблюдая за тем, как ING работает с ним.

Следующее большое достижение ING заключается в привлечении своих разработчиков со всего мира к совершенствованию платформы. В 2019 г. разработчики в Амстердаме запустили пилотную программу совместно с разработчиками из филиала ING на Филиппинах. У этого филиала нет традиционных отделений, он работает только через мобильные телефоны. Тамошние разработчики поднаторели в создании эффективных функций для мобильных телефонов. Они также внесли поправки в систему контакт-центра для удовлетворения своих специфических потребностей и делятся своими новыми функциями с основной командой разработчиков в Амстердаме, которая интегрирует их в базовую платформу.

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

Успех проекта Contact Center 2.0 свидетельствует о мастерстве инженеров ING и доказывает, что обычные, по мнению руководства, ИТ-специалисты могут превратиться в опытных разработчиков, создающих программы мирового класса. Но такие разработчики мирового класса есть везде. Компании должны найти их и реализовать их творческий потенциал. Дайте им почувствовать себя собственниками компании. Тео говорит, что этот проект стал кульминацией его карьеры. Всегда скромный, он отдает должное своим инженерам, а также высшему руководству ING, которое позволило его группе пойти на большой риск. «Я стою на два уровня ниже директора по информационным технологиям, но чувствую, что могу быть предприимчивым, пробовать новое и даже делать ошибки», – говорит он.

В мире, где господствует принцип «Создать или умереть», банк ING – модель эволюции.

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

Этот подход работает во всех отраслях и по всему миру: в Мюнхене, в крупнейшей страховой компании мира Allianz; в США – в компаниях Domino’s, Target и U-Haul. Готовят ли они пиццу или оформляют страховые полисы, занимаются арендой грузового автотранспорта или развозят тюльпаны – независимо от характера бизнеса все они становятся софтверными компаниями.

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

Чтобы оценить, насколько вы готовы к новой реальности, поинтересуйтесь у технических руководителей высшего звена, как они принимали решения типа «создать или купить». Какие технологии являются стандартными, но недостаточными и должны быть куплены – и какие цифровые инновации отличают вас от конкурентов? Подумайте над ответами – многое из того, что воспринималось как дифференцирующее, стало стандартным в последнее десятилетие. Какую аналоговую часть вашего бизнеса следует принести в жертву цифровым технологиям? Какие готовые программные решения сдерживают вас? Как часто вы слышите фразу «Мы не можем это сделать»? Вместо того чтобы принять такой ответ, спросите свою команду, какие изменения или инвестиции могут изменить ответ на «Да, мы можем создать это!».

Глава 2
Новая цепочка поставок программного обеспечения

Важно не то, как вы используете серверы, а то, как вы обслуживаете клиентов.

ЦИТАТА АВТОРА, 2010 Г.

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

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

До недавнего времени в софтверной индустрии такого не было. Большинство софтверных компаний – взять хотя бы Microsoft, Oracle или SAP – самостоятельно написали свои программы от начала до конца. Это работало, когда программное обеспечение было узкоспециализированной областью и на рынке присутствовало относительно мало софтверных компаний, т. е. вплоть до 1990-х и начала 2000-х гг. Это было особенно очевидно, когда разработчики продавали свои продукты в виде загружаемых файлов или на CD-ROM.

Сейчас все компании становятся софтверными, но большинство из них не могут строить все с нуля. Им нужна цепочка поставок – точно так же, как автомобильным компаниям Ford и Toyota, – которая делит отрасль на специализированные области и позволяет каждой компании в экосистеме делать то, что она умеет лучше всего. Однако цепочка поставок программного обеспечения выглядит иначе. В ней компании вместо специализации на спидометрах или рулевых колесах поставляют универсальные части программного кода, которые разработчики объединяют в готовые приложения. Это интерфейсы прикладного программирования (API). Каждый поставщик API предоставляет только часть программного решения. Например, Amazon Web Services предлагает дата-центр, Twilio обеспечивает связь, а Stripe и PayPal позволяют осуществлять платежи. Современные приложения интегрируют десятки этих небольших компонентов в уникальное ценностное предложение для клиента. Такой переход к компонентному программному обеспечению является большим скачком в эволюции софтверной индустрии.

Я называю это третьей эрой программного обеспечения.

Эту тенденцию – переход от готовых решений к строительным блокам – лучше всего предсказал рекламный ролик компании IBM 1990-х гг. Взлохмаченный консультант показывает владельцу бизнеса первый вариант сайта, который, похоже, был сделан без особого участия владельца. Консультант заканчивает свою речь словами: «Теперь у вас есть выбор… между вращающимся логотипом или пылающим». В верхнем левом углу сайта (где в те дни всегда стоял логотип) красуется логотип компании, то глупо вращающийся по кругу, то подсвечиваемый языками пламени. Озадаченный бизнесмен отвечает: «Хорошо, но может ли это оптимизировать мою цепочку поставок?» Идея заключалась в том, что готовое программное обеспечение, обладающее лишь номинальной гибкостью, никогда не удовлетворит потребности быстро развивающегося, сложного бизнеса. Теперь, более чем 20 лет спустя, этот рекламный ролик оказался невероятно пророческим. Но, как это часто бывает, вовсе не компании-старожилы сделали эту идею реальностью.

Краткая история программного обеспечения

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

Сначала компании работали на мейнфреймах. Многие это делают до сих пор, причем гораздо чаще, чем можно представить. Затем появились мини-компьютеры, рабочие станции Unix и, наконец, персональные компьютеры. Те, кому меньше 30 лет, могут не помнить этого, но, когда появился персональный компьютер, программы в буквальном смысле поставлялись на гибких дисках, а позднее – на CD. Программное обеспечение на самом деле везли в коробках! Вы приходили в магазин типа Babbage’s, Egghead Software или Software Etc и брали программы с полки. Серьезно, эти магазины были просто замечательны.

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

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

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

Эта проблема была решена с наступлением второй эры программного обеспечения – с предоставления программного обеспечения как услуги (SaaS – Software as a Service). Это произошло около 20 лет назад. Компанией, которая первой применила эту модель, была Salesforce. Ее основатель и генеральный директор Марк Бениофф стажировался в качестве программиста ассемблера в Apple (т. е. был программистом высшего класса), а после университета пришел в компанию Oracle, где быстро стал весьма успешным менеджером по продажам.

Он получил номинацию «Новичок года» в компании и дорос до вице-президента, когда ему было около 25 лет – самый молодой вице-президент в истории Oracle. В 1999 г. он запустил компанию Salesforce под лозунгом «Конец программного обеспечения». Конечно, на самом деле речь шла не о конце программного обеспечения, а о новом способе его поставки.

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

Со временем SaaS-компании начали обслуживать руководителей всех направлений деятельности в компаниях. Так, финансовый директор (CFO) обращался к компании NetSuite, поставщику финансового ПО. Руководитель отдела маркетинга был подписан на сервис компании Marketo – SaaS-поставщика средств автоматизации маркетинга. Директор по персоналу пользовался сервисом компании Workday. Плата этим компаниям зависела от количества сотрудников, использовавших соответствующее ПО. Больше не нужно было беспокоиться о дата-центрах или лицензиях. На деле многие программные продукты были настолько недорогими, что небольшая команда могла просто оплатить их покупку кредитной картой.

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

Изменение коснулось и бизнес-модели. Вместо того чтобы платить за лицензии на программы в зависимости от количества серверов, включая первоначальный взнос, а затем ежегодную плату за обслуживание, вы просто подписывались на ПО. Когда потребность в программном обеспечении отпадала, подписку просто отменяли – примерно так же, как подписку на журнал.

Когда в 1999 г. компания Salesforce только начинала свою деятельность, многие считали Бениоффа сумасшедшим. Зачем кому-то платить за программное обеспечение, которое ему не принадлежит? Что произойдет, если отключится интернет? Не забывайте, что в те времена интернет не был достаточно быстрым и надежным для SaaS-модели: к 2001 г. только 6 % американцев имели широкополосный доступ к интернету. По данным Исследовательского центра Пью, в те времена подавляющее большинство пользователей выходило в интернет через коммутируемое соединение с пищащими модемами.

Но Бениофф знал, что интернет со временем будет лучше и надежнее. Когда высокоскоростной интернет стал нормой, Salesforce превратилась в одну из крупнейших софтверных компаний в мире, с доходом $17 млрд в 2020 финансовом году. И Salesforce не одинока – за годы, прошедшие с начала тысячелетия, возникло множество многомиллиардных SaaS-компаний.

Но как бы ни были хороши SaaS-поставщики, самая быстрорастущая софтверная компания в мировой истории не имела ничего общего с Salesforce или Workday.

Платформа Amazon Web Services меняет правила игры

Я пришел на работу в компанию Amazon в 2004 г., когда облачная платформа Amazon Web Services (AWS) только появилась. Мой босс сразу же объяснил мне мою миссию. Amazon собиралась строить огромные дата-центры и сдавать в аренду вычислительные мощности не в форме приложений, а в виде строительных блоков, которые разработчики и другие компании могут использовать для создания собственных приложений. Это позволило бы любому разработчику и любой компании использовать все возможности сетевой инфраструктуры Amazon. Сервис должен быть гибким, обеспечивающим мгновенное наращивание и сокращение масштабов. Если ваш трафик резко возрастает и держится на высоком уровне несколько дней, то «эластичное вычислительное облако» просто предоставляет дополнительную компьютерную мощность вашему сайту. Когда всплеск трафика заканчивается, ваш виртуальный дата-центр уменьшается. Вы платите только за те ресурсы, что использовали. Вам выставляют ежемесячный счет аналогично счету за мобильный телефон и электричество.

Модель платы в зависимости от фактического пользования сервисов была огромным прорывом, возможно, не менее значительным, чем сама технология. Старая модель предварительной покупки аппаратных средств («железа») была абсурдно дорогой и чудовищно неэкономной. Десятилетиями компании покупали гораздо больше мощностей, чем им было нужно, и набрали массу избыточного оборудования. Процессоры стояли без дела. Накопители данных пустовали. Уровень использования дисковых систем хранения данных временами не превышал 30 %. Серверы обычно загружались на 10 %. Каждое приложение нуждалось в собственных выделенных серверах и хранилищах данных – достаточных, чтобы справиться с максимально возможной нагрузкой.

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

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

Разница между этой моделью и моделью первой эры программного обеспечения была такой же, как разница между производством электроэнергии с помощью собственного дизельного генератора и покупкой электроэнергии у обслуживающей компании. Вы понятия не имеете, где работают ваши программы и на каком компьютере. Да это и не важно – все происходит в облаке (на заре существования облачных технологий это были чаще всего серверы в Вирджинии). Заботу обо всем этом берет на себя кто-то другой. Единственное, что вас волнует, – это появление в вашем распоряжении дата-центра по щелчку переключателя, причем такого размера, который необходим. Крупные компании ухватились за это решение. Они начали переносить приложения из собственных дата-центров в облако Amazon.

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

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

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

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

Эти тенденции отражаются в бизнес-результатах AWS. Ее продажи выросли практически с нуля в 2007 г. до $40 млрд в год по состоянию на первый квартал 2020 г. От нуля до $40 млрд за 12 лет – поистине беспрецедентный рост. Вот почему эта бизнес-модель – модель платформенного бизнеса – является знаковым моментом в софтверной индустрии.

Но Amazon не единственный двигатель третьей эры программного обеспечения. Microsoft, Google и Alibaba создали свои конкурирующие облачные платформы, предлагающие вычислительные ресурсы, хранилища и многое другое, что могут интегрировать разработчики сервисов. Выручка Microsoft Azure в 2019 г. составила $37 млрд, а Google Cloud – $9 млрд. Это гиганты в своей области. Моя компания Twilio предоставляет API для коммуникаций и быстро растет – в 2019 г. ее доход составил $1,1 млрд. Частная компания Stripe, предоставляющая платежные API, не раскрывает объем своих продаж, но частные инвесторы оценили ее в $36 млрд по состоянию на апрель 2020 г. Третья эра программного обеспечения дает очень много не только клиентам, но и инвесторам.

Как мы пришли к этому?

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

В 2000 г. в компании Amazon царил полный кавардак во всем, что касалось разработчиков и кодов, поддерживающих быстрорастущий розничный бизнес. Разработчики соперничали друг с другом, и координация их действий для получения результата требовала огромных усилий. Рабочий процесс замедлялся, и тогда Безос придумал «правило двух пицц», которое предполагало создание небольших команд, чтобы работа шла быстрее. (В соответствии с его идеей команде должно было хватать двух пицц, чтобы перекусить.) Но все было не так просто.

Как организовать в компании небольшие независимые команды, когда работа замыкается на общий код, который они пишут? Они не могут по-настоящему работать независимо, если изменения, внесенные одной командой, нарушают код, который создали другие команды. Такой продукт просто не будет работать.

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

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

Следующая проблема заключалась в оценке эффективности каждого из этих сервисов и учете того, куда уходят деньги. Если одна команда запустила свой сервис на 10 000 серверов, это хорошо или ужасно неэффективно? И на какую бизнес-цель следует относить затраты? Поэтому Amazon начала списывать затраты на использование этих сервисов даже внутри компании. Некоторые называют это трансфертным ценообразованием, но фактически такая система решает две задачи: делает команды ответственными за свои расходы и помогает принимать решения о том, на что закладывать больше средств в бюджетах.

Небольшие команды отвечают за эффективность своих сервисов, поскольку они по существу называют «цену» для внутренних клиентов, а последним приходится покрывать затраты из своих средств. Если эти «клиенты» недовольны вашей ценой, значит, вам есть над чем работать. Внутренняя система учета согласовывает интересы всех сторон и создает естественный стимул для повышения эффективности с течением времени. Внутреннее ценообразование также позволяет лидерам принимать правильные бюджетные решения. Представьте, что у вас есть два клиентских продукта, один из них приносит доход $100 млн и быстро растет, а другой – $10 млн и растет медленно. На какой из них вы выделите больший бюджет? Ответ очевиден, когда у вас есть показатель в виде дохода. То же самое касается и внутренних сервисов. Когда сервис широко используется внутренними клиентами и быстро растет, вы должны выделять на него больше средств. Но без показателя, позволяющего сравнивать инициативы, трудно сказать, какие команды нуждаются в дополнительных инвестициях. Вот почему введение цены даже для внутренних клиентов чрезвычайно полезно.

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

Вскоре стало понятно, что можно делать бизнес на создании микросервисов и их продаже другим. Компания New Relic, основанная в 2008 г., выпустила программу, которая отслеживает результаты работы сайта. Компания Stripe создала платежные сервисы. Компания Twilio разработала облачную коммуникационную платформу. Еще один пример – Google Maps. С помощью всего лишь нескольких строк кода разработчики могут встроить этот сервис в свой сайт. Это намного лучше, чем самостоятельно запускать автомобили с камерами на крыше на улицы городов мира, а затем создавать карты с аэрофотоснимками, видами улиц и всеми другими функциями, которые уже имеются у Google Maps. Ценностное предложение здесь довольно очевидно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждые две недели мы собираем группу новых сотрудников Twilio. Я провожу с ними получасовое рабочее собрание – и начинаю его так: «Привет! Я – Джефф, и я – разработчик программного обеспечения». Все они знают меня как генерального директора и основателя компании, но я по-прежнему считаю себя разработчиком. В очень многих компаниях цифровой эры существует разрыв между руководителями и разработчиками, фактически осуществляющими цифровую трансформацию. Я надеюсь, что эта книга поможет устранить его, позволив разработчикам, менеджерам и руководителям говорить на одном языке. Как генеральный директор публичной компании и разработчик я смотрю на вещи иначе, чем большинство руководителей, как, впрочем, и большинство разработчиков. Я вижу проблемы и успехи сотрудничества между менеджерами и разработчиками с двух сторон. Чтобы понять идею «Спросите разработчика», полезно познакомиться с моей карьерной эволюцией. Хотя сегодня я генеральный директор, я начал свою трудовую жизнь как программист-самоучка и создатель ПО. Я хочу выделить поворотные моменты моей жизни, которые привели к методологии «Спросите разработчика».

Я вырос в пригороде Детройта, в городке под названием Уэст-Блумфилд. Моя мать была преподавателем математики, а отец – рентгенологом. В начале 1980-х гг. рентгенология была полностью аналоговой. Больница получала от компании Kodak коробки, где было порядка десятка листов пленки, разделенных прокладками из белой плотной бумаги. В больнице бумагу просто выбрасывали – имейте в виду, это было до того, как переработка отходов набрала силу, – и мой отец приносил ее домой и складывал в аккуратную стопку у себя в комнате.

По выходным, когда нам было скучно и хотелось посмотреть телевизор, отец говорил: «Давай сделаем проект!» Мы вытаскивали коробку, полную листов разного размера, и он продолжал: «Что бы ты хотел сделать?» Я говорил что-нибудь вроде: «Давай сделаем робота», или «Давай сделаем видеомагнитофон»», или «Давай сделаем рентгеновский аппарат» – и мы принимались за работу. Например, мы складывали из бумаги коробку размером примерно с видеомагнитофон, а потом я рисовал фломастером кнопки «Воспроизведение», «Пауза», «>>», «<<» и т. п. Я рисовал порт для загрузки кассеты Betamax – да, у нас дома был видеомагнитофон формата Betamax! И всегда, когда мы заканчивали процесс создания, я задавал вопрос, которого боялся мой отец: «Папа, как мы можем сделать так, чтобы это действительно работало?» Если бы отец обладал способностями папы Карло, создавшего Буратино, то он бы, наверное, смог оживить видеомагнитофон, робота… да что угодно, созданное в этот день. Но, увы, оживить наши «проекты» он не мог, и это расстраивало нас обоих.

Так или иначе, мне захотелось создавать. Мне нравилось, что можно просто взять инструменты и материалы и создать что-то. Даже если это что-то не работало… до поры до времени.

В 1983 г. мы приобрели наш первый компьютер, Apple IIe, и я открыл для себя бейсик – простой язык программирования, на котором можно попросить компьютер сделать то, что вы от него хотите. Я начал с глупостей элементарного программирования, вроде:

10 PRINT “Hello World”

20 GOTO 10

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

В 1990 г. наша семья приобрела свой первый персональный компьютер – 386DX с рабочей частотой 20 МГц компании CompuAdd. Это был зверь – огромный бежевый ящик, весивший не меньше 13 кг. На протяжении многих лет я копался во внутренностях этой машины, обновляя железо и софт с Windows 3.0 до 3.1. Периодически я решался на глупости, например удалял на диске C файл command.com или баловался с текстом файла autoexec.bat. К счастью, мой дядя Джерри жил в нашем квартале по соседству, и я мог сбегать к нему, чтобы скопировать его файл autoexec.bat и вернуться к делу.

Я стал тем парнем, который «разбирается в компьютерах». Когда кто-нибудь спрашивал меня, почему у него не работает мышь или почему не загружается компьютер, я обычно не знал конкретного ответа, но зато мог просто залезть в компьютер и устранить проблему. И действительно, я не делал хуже! С компьютером 386DX я научился копаться в железе и программах и баловаться с ними. Я осознал, что даже если испортишь программу, то ее всегда можно исправить. Во многом в этом и заключается суть создания ПО.

Но лишь поступив в колледж, я по-настоящему проникся интересом к программированию. Когда я поступил в Мичиганский университет в 1995 г., большинство сокурсников упивались прелестями обретенной в 18 лет свободы: вечеринки, алкоголь, девчонки, парни… Но что действительно взволновало меня, так это разъем локальной компьютерной сети в моей комнате в общежитии! Впервые у меня был доступ к постоянному интернет-подключению со скоростью 100 Мбит/с, что намного превосходило наше домашнее коммутируемое подключение со скоростью 28 800 кбит/с. Первое, что я сделал после того, как попрощался с родителями, – загрузил по протоколу FTP копию браузера Netscape Navigator 1.0.

Прощайте, сетевые сервисы America Online, здравствуй, «настоящий» интернет! Это случилось буквально через несколько недель после первоначального публичного размещения акций компании Netscape, заставшего мир врасплох, и я оказался одним из миллионов, впервые открывших для себя интернет в эти месяцы.

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

Но еще более интересными оказались «динамические» сайты, которые только начали появляться в то время – они не просто отображали контент. Amazon.com позволял просматривать книги и даже покупать их! Сайты Yahoo, Lycos и AltaVista искали все что угодно. На MapQuest можно было найти любую точку планеты и получить пошаговые инструкции!

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

Я посещал занятия по информатике, изучал основы работы компьютеров – как функционируют процессоры, как работает память, теоретические аспекты современных вычислений (например, почему для компьютеров выбран именно двоичный код) и многое другое. Я начал изучать основы разработки программного обеспечения, писать алгоритмы сортировки на языках C и C++, а также циклы, функции и структуры. Все это было очень интересно, но, как вы, наверное, уже догадались, я скорее «прикладник». Я хотел создавать нечто большее, чем просто алгоритмы сортировки, которые миллионы раз уже создавались миллионами других студентов.

Летом 1997 г., после двух лет изучения курса информатики, я попал на стажировку в компанию Citysearch в Пасадене, штат Калифорния, расположенной в горах к северо-востоку от Лос-Анджелеса. Citysearch имела один из первых крупных сайтов. Ее продуктом был «путеводитель по городу», рассказывающий обо всем, что можно сделать в вашем городе. Незадолго до моего приезда в июне 1997 г. компания перестроила систему управления контентом (CMS), которая позволила ей обновить сайт, и эта новая версия имела новый формат файлов. (Да, данные хранились в файлах и даже не в базе данных!) В первый же день мой менеджер приветствовал меня и изложил задание: мне нужно было преобразовать файлы из старого формата в новый. Он выдал мне компьютер, описания старых и новых форматов файлов и выделил рабочее место.

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

В результате я приходил каждый день на стажировку, сидел за своим столом с 9:00 до 17:00 и копался в интернете. Я изучил новый язык программирования Cold Fusion, набиравший популярность у создателей интернет-приложений. Тем летом я вернулся в Анн-Арбор с желанием начать свое дело.

Я всегда полагал, что лучший способ узнать что-то новое – это взять обязательство перед «клиентами» и заставить себя учиться новому. Поэтому вместе с друзьями, разделявшими мое увлечение интернетом, – Брайаном Левином и Майклом Красманом, – я стал придумывать интернет-продукты, которые можно было бы создать. У нас родился целый ряд идей, но лишь одна из них воплотилась в жизнь.

По всему кампусу в Анн-Арборе были расклеены рекламы компаний, занимающихся конспектированием. Эти небольшие фирмочки с названиями вроде «Грустные конспекты», «Превосходнейшие конспекты» или «Конспекты высшего уровня» работали в копировальных центрах по всему кампусу. Примерно за $50 за курс в семестре вы могли купить конспекты у какого-нибудь очень умного, прилежного студента – ну, знаете, парня в первом ряду аудитории – и учиться по его конспектам, а не по своим собственным, но дрянным. Заплатив $50, после каждой лекции вы тащились по снегу через весь город, чтобы забрать физическую копию конспектов. Эти услуги были довольно популярны, особенно у тех, кто посещал вводные лекции, которые могла слушать тысяча первокурсников.

Мы с Брайаном и Майком решили, что интернет будет лучшим каналом получения этих конспектов, нежели хождение по снегу несколько раз в неделю. Вы можете сидеть в удобной комнате общежития и просматривать свои конспекты в интернете… При большом числе студентов, слушающих сравнительно немногочисленные мегакурсы («Психология», «Экономика» и т. д.), нам требовалось очень немного тех, кто пишет конспекты, чтобы покрыть потребности почти всех первокурсников, а их было 5000, если взять Университет штата Мичиган. А ведь такие услуги пользовались популярностью практически во всех колледжах и университетах. Мы прикинули «на салфетке» и обнаружили, что вся «индустрия» конспектов – это колоссальный рынок размером $15 млн. Поэтому мы решили не продавать конспекты, что в 1997 г. было бы очень трудно сделать в интернете, а просто устроить их бесплатную раздачу. Рекламный рынок был намного больше рынка конспектов лекций, поэтому мы могли бы получать выгоду от размещения рекламы местных и национальных компаний на конспектах.

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

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

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

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

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

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

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

Именно тогда меня пригласил на обед Кевин О’Коннор, основатель и генеральный директор ведущей рекламной сети в интернете той эпохи, компании DoubleClick. Они фактически создали основы баннерной рекламы и представляли первую волну монетизации интернета. Кевин был бизнес-ангелом для Versity, и мы не теряли связи. Во время обеда я сказал ему, что хотел бы заняться чем-нибудь новым, а он ответил, что с удовольствием стал бы сотрудничать со мной. Я подкатился с предложением к Мэтту Левенсону, который работал и в Versity, и в StubHub.

Мы перебрали чуть ли не тысячу идей, исследовали около полусотни самых достойных из них и написали без малого 20 бизнес-планов, но в конце концов идея пришла с неожиданной стороны. Мэтт вырос в Санта-Барбаре, штат Калифорния, и был свидетелем взрывного роста популярности экстремальных видов спорта – скейтборда, серфинга, сноуборда и трюкового велоспорта. Однако товарами для подобных видов спорта торговали исключительно мелкие семейные магазинчики. Это хорошо, пока спорт является нишевым, но, как только он становится массовым, у покупателей, на взгляд Мэтта, появляется желание ходить в гипермаркеты с предсказуемым временем работы, с хорошей политикой возврата товаров и с широким выбором, т. е. пользоваться всем тем, что предлагает интернет-магазин REI для спорта на открытом воздухе. Мы принялись за работу, гадая, как должен выглядеть такой магазин для экстремальных видов спорта.

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

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

Я и Мэтт принялись за работу. Мы остановились на названии Nine Star, которое мне не понравилось, но оно было лучше нашего рабочего названия Rough Riders. После приобретения помещения Мэтт и наша команда сосредоточились на оборудовании магазина и доставке товаров в него, а я занялся созданием программного обеспечения для поддержки работы магазина. Для меня это был уникальный шанс понять, как действует вся технология розницы, и создать нечто более удобное, чем есть в большинстве магазинов. За свою жизнь я бывал в бесчисленных розничных магазинах и тысячи раз видел, как кассиры пользовались лазерным сканером, считывали мои кредитные карты и печатали чеки. Теперь мне предстояло погрузиться в эту тему и узнать, как работает вся эта технология. Что происходит, когда лазерный луч попадает на штрихкод на наклейке на товаре? Какая информация вообще закодирована на магнитной полоске кредитной карты? Откуда ящик кассы знает, когда ему открыться?

Я оформил все это как веб-приложение, поскольку интернет был тем, что я знал. На языке PHP я создал полную систему обслуживания кассовых терминалов – ПО, используемое в розничной торговле для оплаты покупок, приема наличных денег и кредитных карт, печати чеков и многого другого. Из-за того, что я создал цельную систему, у меня была возможность достраивать ее и менять по собственному желанию. Когда нам понадобилась членская программа, я легко встроил ее в систему. Каждого нового клиента мы спрашивали, не хочет ли он стать членом нашего клуба. Если он соглашался, кассир вводил его имя и адрес электронной почты и делал снимок маленькой веб-камерой. Через 30 секунд из кассы выскакивала полноцветная членская карточка. Подростки были от этого в восторге! Карточки Nine Star очень смахивали на кредитные карты. Мы решили, что участники будут получать «возврат» в размере 20 % от суммы, потраченной ими за год, который становится доступным в феврале (когда мы освобождали склад от оставшихся после рождественских праздников запасов). Я встроил в систему обслуживания кассовых терминалов возможность использования «возвращенных денег».

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

Разработчику необходима глубокая концентрация, чтобы держать всю систему в голове. Это называется потоком – такое состояние, когда разум погружен в проблему и вы выполняете невероятные объемы работы. Погружение в базу исходного кода, понимание того, как определенная часть кода должна работать, требует невероятной концентрации. А возможности сосредоточиться при работе в подсобке спортивного магазина как раз и не хватало. Мы сделали все доступные пространства в магазине пригодными для катания, чтобы дети могли носиться по магазину как по скейт-парку. Им это нравилось, а я ненавидел такой подход. Меня постоянно отвлекали громкие звуки и крики работников магазина.

Однажды, когда я был глубоко погружен в свои мысли, один из сотрудников магазина забежал в подсобку. Он похлопал меня по плечу.

– Эй, чувак. Сайт не работает?

Я снял наушники, раздраженный тем, что мне помешали.

– Ты спрашиваешь меня об этом или сообщаешь это мне?! – прорычал я.

Парень медленно попятился, и до меня дошло, во что я превратился: я был сварливым компьютерщиком в подсобке, с которым никто не хотел разговаривать. Именно тогда стало ясно, что мне не место в магазине.

Работая над всеми этими крутыми технологиями в Nine Star, я наблюдал, как из неизвестности поднимается Google и превращается в высокотехнологичного гиганта, как с каждым днем росла Amazon, добавляя на сайт новые категории товаров. Компании, пережившие крах доткомов, начали определять нашу жизнь. Я хотел вернуться в компьютерные технологии, а не в подсобку спортивного магазина. Кроме того, в Nine Star было плохо с деньгами. Все наши средства уходили на закупку товаров. Мы с Мэттом не получали зарплату уже три года, и это оборачивалось очень плохим состоянием моего банковского счета и превышением лимитов по кредитным картам. В забегаловке Subway через дорогу от Nine Star каждый день после 17:00 проходила акция «Два по цене одного», и я покупал там сэндвич за $3,99 на ужин и оставлял второй сэндвич на обед на следующий день. В какой-то момент у мексиканской сети фастфуда Baja Fresh на сайте появился купон на бесплатную тарелку буррито. Это было еще на заре интернета, и, похоже, в Baja Fresh не понимали, что веб-купон можно распечатывать сколько угодно раз. Мэтт и я ели бесплатные буррито два раза в день почти три месяца, пока нас не поймали. Такая вот предпринимательская деятельность.

Размышляя о том, что делать дальше, я подбивал итоги. Итак, я участвовал в создании трех стартапов. Я подключался к процессу в самом начале, когда несколько человек в гараже (или в моем случае в спортивном магазине) пытались сделать что-то из ничего. Но у меня не было опыта работы в большой компании, кроме той летней (на самом деле однодневной) стажировки в Citysearch. Если я захочу однажды создать значимую компанию, то мне нужно узнать, как работают крупные компании. Что работало хорошо? К чему мне следует стремиться в своем следующем стартапе? Что перестает работать, когда компании становятся большими? Каких ловушек следует избегать? Мне нужно было узнать, как работает бизнес, как управлять, руководить и масштабировать быстрорастущую организацию. Стартап – это просто быстрый забег, но как работают реальные компании? Я хотел это выяснить. Также не помешало бы получить зарплату и пополнить свои финансы.

Осенью 2004 г. я принял предложение от платформы AWS и переехал в Сиэтл. Я всегда работал в ничего не имеющих стартапах с теми исполнителями и бюджетами, какие удалось добыть. А теперь это была совершенно другая история – работа в компании мирового уровня и со специалистами мирового класса. Я узнал, как работают такие крупномасштабные системы. Я узнал о технологиях, которые компания разработала, чтобы совладать с масштабами Amazon, о распределенных системах, согласованном хешировании, идемпотентности, теореме Брюера. Все это выходило далеко за пределы того, с чем я имел дело раньше. В момент моего приезда в Сиэттл в AWS, где я стал менеджером по продукту, там трудилось около 30 человек, располагавшихся на шестом этаже Тихоокеанского медицинского центра – старой больницы в стиле ар-деко, которая была преобразована в головной офис компании Amazon. Джефф Безос работал на седьмом этаже, и, если вы оказывались рядом с ним, это означало, что он заинтересован в вашей работе. AWS была его любимым детищем – именно поэтому мы и находились на шестом этаже.

Мы создавали продукты не для потребителей, а для разработчиков вроде меня. Люди, с которыми я работал, действительно изобретали что-то новое. Переосмыслялось все без исключения – продукты, маркетинг, даже ценообразование. Мой напарник по офису Дейв Барт был первым менеджером по перспективному продукту под названием Simple Storage Service, или сокращенно S3, призванного революционным образом преобразовать рынок цифровых хранилищ. Я был назначен на продукт, который позже получил название Flexible Payment Service (FPS). Цель этого платежного сервиса состояла в том, чтобы позволить разработчикам принимать платежи в своих собственных приложениях. Точно так же, как S3 давал разработчикам доступ к облачному хранилищу данных, FPS давал разработчикам доступ к платежной инфраструктуре, которой пользовался крупнейший сайт электронной коммерции в мире. Мы, бывало, шутили, что S3 не зря называют простым сервисом хранения данных, а FPS – гибким платежным сервисом. Наш продукт был в конечном счете слишком сложным и с трудом запускался. Тем не менее это был удивительный опыт. Несмотря на то что Amazon казалась мне огромной компанией, сама она считала себя стартапом. Вся компания была разделена на небольшие команды «на две пиццы», каждая из которых работала как крошечный стартап. В них был дух срочности и энергия, а то, что делалось, имело значение. Там изобретали будущее – вы должны делать все, чтобы ваши технические специалисты обрели именно такое чувство.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я разговаривал с потенциальными клиентами – разработчиками программного обеспечения. Я спрашивал: «Если бы у вас был API, который позволял бы инициировать или принимать телефонные звонки из вашего приложения и делать такие вещи, как воспроизведение аудио, чтение текста или осуществление конференц-связи, вы бы нашли ему применение?»

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

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

В конце 2007 г. я связался с моим первым сотрудником в Versity, а затем и в StubHub Джоном Уолтуисом, чтобы узнать, чем он занимается и интересна ли ему моя идея. Затем я созвонился с Эваном Куком, одним из моих преподавателей в Мичиганском университете, с которым я поддерживал связь и время от времени обсуждал бизнес-идеи. Все были в восторге, и общение с клиентами подтверждало, что интерес есть и у них, поэтому в январе 2008 г. мы сфокусировались исключительно на этой идее.

Для начала нам нужно было придумать название компании. Я – твердый сторонник уникальных названий, которые ни с чем не спутаешь. Мы начали вслух подбирать что-то созвучное слову telephone: Teliph, Teliphoo, Tilapia. Нет, ничего не звучит, а последнее вообще название рыбы. Мы продолжили свое упражнение. Наверное, это выглядело забавно со стороны, но нам было все равно. Минут через 20 я выдал: «Twili, Tweli, Twilio». Последнее вроде бы перекликалось со словом telephone. Удивительно, но домен Twilio.com был доступен всего за $7, и я купил его. Вот и все. Мы выбрали название для своей компании.

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

Сначала мы просто выясняли основы функционирования телекоммуникационной системы, а затем писали первую версию Twilio. Наше ПО обобщало сложность, накопленную в индустрии за столетие, и представляло ее в виде простого API для разработчиков. Такой интерфейс позволяет веб-разработчикам делать то, что им нужно в телекоммуникационной системе, без необходимости изучения языка, на котором говорит телекоммуникационная отрасль. Они просто пишут код на обычных языках вроде Ruby, Python, JavaScript или Java и используют его для создания приложений, способных совершать и принимать телефонные звонки.

Помните тех разработчиков, у которых пропадал интерес к проблеме после того, как они слышали ее описание? При работе над первой версией Twilio мы вернулись к ним, предоставили им доступ и запросили отзывы. Хотя наш продукт был очень сырым, он вызвал чуть ли не восторг разработчиков.

Тем не менее на венчурных инвесторов наш прототип впечатления не произвел. Нам отказывали раз 20. Денег не хватало настолько, что в 2008 г., когда мы с Эрикой поженились, нам пришлось продать свадебные подарки и отнести деньги в банк. Инвесторы могли и не верить в Twilio, но я верил и мои соучредители тоже. Мы не собирались сдаваться. Мы не сомневались, что наш продукт понравится клиентам.

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

Истоки методологии «Спросите своего разработчика»

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

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

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

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

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

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

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

В книге упоминаются социальные сети Instagram и/или Facebook, принадлежащие компании Meta Platforms Inc., деятельность которой по реализации соответствующих продуктов на территории Российской Федерации запрещена.

Переводчик В. Баронин

Редактор В. Ионов

Главный редактор С. Турко

Руководитель проекта Е. Кунина

Дизайн обложки Д. Изотов

Арт-директор Ю. Буга

Корректоры Е. Аксёнова, Т. Редькина

Компьютерная верстка М. Поташкин

Copyright © 1995 by Peter Lynch

The original publisher is Simon & Schuster, Inc.

© 2021 by Jeffrey Lawson

© Издание на русском языке, перевод, оформление. ООО «Альпина Паблишер», 2022

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

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

* * *

О слияниях и поглощениях: жду не дождусь, когда увижу, что же вы создаете

Предисловие Эрика Риса

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

В последние 10 лет я помогал разным компаниям – от стартапов из Кремниевой долины до промышленных гигантов из списка Fortune 50 – повышать шансы на создание подрывных инноваций на основе принципов, изложенных в моей книге «Бизнес с нуля»[1]. Мне не раз приходилось ловить себя на мысли, что я пытаюсь объяснить цифровую революцию руководителям, которые не понимают сути программного обеспечения. Многие до сих пор верят, что это цунами подрывных изменений обойдет их собственный бизнес. Однажды я работал с группой руководителей высшего звена из крупных ассоциаций больниц, которые отчаянно пытались повысить удовлетворенность своих пациентов, но на протяжении всего нашего общения не переставали находить оправдания низкого качества обслуживания. Ничто из того, что я рассказывал об использовании цифровых инструментов для осуществления трансформации бизнеса, просто не доходило до них. Наконец я спросил: кто из них пользовался приложением Uber или Lyft? Когда все сказали, что являются пользователями этих сервисов, я попросил достать телефоны и посмотреть, как эти приложения показывают, что такси уже в пути и где оно находится. Я попросил их представить, как бы было хорошо с точки зрения качества обслуживания, если бы пациент знал время прибытия медсестры или врача. Создать соответствующее приложение для медицинского персонала не составляет особого труда. Препятствием является только неспособность увидеть связь между программным обеспечением и уходом за пациентами.

Цифровая революция полностью переписывает правила общего менеджмента. Программное обеспечение одновременно снижает транзакционные издержки, разрушает барьеры для входа и ускоряет темпы изменений. Компании и организации, которые не могут справиться с такими темпами и интенсивностью перемен, теряют связь с реальностью. В мире не так много людей, имеющих опыт как в сфере разработки программного обеспечения, так и управления бизнесом. Вот что делает Джеффа Лоусона такой уникальной личностью: он знаком с обоими мирами. Я видел, как руководители крупных компаний невольно подрывают собственный цифровой успех в результате действий (или бездействия), которые нивелируют работу специалистов и убивают инновации.

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

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

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

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

Я имел честь наблюдать, как все созданное Джеффом Лоусоном и его выдающейся командой в компании Twilio реализуется в реальном времени по мере встраивания в наш мир бесчисленными способами, которые мы не прекращаем изобретать. Долгосрочное видение Джеффа и его умение объединять невероятно талантливых людей – вот причины, по которым та невидимая инфраструктура, на которой строится сейчас наша жизнь, работает бесперебойно и четко. Это Twilio позволяет вам написать сообщение водителю Uber или заказать пиццу онлайн. Продукты компании Twilio, встроенные в Hulu, Twitter и Salesforce, помогают общаться и обмениваться информацией. Эти продукты играют важную роль в сфере недвижимости и здравоохранения, а также в многочисленных некоммерческих и благотворительных организациях. Они помогают компаниям, которые раньше не могли даже представить себя цифровыми, осуществить невероятную трансформацию перед лицом жесткой альтернативы – продолжить развитие или погибнуть.

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

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

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

Предисловие переводчика

Со времен первой промышленной революции, т. е. с конца XVIII в., слова, вынесенные в заголовок этого предисловия, означали в первую очередь тех людей, которые двигали вперед научно-технический прогресс. А первые два из них стали официальными названиями профессий и остаются ими по сей день.

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

Уникальность книги Джеффа Лоусона заключается в том, что ее автор, сам профессиональный программист с огромным опытом, написал ее не только и не столько для собратьев-программистов. Вы удивлены? Но принципы инженерной работы в команде, пусть всего только из пары специалистов, с ориентацией на заказчика одинаковы и для разработчиков-программистов в современных США, и для инженеров-механиков в СССР в последней трети XX в. Вы удивлены еще больше? Прочитайте книгу от корки до корки, и вы поймете, что автор, говоря о разработчиках и инженерах, создающих новое ПО, и стратегии их работы, подсознательно обращается ко всем тем, чья карьера связана с техническим созиданием. Терминология значения не имеет… Его взгляды универсальны, но необычны для многих из нас. В частности, он декларирует нечто совершенно странное – идею о том, что разработка ПО должна начинаться с написания грамотного пресс-релиза будущего продукта. И это только один пример нестандартного бизнес-подхода, преподносимого легко и убедительно.

Готовы к неожиданным открытиям в области инженерного процесса? Вперед!

ВСЕВОЛОД БАРОНИН

Пролог

Все началось с билборда

В начале 2015 г. компания Twilio арендовала билборд в Сан-Франциско рядом с Шоссе 101. Билборды технологических компаний давно стали частью ландшафта в районе залива точно так же, как билборды с рекламой фильмов в Лос-Анджелесе. С одной стороны, это повышает узнаваемость бренда, а с другой – является элементом тактики рекрутинга, способом обратить на компанию внимание тысяч инженеров, едущих на работу. Кроме того, в этом есть что-то от стремления показать свое превосходство, поскольку всем нам хочется придумать что-то незаурядное вроде популярной шутки или чего-нибудь такого, что понимают только в Кремниевой долине.

Итак, мы арендовали билборд. Оставалось лишь придумать, что написать на нем. Вокруг этого разгорелись жаркие споры. Некоторые говорили, что нужно поместить на билборд отзывы клиентов. Можно было разместить на нем логотипы известных компаний, использующих нашу облачную коммуникационную платформу, – это как минимум показывало бы, что мы успешны, хотя о нас никто не слышал. В то время наш годовой доход составлял порядка $100 млн, мы готовились выйти на биржу, но не были известным брендом. А все потому, что компания Twilio не продает продукты потребителям. Мы продаем сервис разработчикам программного обеспечения, который позволяет их приложениям передавать голосовые сообщения, SMS, электронные письма и прочее. У нас известные клиенты – Uber, WhatsApp, Lyft, Zendesk, OpenTable, Nordstrom и Nike. Однако наше программное обеспечение прячется внутри сайтов и мобильных приложений. На самом деле если вы являетесь клиентом любой из этих компаний или тысяч других подобных им, то вы, несомненно, пользуетесь Twilio, не подозревая об этом.

Годовая аренда обошлась нам в полмиллиона долларов (да, даже рекламные поверхности в районе залива стоят несуразно дорого!), и теперь требовалось броское послание. Кроме того, существовали сроки, и мы точно знали день, когда рабочие должны были начать монтаж нашей рекламы. Конечно, мы обратились в рекламное агентство, которое подключило к проекту свою лучшую творческую команду и придумало массу идей. Его сотрудники опросили десятки клиентов – разработчиков программного обеспечения, которые использовали нашу платформу для реализации функции коммуникации в своих приложениях. Они переговорили с массой наших сотрудников – «твилионов» (Twilions), как мы их называем, – в стремлении выяснить, что именно делает компанию Twilio особенной. И через несколько месяцев напряженной работы и размышлений устроили большую презентацию. Вы видели эту сцену в сериале «Безумцы» – фирма представляет клиенту (т. е. нам) все блестящие идеи, которые они придумывали. Там были красивые образцы рекламы, которые сопровождались пространными разъяснениями дизайнеров. Это была грандиозная презентация. Однако все, что они предлагали, казалось довольно скучным – нам не понравилось ничего. Дебаты затянулись.

До начала монтажа рекламного плаката оставалось меньше недели, а мы все еще не могли придумать емкий, лаконичный способ выражения того, что делает компания Twilio. К вечеру пятницы у нас так ничего и не родилось, но мы не могли уйти на выходные, не предоставив владельцу билборда эскиз. Мы вместе с директором по маркетингу, креативным директором и директором по производственным вопросам сидели и ломали головы, на какой заурядной рекламной фразе остановиться, когда у меня мелькнула безумная мысль. «Почему бы нам просто не сказать: “Спросите своего разработчика”? – выпалил я. – Как в тех рекламных объявлениях по телевизору, где говорится: “Спросите своего врача, подходит ли вам это лекарство”. А у нас получается: “Спросите своего разработчика, подходит ли вам Twilio”».

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

Вот так мы и выставили наш ярко-красный рекламный щит с тремя словами, написанными гигантскими белыми заглавными буквами: «СПРОСИТЕ СВОЕГО РАЗРАБОТЧИКА». Ниже красовались наш логотип и название компании. Вот и все.

Наш билборд стал сенсацией, по сравнению с другими по крайней мере. «Как Twilio превзошла Хемингуэя» – так называлось эссе Энди Раскина, известного консультанта по маркетингу в сфере высоких технологий. Он намекал на легендарную (хотя, возможно, и вымышленную) историю о том, как Эрнест Хемингуэй поспорил с кем-то на $10, что сможет написать законченный рассказ всего из шести слов, и выиграл пари со следующей фразой: «Продаются детские ботинки. Хорошие и ненадеванные». Раскин говорил, что мы сделали практически то же самое с нашей рекламой из трех слов, создав «блестящий пример того, как с помощью даже очень краткого послания можно поведать емкую и волнующую историю». Не думаю, что Папа Хэм должен уступить свой титул, но, когда твоя реклама вызывает ассоциации с одним из величайших писателей всех времен, ты принимаешь комплимент и не придираешься к его автору.

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

Более того, наше послание работало на двух уровнях.

На одном мы просто говорили, что, хотя вы можете и не знать, чем занимается компания Twilio, «вашему разработчику» это наверняка известно. Мы признавали, что наш бренд известен далеко не всем. Вскоре после этого Twilio стала публичной компанией и была оценена в $2 млрд, которые довольно быстро выросли до $4 млрд. Журнал Forbes поместил нас на обложку, назвав Twilio «самой привлекательной акцией в мире» и заявив, что «компания Twilio – это скрытая сила, стоящая за популярнейшими приложениями».

В 2019 г. наш доход перевалил за $1 млрд. К лету 2020 г. у нас было 190 000 клиентов, а 8 млн разработчиков имели аккаунты на нашей платформе. Наш сервис встроен в тысячи приложений и сайтов. Когда вы пишете водителю Uber из соответствующего приложения – это сервис Twilio. Когда Netflix отправляет вам текстовое сообщение с шестизначным паролем для входа в систему – это опять мы. Когда вы заказываете ужин в DoorDash, уведомление о том, что заказ прибыл, отправляется через Twilio. Понимаете, о чем идет речь? Вы, скорее всего, используете Twilio каждый день, но даже не подозреваете об этом.

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

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

Однако в ряде высокоэффективных технологических компаний разработчики играют огромную роль не только в написании кода, но и в определении стратегии разработки продукта, а также бизнес-стратегии. Они относятся к своим продуктам больше как к произведениям искусства, а не как к поделкам, и в результате удивляют клиентов возможностями цифровых технологий – вспомните об Apple, Google, Spotify и Uber. Компании, которые работают таким образом, привлекают и удерживают самых ценных специалистов, постоянно поражают клиентов инновациями и генерируют высокую прибыль для акционеров. Мышление в духе «Спросите своего разработчика», которое я описываю в этой книге, – способ раскрытия технических талантов, уже опробованный многими гигантами высоких технологий.

Сейчас это важнее, чем было когда-либо раньше.

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

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

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

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

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

Почему это так?

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

«Спроси разработчика» – это не просто набор навыков, это образ мышления. За последнее десятилетие я видел немало людей с таким мышлением в разных функциональных подразделениях – от финансов до поддержки клиентов, от маркетинга до производства, от продаж до разработки продукта, – которые строят цифровое будущее своих компаний. Все они являются создателями. Существует ошибочное мнение, что цифровая революция – дело рук разработчиков. Это не так. Да, компаниям нужны разработчики для создания программного обеспечения. Но в действительности им требуется успешное сотрудничество между всеми функциональными подразделениями и разработчиками программного обеспечения, которые пишут код. Иначе говоря, общие усилия.

Я – разработчик программного обеспечения и пишу коды почти 25 лет, но теперь я еще и генеральный директор публичной компании с несколькими тысячами сотрудников, рыночная капитализация которой летом 2020 г. составила $25 млрд, доход превысил $1 млрд, а число клиентов приблизилось к 200 000. Я все еще пишу коды, но львиную долю времени выполняю функции генерального директора публичной компании. Это ставит меня в уникальное положение, помогая соединить эти две точки зрения и два стиля работы и добиться более гармоничных взаимоотношений между бизнесменами и разработчиками программного обеспечения. В этом и заключается цель настоящей книги: мышление в духе «Спросите своего разработчика» призвано помочь бизнесменам лучше понять технарей и сотрудничать с ними для достижения общих целей.

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

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

Если, на ваш взгляд, технические команды работают усердно, но упускают из виду важные потребности клиентов, то книга «Спроси разработчика» поможет добраться до причин организационных проблем, мешающих пониманию клиентов.

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

Если вы видите необходимость цифровизации и хотите осуществить трансформацию компании, но не знаете, с чего начать, то книга «Спроси разработчика» станет хорошей отправной точкой.

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

Если вы просто не знаете, какие вопросы задавать в быстро меняющемся цифровом ландшафте (а это совершенно обычное дело), то книга «Спроси разработчика» станет отличной отправной точкой для понимания того, что происходит в недрах цифровой революции.

Если вы технический руководитель, пытающийся помочь своим коллегам по бизнесу понять сложности создания отличного программного обеспечения, то книга «Спроси разработчика» даст вам инструменты для укрепления сотрудничества и поможет преодолеть разрыв в понимании с помощью общего языка.

Даже если вы уже далеко продвинулись на пути цифровой трансформации, то книга «Спроси разработчика» поможет вам переосмыслить представление о том, на что способны ваши разработчики.

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

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

Готовы? Вперед!

Часть I

Почему разработчики сейчас важны больше, чем когда-либо

Глава 1

Создать или умереть

Выживают не самые сильные виды и не самые умные, а те, которые наиболее восприимчивы к изменениям.

ЧАРЛЬЗ ДАРВИН. ПРОИСХОЖДЕНИЕ ВИДОВ

В сентябре 2004 г. я поступил на работу в компанию Amazon в качестве менеджера по продуктам и на первом собрании коллектива, на котором мне довелось присутствовать, услышал от основателя и генерального директора Джеффа Безоса то, что навсегда врезалось в память.

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

«Amazon, – сказал он, – не розничный продавец. Мы – софтверная компания».

Это казалось странным, особенно если учесть, что многие сотрудники Amazon в то время были выходцами либо из розничной сети Walmart, либо из Microsoft, занимавшейся программным обеспечением. И те и другие были одинаково удивлены. Но Джефф настаивал на своем. Большинство софтверных компаний тогда продавали ПО на CD-ROM, в коробочном варианте и даже через традиционные магазины CompUSA.

Джефф считал, что Amazon такая же софтверная компания, как Microsoft, Oracle и Adobe. Просто наше программное обеспечение вместо того, чтобы быть продуктом, который мы продаем потребителям, работает за кулисами, позволяя нам доставлять коробки с книгами, музыкой и кучей других вещей к порогу дома покупателя.

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

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

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

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

От центра затрат до центра определения стратегии

Долгое время в большинстве компаний считалось, что ИТ-службы лишь поддерживают программы и серверы в отделах обработки документации или работу персональных компьютеров на рабочих местах. У всех имелись мощные программы для управления финансами и еще более мощные ERP-системы предприятия для отслеживания запасов, поставок и прочего. Но по сути все это предназначалось для учета денег и материалов, т. е. того, что интересно больше всего бухгалтерам. ИТ-служба также обеспечивала персонал компьютерами для выполнения работы и принтерами для распечатки результатов. В 1980‒1990-х гг. ИТ-службы были центрами затрат – они поглощали средства компании, но сами по себе не приносили прибыли. Поэтому многие компании экономили на них и передавали их задачи на аутсорсинг, причем нередко офшорным фирмам, где специалисты обходились дешевле.

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

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

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

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

Компании Uber и Lyft, не имея в собственности ни одного такси, менее чем за пять лет с помощью ПО полностью изменили алгоритм передвижения людей в городах. В свою очередь, Airbnb, не имея в собственности недвижимость, бросила вызов мировой гостиничной индустрии.

Один из моих любимых примеров подобных компаний – производитель матрасов Casper. Эта компания выпускает матрасы и продает их напрямую потребителям через свой сайт. Меня всегда удивляло, почему Casper оказалась в рядах технологических компаний, как ей удается привлекать значительные средства от венчурных инвесторов Кремниевой долины и почему ее оценивают подобно высокотехнологичным компаниям. Есть ли производство менее похожее на высокую технологию, чем изготовление пружин и ткани для сна? Но Casper действительно высокотехнологичная компания. Технология заключается не в самом продукте, а в том, как компания приобретает клиентов и распространяет свои продукты и в конечном счете обеспечивает качество обслуживания на протяжении всего процесса покупки и использования продукта. Благодаря технологии компания может делать все это с размахом и с минимальными вложениями. Она использует стратегии цифрового взаимодействия для обеспечения невероятно быстрого роста. Всего за пять лет с момента основания Casper довела выручку почти до $500 млн с персоналом менее сотни человек. Разительный контраст с крупнейшей в мире компанией по производству матрасов Tempur Sealy, в которой занято 7000 человек, а доход составляет $2,7 млрд. Подумайте о преимуществах, которые дает технология компании Casper: да, Tempur Sealy имеет доход в пять раз больше, но для этого ей требуется в 70 раз больше сотрудников. Победит ли в конечном счете компания Tempur Sealy своего конкурента Casper в его игре, пока трудно сказать, но их война продолжается.

Подобное происходит в каждой отрасли. Возьмите бритвенные приборы: стартап Harry’s бросает вызов общеизвестному бренду Gillette. В сфере инвестиций стартап Robinhood конкурирует с Fidelity, T. Rowe Price и другими институтами с вековой историей. Компания Opendoor перевернула сферу сделок с недвижимостью, изменив процесс покупки и продажи домов. В одной отрасли за другой цифровые компании используют технологию для вывода на рынок новых продуктов и делают это быстрее, дешевле при более высоком качестве обслуживания.

Можно сказать и по-другому: программное обеспечение превратилось из источника затрат в источник прибыли.

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

Вернемся к матрасам. В ответ на успех Casper фирма Tempur Sealy запустила программу Cocoon by Sealy, которая обеспечивает онлайновое обслуживание клиентов по аналогии с Casper. Получай! Империя наносит ответный удар! А теперь подумай о своем банке. Наверное, он предлагает то же самое, что и любой другой банк. Расчетный счет, сберегательный счет – это высококонкурентная сфера. Так что же отличает один банк от другого? Раньше речь шла о качестве обслуживания в отделении банка. Каким оно было? Сотрудники были хорошо одеты и дружелюбны? Вас угощали печеньем? А вашему ребенку предлагали леденец? Но теперь вы не ходите в офис, а просто открываете приложение. Поэтому банкам нужны совершенно новые навыки – навыки разработки ПО. И они не могут просто купить все эти программы у стороннего поставщика. Конечно, в компаниях, предлагающих программы, необходимые банкам для осуществления цифровой трансформации, нет недостатка. Но если бы банки просто покупали одинаковый софт, все они были бы на одно лицо. В конечном счете они должны ориентироваться на потребности клиентов и реагировать на них, быстро создавая собственное ПО.

Компании, приспособившиеся к новой цифровой реальности, будут лучше обслуживать клиентов и таким образом выживут. Но те, кто этого не сделает, умрут. Возможно, кончина не произойдет в одночасье, но она неизбежна. Да, именно так. Не имеет значения, в какой сфере вы ведете бизнес: банковское обслуживание, авиаперевозки, автомобилестроение, страхование, недвижимость, розничная торговля, здравоохранение… Конечно, необходимо также предоставлять отличный продукт или услугу по конкурентоспособной цене. Но на любом рынке в конечном итоге победит компания, обладающая лучшим программным обеспечением. Джефф Иммельт, бывший генеральный директор General Electric и член совета директоров компании Twilio, однажды сказал своей команде в General Electric: «Если мы не станем лучшей технологической компанией в мире, мы обречены. Мы мертвы. Альтернативы этому нет».

«Это стремление к выживанию», – говорит Вернер Фогельс, легендарный директор по технологиям компании Amazon и один из главных архитекторов сетевых сервисов Amazon, крупнейшей в мире платформы облачных вычислений с десятками дата-центров по всему земному шару. Фогельс – человек очень высокого роста, 198 см, сложенный как полузащитник Национальной футбольной лиги США. Он имеет докторскую степень в области компьютерных наук и провел более десятилетия в университетской среде, прежде чем присоединиться к Amazon.

Сегодня он много ездит по миру и помогает традиционным компаниям адаптироваться к цифровой реальности и выжить. Он также играет главную роль в видеосериале под названием «А теперь создавай» (Now Go Build), который Amazon создала в честь компаний, разрабатывающих программное обеспечение. Помощь клиентам идет на пользу самой Amazon. «Наше облако было бы бесполезно, если бы люди не знали, как им пользоваться. Мы должны помогать им с организационными и культурными преобразованиями, а затем показывать, как принять новую технологию», – говорит Фогельс. Большинство компаний приняли облачные вычисления, но им непросто стать организациями, ориентированными на программное обеспечение. «Это самый часто задаваемый вопрос, – утверждает Фогельс. – Клиенты спрашивают нас: “Как нам это сделать?” Они действительно пытаются учиться у таких компаний, как Amazon».

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

Еще одна проблема – скорость. Цифровые компании могут превратить отличную идею в работающий код за считаные недели или даже дни. Они ежедневно представляют новые версии программ. Чтобы идти в ногу с технологиями, традиционным компаниям необходимо ускориться. «Вы больше не можете позволить себе тратить шесть или 12 месяцев на разработку программ перед их запуском», – утверждает Фогельс. Не верите? Спросите у Blockbuster. Спросите у Borders. Спросите у Nokia. Спросите у Yellow Taxi. Эти компании стали жертвами цифровой революции, потому что не успели достаточно быстро адаптироваться к новой реальности.

Как мыслят разработчики программного обеспечения

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

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

Если вдуматься, то компьютер – это машина, выполняющая математические вычисления, с набором подключенных датчиков (входов) и исполнительных механизмов (выходов). Датчики и исполнительные механизмы – единственный способ узнать, что происходит внутри машины, и на историю компьютеров вполне можно смотреть как на непрерывное усложнение датчиков и исполнительных механизмов, которые позволяют нам «вычислять» все в большем и большем масштабе. Первые два десятилетия вычислительной техники, 1950-е и 1960-е гг., были связаны с математическими вычислениями, и мы применяли перфокарты для ввода и вывода цифровых данных. Программы обрабатывали именно эти цифровые данные. Компьютеры использовались практически только для расчета траекторий ракет и государственного долга. В 1960 г. в мире существовало всего несколько тысяч компьютеров. Но после усовершенствования датчиков и исполнительных механизмов появилась возможность вводить в компьютеры текст и применять программное обеспечение к текстовым задачам. В следующие два десятилетия обрабатывались уже тексты, а не только числовые данные. Появление клавиатур и принтеров в 1970-е и 1980-е гг. открыло дорогу текстовым редакторам, настольным издательским системам и электронным таблицам, и персональный компьютер стал атрибутом каждого рабочего места. Прогресс в сфере датчиков и исполнительных механизмов затем позволил оцифровывать аудио- и видеоинформацию. Компьютеры получили сложные графические и звуковые карты, а 1990-е и 2000-е стали годами мультимедиа – они принесли нам звуковые файлы в формате MP3, компьютерные игры и возможность реализации спецэффектов в таких фильмах, как «Парк юрского периода». Сегодня, имея в кармане постоянно включенные смартфоны, мы несем с собой массу датчиков и исполнительных механизмов, постоянно подключенных к интернету, что превращает весь остальной мир в сферу программного обеспечения. Таким образом, 2010-е и 2020-е гг. связаны с вычислениями практически всего сущего. Именно это сделало последнее десятилетие (и сделает следующее десятилетие) таким захватывающим. Набор проблем, к которым можно применить программный образ мышления, растет взрывными темпами.

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

Вспомните, что компания Apple сделала с пультом дистанционного управления телевизора. До того как Apple выпустила медиаплеер Apple TV, приставки снабжались пультом дистанционного управления с чуть ли не сотней кнопок. Некоторые компании даже хвастались в рекламе количеством кнопок. Рядом с каждой кнопкой была надпись «Громкость больше/меньше», «Номер канала больше/меньше», «Избранное», «Картинка в картинке», «Источник сигнала», «Меню» и т. д. Первый пульт Apple TV имел всего семь кнопок. Почему? Потому что все функции медиаплеера Apple TV были заложены в программное обеспечение данного устройства. Это давало Apple возможность учиться у клиентов и постоянно дополнять программное обеспечение новыми функциями. Разработчики не могут улучшать то, что отлито в пластике и металле, – после выпуска изделия с завода его функциональность остается неизменной. Так что решение убрать кнопки с пульта не только эстетично, но и отражает стратегию развития высоких технологий. Когда я впервые увидел минималистичный пульт Apple TV, то подумал: «О, это уже игра на уровне программного обеспечения».

Тот же образ мышления Стив Джобс применил при разработке iPhone в 2007 г. Он высмеивал телефоны с физической клавиатурой, поскольку, по его замечанию, такая клавиатура всегда была на месте независимо от того, нужна она или нет. Такую клавиатуру нельзя обновить, на ней невозможно изменить язык, и, конечно, ее нельзя убрать, когда она не нужна. Физическая клавиатура и зашитый на заводе язык навечно оставались с устройством. Клавиатура iPhone – это программное обеспечение. Она исчезает, когда не нужна, т. е. ее не видно большую часть времени. При необходимости ее можно переключить на эмодзи или другой язык, если вы полиглот. Это означает, что Apple может поставлять одно устройство во все страны мира. Нужный язык – это просто программное обеспечение, а не то, что зашивается только на заводе-изготовителе.

Другой пример – считыватель кредитных карт Square. Традиционные устройства для работы с кредитными картами – солидные конструкции с экраном как у калькулятора для научных расчетов из 1990-х гг. и клавиатурой. Когда появляется новый метод оплаты или экраны с разрешением более чем в сотню пикселей, то подобное устройство приходится менять. Ведь все, что мог делать традиционный считыватель, зашивалось на заводе в пластик и кремний. Считыватель Square – это всего лишь небольшой интерфейс, необходимый для связи физического мира (считывателя магнитной полосы) с миром программного обеспечения. Все остальное делает программное обеспечение, которое компания Square может обновлять еженедельно. Программное обеспечение становится совершеннее с каждой версией – оно получает новые функции, а ошибки в нем исправляются. Считыватель Square может улучшаться и обучаться так же быстро, как и программные средства, потому что его разработчики вложили в программное обеспечение абсолютно все, оставив только минимальную пластиковую конструкцию, необходимую для выполнения работы. С приходом бесконтактных платежей исчезает все большее число физических элементов. Чем меньше вокруг аппаратных средств, тем больше делают программы.

Еще один пример – электромобили Tesla. У обычного автомобиля на приборной панели десятки кнопок. У большинства электромобилей Tesla всего четыре кнопки и два колесика прокрутки на рулевом колесе. Все остальное – это программное обеспечение, работа которого отображается на гигантском экране. На кнопках Tesla даже нет надписей. Это значит, что все можно рассматривать как программное обеспечение, которое обновляется по мере того, как компания Tesla получает отзывы клиентов. Обновляется не только информационно-развлекательная система электромобиля (туда, например, добавили функцию караоке и YouTube), но и важные функции безопасности.

В октябре 2013 г. один владелец Tesla S наехал на камень, который повредил аккумулятор, что вызвало пожар. Система безопасности предупредила водителя о возникшей проблеме, он благополучно съехал на обочину и вышел из машины за несколько минут до того, как пламя охватило электромобиль. Но для компании Tesla это была PR-катастрофа. Чтобы сделать автомобиль безопаснее, конструкторы Tesla решили увеличить клиренс электромобиля на один дюйм при выходе на высокую скорость. В большинстве компаний это потребовало бы отзыва автомобилей, что обошлось бы производителю в десятки или сотни миллионов долларов и создало бы неудобства для владельцев машин. Но Tesla всего лишь произвела рассылку обновления, изменившего параметры подвески электромобиля, и проблема была решена. Вот так работает программное мышление.

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