Текст книги "WTF? Гид по бизнес-моделям будущего"

Глава 6. Мыслить в перспективе

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

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

• Партнерская архитектура означает, что ваши пользователи помогают развитию вашей платформы.

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

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

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

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

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

За этим следовал слайд под названием «Урок истории», концовка которого такова: «Стратегия платформы всегда одерживает победу над стратегией приложения!»

Платформа всегда одерживает победу над приложением

Джефф Безос, услышав эту речь на конференции по новым технологиям (Etech), в 2003 году попросил меня выступить с ней перед небольшой группой разработчиков Amazon.

Ранее, в марте 2001 года, во время своей поездки в Сиэтл я подбросил Джеффу идею о том, что компании Amazon следовало бы предлагать доступ к своим данным через веб-службы.

В целях исследования рынка компания O’Reilly делала запрос по Amazon через глобальный поиск по сети каждые три часа, чтобы загружать информацию о ценах, рейтинге, количестве страниц и рецензиях на наши книги и книги наших конкурентов. Глобальный поиск по сети казался мне нерациональным, поскольку нам приходилось загружать гораздо больше данных, чем требовалось, а затем извлекать только нужные биты информации. Я был убежден, что огромный каталог товаров Amazon был прекрасным примером обширного набора данных, к которому следует предоставить доступ – в программном отношении через веб-сервисы API в «операционной системе Интернета» следующего поколения, которую я проповедовал.

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

Я как сейчас помню разочарование Джеффа по поводу моей речи на этой внутренней конференции разработчиков Amazon. Когда я закончил, он вскочил с задних рядов зала и сказал: «Вы не сказали ни слова о том, что платформа всегда одерживает победу над приложением!» Но я не ошибся, когда произнес другую версию своей речи на всеобщем собрании Amazon в мае 2003 года.

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

Благодаря своей великолепной стратегии принимать любую идею и как следует ее обдумывать, Джефф продвинул идею платформы намного дальше, чем я себе представлял. Как поведал Джефф в коротком интервью Ому Малику в 2008 году: «Когда все это началось четыре года назад, у нас было довольно много сложностей внутри компании Amazon. Мы поняли, что тратим слишком много времени на точечную координацию действий между нашими группами сетевой технологии и группами прикладного программирования. По сути, то, что мы решили сделать, – это создать набор API-интерфейсов между этими двумя уровнями, чтобы можно было выполнять более общую координацию между этими двумя группами» (то есть это были «свободно соединенные мелкие частички»).

Что важно: веб-службы компании Amazon были созданы как решение проблемы организационной структуры. Джефф понял то, что должен понять каждый сетевой бизнесмен XXI века. Это то, что однажды сказал мне HR-эксперт Джош Берсин: «Производить цифровые технологии – это не то же самое, что быть цифровыми технологиями».

В эпоху цифровых технологий онлайн-сервис и организация, которая его предоставляет и им управляет, должны стать единым целым.

То, как Джефф перенес представление об Amazon как о платформе из сферы программного обеспечения в организационную структуру, нужно преподавать в каждой бизнес-школе. Об этом рассказал бывший инженер Amazon Стив Йегге в статье, написанной для своих коллег из Google, которая была случайно обнародована и стала вирусной среди интернет-разработчиков. Она известна как «Тирада Стива о платформе». В ней Йегге ссылается на записку, которую, как он утверждает, Джефф Безос написал «примерно в 2002 году, я думаю, плюс-минус год»:

«Его «Большой приказ» был изложен примерно в таком духе:

1. Отныне все команды будут обнародовать свои данные и функциональные возможности через служебные интерфейсы.

2. Команды должны общаться друг с другом через эти интерфейсы.

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

4. Не имеет значения, какую технологию они используют. HTTP, Corba, Pubsub, собственные протоколы – не важно. Безосу нет до этого дела.

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

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

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

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

