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

Глава 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 в 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 продает свои вычислительные мощности.

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