Microsoft, Google и многие другие бежали наперегонки к облачной обработке данных, но они опоздали к игре. У Amazon было одно большое преимущество, которое Джефф разъяснил мне вскоре после того, как в 2006 году предложения по облачной обработке данных Amazon были официально представлены публике: «Я начал бизнес в качестве розничного торговца. Это бизнес с очень низким коэффициентом прибыльности. Для меня хуже бы не стало. Прибыль Microsoft и Google очень высокая. Им было что терять». К тому времени, когда Microsoft и Google поняли, насколько серьезным может стать бизнес по облачной обработке данных, они остались далеко позади.

Программное обеспечение как организационная структура

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

Работа ведется силами небольших команд (Amazon в шутку называет их «команды двух пицц», то есть команды настолько маленькие, что их можно накормить двумя пиццами). Эти команды работают независимо, начиная с высокоуровневого описания того, чего они пытаются достичь. Любой проект в Amazon разработан по принципу работы «наоборот». То есть компания, известная своей клиентоориентированностью, начинает работу с выпуска пресс-релиза, в котором описывается, для чего и зачем нужен готовый продукт. (Если это внутренняя услуга или товар, в роли «клиента» может выступать другая внутренняя группа.)

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

Это является примером того, что теоретик в области компьютерных технологий и менеджмента Марк Берджесс назвал «перспективным мышлением». Он писал: «Если взять поваренную книгу, каждая страница обычно начинается с обещания того, как будет выглядеть конечный результат (в виде соблазнительной картинки), а затем предлагается рецепт его создания. Книга не просто дает вам рецепт, заставляя вслепую проделать все шаги, чтобы затем увидеть результат. Сначала в ней показывается, чего следует ожидать. В программировании и в управлении мы не всегда столь предупредительны».

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

Однажды на выездном заседании Amazon Джефф Безос дал знаменитый ответ на предложение о необходимости улучшения связи между командами компании: «Нет, общение – это ужасно!» Причину объяснил на примере старого анекдота: «Один человек сидит и пьет. Два человека чокаются и пьют. Чем больше к ним присоединяется людей, тем больше показатель чоканий и выпитого». Лучше, когда люди «чокаются» только с людьми, делающими совместную с ними работу, а не вообще со всеми. Это простая математика. Общение становится менее конструктивным по мере увеличения размера команды.

В этом есть парадокс. Джефф действительно настаивал на более эффективной, более тесной связи внутри команд в сочетании с четко определенной связью между командами, копируя четко структурированное сообщение, позволяющее современным интернет-приложениям работать столь хорошо. Он приводил аргументы против внерабочего общения, которое порождало спонтанные решения, со временем ломающиеся под собственным весом. Именно благодаря этому контексту вы также можете понять, почему Джефф запретил PowerPoint и настоял на том, чтобы все предложения и связанные с ними презентации были сделаны в виде записок от руки. В зависимости от того, подчеркивал Берджесс, как независимые субъекты дают друг другу обещания, можно понять, в чем состоит суть этой четко структурированной коммуникации. Этими субъектами могут быть программные модули, обещающие определенным образом реагировать на вызовы API, или небольшие команды, обещающие достигнуть конкретного результата. Берджесс пишет: «Представьте себе набор правил, который может помочь вам понять, как части соединяются в целое и как каждая часть видит целое со своей собственной позиции. Если подобные правила приносят хоть какую-то пользу, то не имеет значения, говорим мы о людях в команде, о птицах в стае, компьютерах в центре обработки данных или о шестеренках в швейцарских часах. Теория сотрудничества должна быть достаточно универсальной, поэтому мы можем применять ее как к технологии, так и к трудовой деятельности».

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

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

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

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

Этот подход также стал сутью революции в сфере военных действий, совершенной генералом Стэнли Маккристалом в Афганистане в качестве реакции на стремительно меняющуюся там обстановку. Я слышал, как летом 2016 года в своем выступлении на саммите газеты «Нью-Йорк таймс», посвященном новым направлениям деятельности, генерал Маккристал сказал: «Я говорю людям: «Не следуйте моим приказам. Следуйте указаниям, которые я дал бы вам, если б находился там и знал то, что знаете вы». То есть осознайте нашу общую цель и используйте наиболее конструктивный способ ее достижения.

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

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

Высокая автономность также обеспечивает возможность разрешения непредвиденных конфликтов между отдельными командами. В своей книге «Amazon Way» бывший вице-президент Amazon Джон Россман описывает, как компания переняла идею японского бережливого производства «Андон». Любой сотрудник, столкнувшийся с проблемой на сборочной линии на заводе Toyota, может потянуть шнур, который останавливает производственный процесс и зажигает большое информационное табло («Андон»), чтобы привлечь внимание руководства. Аналог шнура «Андон» был внедрен в компании Amazon, и Россман пишет: «Когда клиенты начинали жаловаться на проблему, связанную с товаром, отдел обслуживания клиентов просто убирал этот товар с веб-сайта и отправлял сообщение в отдел розничной торговли: «Исправьте брак, или вы не сможете продавать этот товар».

«Компания Amazon решила внедрить свою версию шнура «Андон» после случая, произошедшего с Джеффом во время участия в программе «Customer Connection» (один из механизмов, используемых Amazon, чтобы конкретизировать желания клиентов)», – рассказала мне Ким Рахмелер. На тот момент каждый менеджер седьмого уровня или выше, включая Джеффа, каждые два года должен был какое-то время поработать в отделе обслуживания клиентов. В рамках этой программы компания Amazon включала руководителей в команду службы поддержки и просила их ответить на несколько телефонных звонков.

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

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

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

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

Майки Дикерсон, один из инженеров компании Google, приглашенный осенью 2013 года на работу в Белый дом для спасения провального веб-сайта healthcare.gov и ставший позднее руководителем цифровых сервисов США, рассказал мне историю о значении стендап-митингов, которые он проводил в течение ста дней, чтобы связать государственных подрядчиков, построивших неудачный сайт, в единую функционирующую организацию, способную заставить сайт реально работать. Это происходило примерно так:

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

Только потом «Джо» и «Майк», которые работали на разных подрядчиков (более тридцати трех компаний, участвовавших в разработке первой версии healthcare.gov, работали по шестидесяти различным контрактам), обнаружили, что они пользуются разными системами отслеживания возникающих проблем. Запросы от команд на выполнение работы другими командами уходили буквально в никуда. Поскольку каждый находился в неявной зависимости от всех остальных, работа не могла сдвинуться с мертвой точки, так как каждый ожидал результатов от всех остальных, прежде чем мог продолжить действовать.

Не важно, при помощи веб-служб и API-интерфейсов или посредством таких инструментов, как системы отслеживания возникающих проблем, ориентированная на перспективу модель работает над повышением автономии, поскольку каждый автономный субъект дает документально подтвержденные обещания и несет за них ответственность.

Вы все находитесь внутри приложения

Процесс превращения разработки ПО из модели, целью которой было изготовление артефакта (скажем, GM-версии следующего выпуска Microsoft Windows, которая была результатом многолетних разработок и которую необходимо было записать на миллионы компакт-дисков и в тот же день передать в десятки тысяч предприятий розничной торговли и корпоративным клиентам), в модель, в которой разработка ПО была постоянно совершенствующимся процессом, также являлся процессом организационного открытия.

Я до сих пор помню удивление, с которым Марк Лусавски, бывший старший технический руководитель проекта в Microsoft, рассказывал о том, как изменился процесс его работы, когда он перешел в Google. «Я вношу изменения и сразу же, в режиме реального времени, предоставляю их в пользование миллионам людей». Марк описывал глубокие преобразования, произошедшие в разработке программного обеспечения в облачную эпоху. GM-версий больше нет. Сегодня программное обеспечение стало процессом постоянных, более или менее постепенных улучшений. С точки зрения компании, предлагающей онлайн-услугу, программное обеспечение превратилось из вещи в процесс и в конечном счете в серию бизнес-процессов. Структура этих рабочих процессов должна быть оптимизирована не только для разработчиков программного обеспечения, но и для людей, которые будут пользоваться ими изо дня в день.

Основная идея заключается в том, что компания теперь представляет собой гибридный организм, состоящий из людей и машин. Я также отметил это в своем выступлении на общем собрании Amazon в 2003 году. Я рассказал историю о шахматном автомате Вольфганга фон Кемпелена «Механический турок», который возили по Европе в конце XVIII и в начале XIX века, удивляя (и побеждая) таких светил, как Наполеон и Бенджамин Франклин. Внутри так называемого автоматического устройства на самом деле был спрятан сильный шахматист, у которого был набор линз, чтобы видеть доску, и набор рычагов, чтобы управлять руками манекена-«турка». Я думаю, это была чудесная метафора для нового поколения веб-приложений.

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

В течение долгого времени я задавался вопросом, мог ли тот мой рассказ вдохновить Amazon на создание площадки Amazon Mechanical Turk, использующей коллективный труд сети работников для выполнения небольших задач, которые являются трудновыполнимыми для компьютеров. Впрочем, хоть сервис и был запущен в 2005 году, заявка на его патент была подана в 2001 году. Правда, он был выдан только в 2007-м, поэтому в лучшем случае я мог вдохновить на название.

Моя идея о том, что в Интернете программисты находятся «внутри приложения», развивалась постепенно. Впервые она пришла мне в голову, когда я пытался понять, почему язык программирования Perl стал таким важным в первые дни Интернета.

Мне особенно запомнился один разговор. Я спросил Джеффри Фридла, автора книги «Регулярные выражения» (издательство «Символ-Плюс», 2008 г. – Прим. ред.), которую наше издательство опубликовало в 1997 году, что же такое он сделал с Perl на своей основной работе в Yahoo!. «Целыми днями я писал регулярные выражения, чтобы они соответствовали новым историям с тикерными символами, а мы могли показывать их на соответствующих страницах finance.yahoo.com», – ответил он. (Регулярные выражения похожи на подстановочные знаки на стероидах – функция языка программирования, которая позволяет сопоставлять любую строку текста, что для непосвященных кажется магическим заклинанием.) Мне сразу стало ясно, что сам Джеффри был такой же частью finance.yahoo.com, как и написанные им скрипты Perl, потому что он не мог просто один раз написать их и уйти. Поскольку веб-сайт пытался отразить динамичный характер контента, ему нужно было каждый день изменять свои программы.

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

Но только в 2006 году, когда такие компании, как Amazon и Microsoft, начали понимать возможности облачных вычислений, этот еще один важный элемент оказался в центре внимания. Я беседовал с Деброй Храпаты, которая была в то время вице-президентом по оперативной деятельности компании Microsoft Network. Ее проницательный комментарий полностью отражал перемены: «В будущем быть разработчиком на чьей-либо платформе будет означать обосноваться в их инфраструктуре». В качестве примера она рассказала о конкурентном преимуществе, которое она создавала, размещая свои центры обработки данных там, где энергия была дешевой.

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

В следующем году Джесси, Стив Саудерс из компании Yahoo! Энди Орам из O’Reilly Media и Артур Бергман, главный технический директор Wikia, попросили меня о встрече. «Нам нужна площадка, где наша компания могла бы собраться вместе», – сказал мне Джесси. Я с радостью согласился. Мы организовали саммит с лидерами зарождающейся области обслуживания веб-сайтов и вскоре после этого организовали конференцию Velocity для растущего числа профессионалов, работавших за кулисами, заставляя интернет-сайты работать быстрее и эффективнее. На конференции Velocity собралось сообщество, работающее над новой дисциплиной, получившей название DevOps, акроним от англ. development и operations – «разработка и обслуживание программного обеспечения». (Этот термин был придуман через несколько месяцев после первой конференции Velocity Патриком Дебуа и Эндрю «Клей» Шафером, которые провели серию встреч под названием «Дни DevOps» в Бельгии.)

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