WTF? Гид по бизнес-моделям будущего О’Рейли Тим
Этот принцип является ключом к пониманию не только успеха современных гигантов интернет-технологий, но и того, что не так с современной 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. Исторически сложились две отдельные команды, отвечающие за техническую инфраструктуру современных веб-приложений: разработчики, которые создают программное обеспечение, и специалисты по информационно-технологическому обслуживанию, которые управляют серверами и сетевой инфраструктурой. И эти две команды обычно не общались друг с другом, что приводило к непредвиденным проблемам, как только программное обеспечение приобретало действительно широкий масштаб.
DevOps – это способ увидеть весь жизненный цикл программного обеспечения, аналогично процессу «бережливого производства», которое определила для себя корпорация Toyota. DevOps берет жизненный цикл программного обеспечения и процесс работы интернет-приложения и превращает их в процесс работы организации, измеряя показатели, находя слабые места и определяя необходимые средства связи.
В дополнении к учебному пособию по DevOps, написанному в виде романа «Проект Феникс» Джином Кимом, Кевином Бером и Джорджем Спаффордом (изд. «Эксмо», 2015 г. – Прим. ред.), воздавшему дань уважения знаменитому роману о принципах бережливого производства «Цель» (очевидно, речь о книге Э. М. Голдратт и Дж. Кокс, Альпина Паблишер, 2014 г. – Прим. ред.), Джин Ким отмечает, что скорость является одним из ключевых конкурентных преимуществ, которые дает организации DevOps. Обычное предприятие может выпускать новое программное обеспечение раз в девять месяцев, а период его освоения может занять от одного до трех месяцев. В таких компаниях, как Amazon и Google, выпускаются тысячи крошечных обновлений, а время их освоения измеряется в минутах. Многие из этих обновлений обладают экспериментальными функциями, которые можно отыграть назад или изменить.
Возможность вернуть что-то на предыдущий уровень с легкостью превращает неудачу в нечто незначительное и стимулирует к принятию решений работников организации, находящихся на более низких должностях.
Большая часть этой работы полностью автоматизирована. Хал Вариан называет это «компьютерным кайдзеном», ссылаясь на японский термин, обозначающий непрерывное совершенствование. «Точно так же как массовое производство изменило метод сборки продукции, непрерывное совершенствование изменило то, как осуществляется производство, – пишет он, – непрерывное экспериментирование… улучшает оптимизацию бизнес-процессов в наших организациях».
Но DevOps также обеспечивает более высокую надежность и более оперативное обслуживание клиентов. Джин Ким так характеризует процессы, происходящие в высокоэффективной организации, использующей DevOps: «Вышестоящие группы развития, вместо того чтобы вызывать хаос в нижестоящих рабочих центрах (например, в службе по обеспечению контроля качества, информационно-технической службе и службе информационной безопасности), тратят 20 процентов своего времени на то, чтобы убедиться, что рабочий процесс протекает плавно на всем потоке создания ценности, на ускорение автоматизированных тестов, улучшение развития инфраструктуры и на то, чтобы убедиться, что все приложения создают телеметрию эффективного производства». Он повторяет, что это не просто техническая, а организационная практика: «Все участники потока создания ценности объединены общей культурой, в которой не только ценится чужое время и вклад в работу, но в которой также неустанно нагнетается давление в рабочую систему для обеспечения организационного обучения и совершенствования».
Практики DevOps продолжают эволюционировать. Google называет свою версию дисциплины «Site Reliability Engineering» (SRE) – инженерно-техническое обеспечение надежности сайта. Как объяснил создатель этого термина Бенджамин Трейнор Слосс: «SRE в основном выполняет работу, которая исторически осуществлялась оперативной группой, но с привлечением инженеров с опытом работы с программным обеспечением, полагаясь на тот факт, что эти инженеры изначально предрасположены и способны и к разработке, и к внедрению автоматизации в программное обеспечение для замены человеческого труда».
Он отмечает, что традиционная оперативная группа должна расти в соответствии с оборотом поддерживаемых ею служб: «Без непрерывного проектирования увеличивается оперативная нагрузка и командам требуется больше людей, чтобы справиться с объемами работ». В противоположность этому, в концепции SRE, люди «внутри» машинного процесса, поддерживающие его работу, увеличивают производительность, постоянно, по нарастающей обучая машины делать то, что делают они сами.
Таким образом, то, что мы видим в современной сетевой организации, – это не просто радикальное изменение внешних отношений между компанией, ее поставщиками и ее клиентами, но и радикальное изменение того, как организована работа сотрудников внутри нее самой и как они работают в тандеме с программным обеспечением и с машинами, которые они создают и которыми они управляют.
Поскольку принципы интернет-приложений и услуг проникают в реальный мир, каждая компания должна трансформироваться, чтобы воспользоваться преимуществами новых технологий, появившихся в цифровой сфере. Это не минутное дело, а непрерывный процесс. На том всеобщем собрании Amazon в 2003 году, которое длилось целый день, Джефф Безос выступил с вступительной речью. Она называлась «Это все еще день первый». Он описал историю электричества, продемонстрировав яркие исторические фотографии пучков проводов, торчащих из осветительных штепсельных розеток в потолке, смонтированных для питания новых видов электроприборов. Стандартизированный разъем электропитания еще не был изобретен. Он показал, как фабрики на своих сборочных линиях все еще использовали механизмы с огромными двигателями, приводящимися в движение при помощи ремней и шкивов, так же как и в эпоху паровых машин, еще не осознавали, что можно подвести электричество непосредственно к маленьким двигателям, где в действительности происходит работа.
Зачастую, когда впервые внедряется новая технология, она усиливает худшие черты старого способа ведения бизнеса. Только со временем, благодаря каскадной сети инноваций, люди и организации понимают, как правильно использовать новую технологию.
Джефф был прав. Это все еще день первый, даже сейчас. Но поиск возможностей будущего – это задача не только изобретателей программного обеспечения или машин. В этом состоит задача каждого бизнеса – спросить себя, какие возможности сегодня предоставляет технология, не только для их клиентов, но и для организации самого бизнеса. В этом же состоит задача других учреждений, таких как правительство.
Глава 7. Правительство как платформа
Моя увлеченность идеей связать воедино правительство и технологии началась с истории моего друга Карла Маламуда, бессменного защитника технологий в интересах общества. В 1993 году, на заре появления Всемирной паутины, Карл помогал компании Sun Microsystems продемонстрировать возможности Интернета в подкомитете палаты представителей по телекоммуникациям и финансам. После демонстрации представитель председателя подкомитета Эдвард Дж. Марки (ныне американский сенатор от штата Массачусетс) сказал Карлу, что его подкомитет также контролирует Комиссию по ценным бумагам и биржам (КЦББ). Джейми Лав, который работал с Ральфом Найдером над вопросами, связанными с использованием Интернета, отправлял в подкомитет петиции, в которых спрашивал, почему отчетная документация КЦББ недоступна в Интернете.
Представитель Марки озвучил Карлу первоначальную реакцию КЦББ, которая заключалась в том, что данных не было в Интернете потому, что обеспечить к ним доступ представляется невозможным. Как красочно прокомментировал Карл этот ответ, «даже если бы данные стали доступными, единственными людьми, кто был бы заинтересован в отчетной документации КЦББ, были бы толстосумы с Уолл-стрит, а им на самом деле был не нужен субсидируемый доступ к данным, за которые они готовы были заплатить».
«Меня всегда привлекало то, что технически невозможно», – писал Карл. Поэтому он встретился с представителями КЦББ и представителями председателя Марки. КЦББ хотела знать, почему, ради всего святого, люди хотели бы видеть данные в базе EDGAR (база данных ежеквартальных и ежегодных отчетов американских государственных корпораций). «Я утверждал, что в Интернете полно людей – студентов, журналистов, инвесторов из числа пожилых граждан, которые до смерти хотели бы получить доступ к этим данным. В КЦББ считали, что лишь немногие захотят увидеть отчеты в базе EDGAR, и к тому же в Интернете «отсутствовал правильный тип людей».
«Да, это был запрещенный прием, и я понимал, что они имели в виду под фразой «интересуется не так много людей, всего несколько исследователей», но я не мог удержаться. «Правильный тип людей? – воскликнул я, вскакивая с кресла. – Я думаю, что американский народ – это правильный тип людей».
Так зародилось движение открытости государственных данных.
Карл получил небольшой грант Национального научного фонда, который он в основном потратил на оплату лицензионного сбора, который взимали «спекулянты» из КЦББ за предоставление своих данных банкам Уолл-стрит. Эрик Шмидт, занимавший тогда пост главного технического директора компании Sun Microsystems, безвозмездно предоставил пару серверов. Карл и его партнер Брэд Бердик отформатировали данные, создали сайт, а в январе 1994 года выложили бесплатную версию системы базы данных EDGAR КЦББ в Интернет.
Карл был энтузиастом, а не предпринимателем. «Наша цель заключалась не в том, чтобы создать бизнес в сфере баз данных, – писал он. – Наша цель состояла в том, чтобы КЦББ хранила свои собственные данные в Интернете». После восемнадцати месяцев работы системы Карл объявил, что через шестьдесят дней служба будет закрыта, если не перейдет под руководство КЦББ. В подтверждение слов Карла в КЦББ написали пятнадцать тысяч человек. Мировоззрение изменилось, и КЦББ согласилась взять сайт под свое руководство.
Со временем, когда спрос со стороны общественности на предоставление финансовых отчетов компаний уже не подлежал обсуждению, предприниматели начали создавать улучшенные версии. Такие сервисы, как Yahoo! Finance и Google Finance, которые обеспечивают публичный доступ к данным отчетов КЦББ, являются прямыми наследниками той работы, которую провел Карл в 1993 году. С тех пор он продолжает вести активную деятельность. Его нынешняя задача состоит в том, чтобы составить полный текст всех законов, правил и стандартов, ссылки на которые содержатся в этих законах, и выложить его в свободный доступ в Интернете.
В 2005 году мой интерес к урокам, которыми Кремниевая долина могла бы поделиться с правительством, вновь вышел на первый план. Компания Amazon еще не свершила революцию в индустрии, запустив свою платформу облачных сервисов, но ценность Интернета как платформы и характер этой платформы становились для меня все более понятными. Я убедился, что интернет-платформой следующего поколения будет платформа данных, и я заметил, что источником многих этих данных является правительство. Работа, которую Карл Маламуд начал десять лет назад, была лишь первым шагом. Карты Google, чей интерактивный интерфейс JavaScript (Ajax) был одной из WTF-технологий 2005 года, как и все сервисы онлайн-карт, были созданы с использованием базовых карт, лицензированных правительством. И когда хакеры поняли, что они могут делать мэшапы, размещая другие данные на картах Google, первым местом, куда они направили свои взоры, были правительственные данные. Сайт Эйдриана Холовати chicagocrime.org (теперь EveryBlock), который добавил на карту Google данные о преступлениях в городе Чикаго, стал вторым из созданных мэшапов.
Карты Google отлично вписываются в мое понимание Web 2.0. Я был убежден, что в отличие от операционных систем, таких как Windows и Mac OS X или Linux, чьи подсистемы управляют доступом к аппаратным подсистемам компьютера или сети, операционная система Интернета будет управлять доступом к подсистемам данных, предоставляющим такие сервисы, как подтверждение личности кого-либо или определение его местоположения. Я был уверен, что если бы эти подсистемы можно было сделать легкодоступными для разработчиков, то произошел бы стремительный рост инноваций. Я был настолько убежден в этом, что организовал мероприятие, посвященное сервисам, работающим на основе определения местоположения, под названием Where 2.0. Идеально продемонстрировав, как в нужный момент «поймать волну», Google связался со мной за две-три недели до мероприятия, чтобы спросить, могу ли я включить их в программу.
Выход приложения Google Maps еще не был анонсирован, и они появились как раз вовремя, чтобы его официальная презентация стала центральным событием этого мероприятия.
Хотя технически приложения могли строиться поверх других онлайновых картографических сервисов, таких как MapQuest, Yahoo Maps и Microsoft Maps, разработчики должны были обращаться за разрешением и оплачивать лицензионный сбор. Мой опыт работы с открытым программным обеспечением научил меня, что в складывающейся ситуации в сфере картографических услуг будет гораздо больше инноваций и они найдут гораздо более широкое применение, если эти барьеры для входа будут сняты, таким образом разработчики смогут свободно творить. Поэтому я позвонил в компанию Microsoft и MapQuest (в то время принадлежащую AOL) в попытке убедить их открыть доступ к их API, но безуспешно. Вместо этого они закрылись от хакеров, объявив их «пиратами».
Но компания Google поняла мою логику. Когда независимый разработчик Пол Радемахер расшифровал формат данных Google Maps, он понял, что может создавать новые пользовательские карты, объединяя данные из нескольких источников. Он построил сайт под названием housingmaps.com, который показал списки квартир из Craigslist на карте Google, и компания Google увидела в этом новые возможности. Вместо того чтобы заблокировать взлом Пола, они отпраздновали это событие. Они взяли его на работу и открыли доступ к API, чтобы упростить создание мэшапа. Это был трансформационный прорыв, следствием которого стало доминирование Google в онлайн-картографии. Поскольку все больше и больше разработчиков создавали приложения для Google Maps, платформа стала более мощной и привлекла больше пользователей. Она превратилась в классический широкий рынок, куда пользователи приходили ради приложений, а приложения появлялись ради пользователей.
Хакеры открыли компаниям истинную силу платформ. Когда в июне 2007 года компания Apple представила iPhone, события стали разворачиваться по тому же сценарию. Сегодня магазин приложений App Store является настолько важным для нашего смартфона, что легко забыть, что в первом iPhone его не было. У первого варианта был революционный, красивый мультисенсорный интерфейс и встроенный музыкальный проигрыватель iTunes, который также был подключен к iPod, но, как во многих других телефонах, в нем содержалось ограниченное количество приложений. Однако в течение нескольких дней хакеры нашли лазейку в ограничениях, введенных компанией Apple, и добавили свои собственные приложения, процесс, известный как «джейлбрейк» (от англ. jailbreak – «побег из тюрьмы», освобождение вашего телефона из тюрьмы приложений). В июле 2008 года в ответ на набирающее обороты движение «джейлбрейк» компания Apple представила App Store как официальный механизм, позволяющий разработчикам добавлять приложения в телефон, и мир смартфонов, такой, каким мы его знаем сейчас, начал стремительно развиваться. Сегодня существует более двух миллионов приложений для iPhone, и они были загружены 130 миллиардов раз. Разработчики приложений заработали почти 50 миллиардов долларов.
Магазин приложений App Store для iPhone был запущен в июле 2008 года. В ноябре того же года Барак Обама был избран президентом и стал широко известен как «первый интернет-президент» из-за того, что он с успехом использовал Интернет во время своей предвыборной кампании. Я участвовал в мозговом штурме с Эриком Форо, чья компания TechWeb была задействована в подготовке саммита Web 2.0 совместно с компанией O’Reilly Media и Джоном Баттелом. Я считал, что мы должны попытаться привлечь новаторов из правительства к нашим мероприятиям, чтобы выяснить, сможет ли новая администрация оправдать ожидания от первого интернет-президентства; вместо этого Эрик предложил создать для них специальную версию этого мероприятия. Что мы и сделали, организовав саммит Gov 2.0 и выставку Gov 2.0 в Вашингтоне в 2009 и 2010 годах. Дженнифер Палка, на которой я теперь женат, стала генеральным менеджером проекта TechWeb и одним из важнейших участников мозгового штурма.
Когда я начал разрабатывать контент для нового саммита Gov 2.0, один из своих первых визитов я нанес Эрику Шмидту, в то время занимавшему пост генерального директора компании Google, которого я знал с тех пор, как мы работали с Карлом Маламудом в далеком 1993 году. Я знал, что Эрик провел много времени в Вашингтоне, и думал, что он может дать хорошие советы. Что он и сделал. Но это был не тот набор рекомендаций, который я ожидал. «Поезжай в округ Колумбия, – сказал он. – Пообщайся с людьми и скажи нам, что ты об этом думаешь. У тебя это хорошо получается. Это твоя работа».
Мысль о том, что нужно сделать концепцию «правительство как платформа» центральным элементом нашего нового мероприятия, пришла мне во время беседы с Фрэнком Ди Джаммарино, который в то время занимал пост вице-президента Национальной академии государственного управления, а затем стал специальным помощником вице-президента Джо Байдена, участвовавшего в принятии закона «О восстановлении и реинвестировании американской экономики» 2009 года. Фрэнк объяснил мне, что, по его мнению, одной из ключевых ролей правительства была роль координатора: как только правительство выявляет проблему, оно не должно пытаться решить ее напрямую, а должно объединить специалистов, которых оно хотело бы привлечь к решению этой проблемы. Фрэнк противопоставлял эту идею старой модели управления государством, которую коллега из Национальной академии государственного управления Дональд Кетл назвал «правительством торгового автомата». Хотя я использовал эту метафору иначе, чем Кетл, я все же взял ее на вооружение: мы платим налоги – взамен мы получаем услуги. В модели торгового автомата полное меню доступных услуг определено заранее. Возможность внедрить свою продукцию в систему есть лишь у небольшого числа провайдеров, и в результате выбор ограничен, а цены высокие. И когда мы не получаем того, что ожидали, наше «участие» сводится к протесту – мы трясем торговый автомат.
Это традиционное представление о правительстве как о торговом автомате было недостающим элементом, который помог осознать все, что я изучал. Мем Gov 2.0 начал блуждать в вашингтонских кругах, но в основном он ассоциировался с появлением федеральных учреждений в социальных сетях. Социальные сети в основном рассматривались политиками как возможность донести свои сообщения, а для граждан это была еще одна возможность потрясти торговый автомат. Но, на мой взгляд, для правительства существовала куда более основательная возможность – управлять Google Maps и iPhone App Store.
Мы решили переосмыслить Gov 2.0 и составить новую карту того, как технология может преобразить правительство, чтобы оно стало ближе к модели, какой ее представляли основатели нашего государства, в которой, как писал Томас Джефферсон в письме Джозефу Кабеллу, «каждый человек чувствует, что он участвует в правительственной деятельности каждый день, а не всего один день в году во время выборов». В этой модели правительство в конечном счете является инструментом координации коллективных действий граждан. Джефферсон говорил об управлении – создании правил, при помощи которых мы руководим нашим обществом, – но его принцип участия резонирует с идеями открытого программного обеспечения и, если уж на то пошло, с идеями любой успешной платформы.
Внесу ясность. Концепция правительства как платформы ни в коем случае не означает передачу государственных программ в частный сектор. Она означает стратегическое определение того, наличие каких структурных элементов должно предоставить правительство, и их предоставление, но не в чрезмерном объеме, чтобы они не ограничивали возможности участников рынка.
Я прочитал замечательную статью под названием «Правительственные данные и невидимая рука», опубликованную в январском выпуске «Yale Journal of Law & Technology» 2009 года Дэвидом Робинсоном, Харланом Йу, Уильямом П. Целлером и Эдуардом У. Фелтеном. В ней утверждается, что правительству следует отказаться от создания сайтов для граждан. Если вам знаком этот призыв, вы, вероятно, слышали его в контексте критики, обвиняющей правительство в том, что оно некомпетентно в создании технологий и будет намного лучше передать все дела государственным подрядчикам. Но эти авторы имели в виду не это. Робинсон и его соавторы хотели, чтобы правительство предоставило бесплатный доступ к массиву данных, чтобы ими мог воспользоваться любой, кто хочет, для создания различных конкурирующих сервисов, которые, возможно, будут опираться на множество бизнес-моделей. В этом состоит разница между торговым автоматом и платформой.
Эта идея также перекликается с одним из «Восьми принципов открытых правительственных данных», которые Карл Маламуд, профессор права Гарвардского университета Ларри Лессиг и я, совместно с группой других сторонников открытых данных, состоящей примерно из тридцати человек, опубликовали после заседания рабочей группы в декабре 2007 года. Один из этих принципов заключается в том, что данные должны публиковаться в форматах, не только машиносчитываемых, но с возможностью машинной обработки. Таким образом, данные можно будет еще раз использовать в целях, не предусмотренных их непосредственными создателями.
Открытые данные стали ключевым предметом обсуждения для нового правительства, но большинство людей воспринимали их только как инструмент прозрачности и подотчетности правительства. Немногие увидели, что существует реальная возможность сделать данные гораздо более полезными для граждан и для общества. Составлялась новая карта, которая, как я думал, сможет улучшить работу правительства. Я видел возможность переосмыслить традиционный для политических выступлений последних десятилетий диалог между либералами и консерваторами. Противостояние «большого правительства» и «малого правительства» по большому счету ни при чем. Если правительство будет успешным в качестве платформы, у вас может быть малое правительство и большие службы, как это происходит в компании Apple с iPhone. Компания Apple не создавала тысячи своих приложений. Apple построила платформу и рынок, и к ним стеклись сотни тысяч разработчиков.
Я пригласил Крейга Манди, в то время занимавшего пост главного технического директора Microsoft, на саммит Gov 2.0, где он решительно выдвинул идею о том, что внедрением платформы управляют «убойные приложения», на примере того, как программа Microsoft Office стала ключом к успеху Windows. Как оказалось, у федерального правительства уже были некие «убойные приложения», созданные на платформе правительственных данных, мы просто их так не называли. К 2008 году автомобили были оснащены GPS-устройствами, показывающими направление, поворот за поворотом; телефонные приложения сообщали нам, когда приедет следующий автобус; а такие службы, как Foursquare и Yelp, предоставляли нам информацию о ближайших ресторанах. Лишь немногие пользователи этих услуг сегодня понимают, что изначально система GPS начала свою работу как сервис, созданный правительством. В свое время военно-воздушные силы США запустили спутники GPS для военных целей, но после того как президентом Рейганом было принято важнейшее политическое решение открыть систему для коммерческого использования, большинство корпораций, таких как Google, решили создать свои приложения с картами. Теперь система GPS не просто приложение, она стала платформой, в результате чего в частном и государственном секторах прокатилась волна инноваций, и в настоящее время рынок оценивается более чем в 26 миллиардов долларов.
Термин Gov 2.0 стал означать нечто гораздо более серьезное, чем регистрация федеральных ведомств в социальных сетях. Вашингтонские инсайдеры начали рассуждать о том, чего мы могли бы достичь как государство, в котором правительство функционирует как платформа, на которой может строить каждый.
Легко забыть, насколько значимыми могут быть вмешательства правительства. Финансирование стэндфордского исследовательского проекта Ларри Пейджа и Сергея Брина, приведшего к созданию Google, велось в рамках программы Цифровой библиотеки Национального научного фонда. Если бы Национальный научный фонд был инвестором, а не грантодателем, действующим на благо общества, одни только эти инвестиции покрыли бы весь бюджет Национального научного фонда за годы предоставления гранта и больше. Фактически рыночная стоимость Google больше, чем все деньги налогоплательщиков, израсходованные на Национальный научный фонд с момента его основания в 1952 году.
Изначально сам Интернет был проектом, который финансировался правительством. Так же как и сеть федеральных скоростных автомагистралей. Не говоря уже о том, что правительство финансировало разработку базовой вычислительной машины и микросхемы памяти, что подарило нам Кремниевую долину, исследования, которые стоят за созданием Siri и беспилотных автомобилей, и фактически предоставило большую часть капитала для финансирования дерзких проектов Илона Маска, таких как создание электромобилей, солнечных батарей и организация коммерческих космических путешествий.
Но правительство как платформа означает гораздо больше, чем финансирование НИОКР. Будут ли процветать наши города без транспорта, воды, энергии, уборки мусора и других услуг, которые мы воспринимаем как должное? Так же как операционная система предоставляет сервисы для приложений, правительство осуществляет функции, обеспечивающие деятельность частного сектора. В особенности это заметно на местном уровне, где правительство самым непосредственным образом взаимодействует с гражданами.
Осенью 2016 года, во время визита в Нью-Йорк, поутру я отправился на пробежку в Центральный парк. Он был прекрасен в свете восходящего солнца, и столь же прекрасным было увидеть, как жители Нью-Йорка используют свой парк. Бегуны и велосипедисты заполонили дороги и дорожки, но были и люди, которые просто сидели, наслаждаясь рассветом. И, конечно же, были люди, выгуливающие собак.
Парк довольно чистый, и в тот понедельник я наткнулся на группу людей из обслуживающего персонала, которые напомнили мне, почему он такой чистый. Это не жители Нью-Йорка ухаживают за парком. Это за парком ухаживают ради них. Это специально отведенный оазис естественной красоты в центре огромного города, и за ним ухаживают, на радость посетителям. Каждый год парк посещает сорок два миллиона человек.
Когда я бежал по парку, то не мог отделаться от мысли, что поддержание парка – это метафора для всего, что правительство делает для своих граждан. Наши дороги, наши поезда, наше водоснабжение и канализация, всеобщий доступ к энергоснабжению, теплоснабжению и телекоммуникациям. Наши школы. Наша защита от пожаров и наводнений, от преступлений и от внешних врагов. Наше верховенство права. Я знаю, что многие из этих «сервисов» стоят дороже, чем следовало бы, а дают отдачи меньше, чем могли бы. Некоторые из них, как это ни трагично, не соответствуют основным американским ценностям – я скорблю о произволе полиции в отношении людей с темным цветом кожи, о неоправданных международных войнах, о несовершенстве закона, который, похоже, слишком часто оказывается на стороне богатых и влиятельных. Тем не менее я также размышляю обо всех тех случаях, в которых правительство выступает в роли платформы, на которой построена наша экономика и наше общество, по аналогии с тем, как iOS и App Store являются платформой для экономики смартфонов Apple.
Точно так же, как недоумение от того, что сторонники Linux игнорировали Интернет, выстраивая свою картину происходящего, у меня вызывает недоумение тот факт, что восторгающиеся крупнейшими платформами Кремниевой долины критикуют правительство за те же действия, которые, когда исходят от Google, Facebook, Amazon или Apple, воспринимаются как принципиально важные. Не должен стоять вопрос о том, должно ли правительство делать это; следует задаться вопросом, как помочь правительству лучше выполнять свои обязанности в качестве платформы.
Как мы уже говорили, создание широкого рынка является первым требованием для любой платформы. Это не является чем-то само собой разумеющимся. Для широкого рынка нужны как производители (в случае с Apple, разработчики приложений), так и потребители. В мире смартфонов Apple и Google смогли построить обширные рынки, а компания Microsoft, несмотря на свои прошлые успехи, не смогла этого сделать. Их телефоны, опоздавшие с выходом на рынок, купило недостаточное количество людей, и поэтому разработчики не пожелали создавать новые приложения для Windows Mobile, что утвердило решение клиентов отказаться от телефонов.
Как измеряется эффективность правительства? Для «широкого рынка» это «процветающая экономика». Нам нравится думать, что «рынок» является естественным явлением. Но тот факт, что существуют бедные страны с богатыми природными ресурсами и большой численностью населения и богатые страны, не располагающие ни большими ресурсами, ни большой численностью населения, учит нас, что создание процветающей экономики – это искусство.
В то время как технологическая платформа должна привлекать пользователей, у государства уже существует набор невольных «пользователей»: его местное население. Если численность населения или ресурсы невелики, страна должна превзойти свои возможности для достижения процветания, но в большинстве случаев численности этого местного населения достаточно для обеспечения надежного рынка, с большим количеством потребителей и множеством поставщиков товаров и услуг.
Но оценка богатства стран дает нам важный урок: если у населения не хватает денег на покупку товаров и услуг, предлагаемых либо местными продавцами, либо продавцами из других стран, страна остается бедной. На ее рынке нет баланса. Таковой является ситуация в мировой экономике сегодня, где рост идет медленно, потому что богатство сконцентрировано в руках слишком небольшого количества людей, и для всех товаров и услуг не находится покупателей, которые при ином раскладе могли бы быть. Если позволить этой тенденции продолжаться достаточно долгое время, весь рынок зачахнет. Производители товаров и услуг в таком случае переходят на другие рынки. Благосостояние стран растет и сокращается, совсем как у технологических платформ.
Достижение надежности рынка и ее поддержание часто требуют сильного государственного вмешательства. В своей книге «Bad Samaritans» корейский экономист Ха Джун Чхан описывает, как Южная Корея использовала централизованное планирование и целевые инвестиции в конкретные отрасли промышленности для создания успешной экономики. «Корея, одно из самых бедных мест в мире, была жалкой страной, где 7 октября 1963 года родился я, – пишет он. – Сегодня я гражданин одной из самых богатых стран в мире, если не богатейшей… Материальный прогресс, который я увидел за свои 40 с лишним лет, сравним с тем, как если бы я начал жить как британский пенсионер, родившийся во времена правления Георга III». Эта трансформация была во многом обусловлена сильным государственным управлением корейской экономики, защитой ее развивающихся отраслей и продуманными шагами, с помощью которых страна фокусировалась на производстве все более дорогой продукции. Та же точка зрения высказана относительно ранней истории Соединенных Штатов в недавно вышедшей работе. В книге «Concrete Economics» Стивен Коэн и Брэд Делонг пересматривают уроки истории, возвращаясь к Александру Гамильтону и определяя роль государственного участия на каждом значительном этапе пути американской экономики.
Правила технологической платформы могут быть не строгими, как в экосистеме приложений Android компании Google, или строгими, как на более жестко контролируемой платформе iPhone. Это справедливо как для стран, так и для смартфонов. Есть много способов добиться успеха в создании успешной платформы.
Технологическим платформам и правительству есть чему поучиться друг у друга.
Правительственные и технологические платформы должны предоставлять основные услуги, на базе которых строятся «приложения» или другие услуги. Несмотря на широко распространенное мнение, что экономика Соединенных Штатов в значительной степени является «свободным рынком», ничто не работает без основополагающей инфраструктуры. В 1930-х годах Управа Долины Теннесси и Администрация электрификации сельских районов построили плотины и системы распределения электроэнергии и постановили, что доступ к электричеству является основным правом каждого гражданина. По той же схеме поступили с телекоммуникациями, обязательства по их всеобщему обслуживанию взяла на себя Федеральная комиссия по связи. И конечно же, наша национальная система шоссейных дорог, созданная в 1950-х годах, способствовала торговле между штатами и ускорила рост нашей экономики. Все вышеперечисленное входит в число основных платформ нашей страны, так же как функции доступа к базовому процессору, памяти, датчикам и возможности телефона являются сервисами платформы iPhone, а оплата, распространение, безопасность, обнаружение и т. д. являются основополагающими сервисами платформы App Store.
Каждая из этих платформ должна также создавать и обеспечивать верховенство права как части этих основных услуг. Если бы корпорация Google позволила компаниям, предоставляющим информацию низкого качества, выходить в топ поисковой выдачи, люди перешли бы на Microsoft Bing или какую-нибудь другую поисковую систему, поэтому Google вложила огромные ресурсы в разъяснение правил допустимого поведения и определение меры наказания для недобросовестных участников. Если бы из магазина App Store загружалось приложение, крадущее вашу личную информацию или ваши деньги, вы бы подумали дважды перед загрузкой следующего приложения, поэтому у корпорации Apple также есть надежная система обеспечения безопасности, контроль качества и контроль состояния инфраструктуры. Верховенство права на платформах и в правительстве делает ведение торговли возможным: люди не занимаются бизнесом там, где они не могут положиться на соблюдение норм.
Также все платформы должны инвестировать в инновации, чтобы стимулировать появление новых возможностей. Мультисенсорный интерфейс iPhone был инновацией, которая окупилась не только для Apple, но и для множества людей, которые выбрали эту платформу как клиенты или как разработчики приложений. Точно так же государственные инвестиции в передовые технологии окупаются неожиданным образом. Основополагающая технология цифровых вычислений была разработана военными во время Второй мировой войны, а затем стала достоянием общественности. Затем ею воспользовалась IBM, чтобы превратиться из производителя электромеханических табуляторов в ведущего гиганта-монополиста новой эры. Аналогично, инвестиции военного времени придали суперускорение аэрокосмической промышленности, производству пластмасс и химикатов. Во время холодной войны военные разработали такие технологии, как Интернет и спутники GPS, которые, когда открылась возможность их использования в частном секторе, привели к созданию цифрового мира, такого, каким мы его знаем сегодня.
В последнее время такие инициативы, как проект «Геном человека» и проект Белого дома BRAIN Initiative, сдвигают границы фундаментальных исследований в областях, которые вполне могут стать центральными для нового технологического бума, новой платформы и новой экономики, после того как цифровой мир, на котором мы так зациклены сегодня, растворится в повседневности, как и предыдущие технологии-«единороги».
Каждая платформа взимает плату за свои услуги. На частной платформе, такой как App Store, разработчики признали, что 30 % – это налог, который они должны заплатить корпорации Apple за все услуги, которые она предоставляет экономике, которую она поддерживает. Люди также принимают как должное то, что платформы, такие как Uber и Lyft, забирают часть заработка у своих водителей, а Amazon – у своих реселлеров. Подобным же образом в демократическом обществе люди облагают налогом самих себя ради достижения общих целей, чтобы профинансировать платформу, на которой строится общество. В закрытом обществе те, кто находится у власти, взимают ренту с тех, кто пользуется платформой. Но так или иначе, мы должны платить. Вопрос в том, сколько и считаем ли мы, что то, что мы получили, того стоит.
И поэтому для каждой из этих платформ важна производительность. Если ваш телефон или приложение работают медленно, ненадежны или сложны в использовании, вы ищете лучшую альтернативу. Во время недавних событий в истории Соединенных Штатов мы наблюдали растущее презрение к правительству и его роли в нашем обществе. Его характеризовали как заплывшее жиром, неэффективное и оторванное от общества. Как и любая система, которая развивалась на протяжении сотен лет, наши процессы государственного управления, структура и регулирование остро нуждаются в реорганизации. И на выборах в 2016 году недовольство чрезмерно раздувшимся государственным аппаратом привело к беспрецедентному изменению направления, последствия чего только начинают проявляться.
Чего наиболее недовольные граждане нашей страны, по всей видимости, не понимают – это того, что механизмы для переосмысления платформы нашего правительства в XXI веке понемногу уже формируются.
За год проведения мероприятий Gov 2.0 Дженнифер Палка, работавшая тогда генеральным менеджером наших партнерских мероприятий TechWeb, стала одержимой идеей. Она проводила половину своего времени на нашем мероприятии Web 2.0, основное внимание на котором уделялось появлению Facebook, Twitter и iPhone, и половину времени – на нашем мероприятии Gov 2.0, посвященном интересу к правительству как платформе, также и впервые изучающем то, как правительство создает и закупает свое программное обеспечение.
Как и порекомендовал мне Эрик Шмидт, мы ходили по Вашингтону и беседовали со множеством людей, и многое из того, что мы слышали, было историями о неудачных технологических проектах, о системах, которые множество лет (иногда десятилетий) находились в процессе создания и которые или попросту не работали или работали настолько плохо, что пользователи предпочитали старую систему, даже если это означало, что работа по-прежнему велась на бумаге. Невозможно было представить более яркий контраст между повседневной работой в этих двух мирах. Конференция становилась реальным местом для диалога между ними, но Джен хотела как-то исправить то несоответствие, которое она увидела.
Мы оба видели, что усовершенствование работы систем правительства может опираться на основные методы, используемые для работы с потребителями в сферах высоких технологий. Но Джен также видела и гуманитарные последствия существующего состояния дел. Сразу после колледжа, прежде чем начать работать в средствах массовой информации, освещающих высокие технологии, Джен устроилась на работу в агентство социальной помощи детям. Она смогла провести параллель между этими неудачными технологическими проектами и детьми, находящимися на попечении государства, социальных работников и сотрудников администрации, которым было поручено защищать их интересы, но чье программное обеспечение и системы работали так плохо. Слишком часто эти системы делали заботу об этих обездоленных детях еще сложнее.
В конце 2009 года Джен уволилась из TechWeb и при помощи кредитной карты и небольшого гранта на планирование от некоммерческой организации Sunlight Foundation и независимого фонда Abrons Foundation запустила некоммерческий проект «Код для Америки», целью которого являлось повышение компетентности правительства до уровня, присущего миру потребителей высоких технологий. Она решила начать с городов, как посоветовал ей ее друг Эндрю Гринхилл, начальник штаба в мэрии Тусона, указавший, что местное правительство является не только менее бюрократизированным, но и имеет больше возможностей для связей с общественностью. В каждый из городов, подавших заявку и выбранных на конкурсной основе для проекта «Код для Америки», предполагалось отправить команду программистов, разработчиков и прочих специалистов из индустрии высоких технологий, чтобы на протяжении года создавать приложения.
Джен попросила меня войти в совет директоров, и я с радостью согласился. Другие также с энтузиазмом восприняли идею: 525 специалистов из области высоких технологий подали заявки на участие в программе; мы отобрали всего двадцать из них для работы в четырех городах – Бостоне, Филадельфии, Сиэтле и Вашингтоне. Выплата стипендии начиналась в январе 2011 года, после месяца обучения, а в феврале научные сотрудники отправились по «своим» городам оформляться на работу.
В течение следующих нескольких лет мы помогли местным органам власти создать серию приложений, которые, как сказал участник первого года проекта и бывший разработчик Apple Скотт Сильверман, были «красивыми и простыми в применении». Веб-сайт для выбора школы в Бостоне. Система отслеживания пришедших в упадок зданий в Новом Орлеане. Краудсорсинговое приложение для очистки пожарных гидрантов от снега, которое, будучи с открытым исходным кодом, разошлось во многие другие города и стало использоваться для других форм общественной деятельности, таких как очистка ливневых стоков и предоставление докладов о том, были ли оперативными оповещения о цунами в Гонолулу. В Санта-Крусе участники проекта создали портал для упрощения ведения малого бизнеса. Другая группа участников, работая в свободное время, создала простой способ составления новых маршрутов общественного транспорта для любого города.
Скорость, с которой участники проекта смогли создать и запустить в работу новые приложения, потрясла сотрудников администрации города. Первая версия сайта в помощь выбора школы в Бостоне была построена примерно за шесть недель. Позже городские специалисты ИТ с изумлением отмечали, что, если бы они пошли по стандартной процедуре закупок, сайт стоил бы им 2 миллиона долларов и его строительство заняло бы два года. Аллен Сквер, начальник информационного управления Нового Орлеана, аналогично отзывался о блестящем инструменте отслеживания.
Что еще более важно, работа сотрудников проекта показала, что функционирование правительственной платформы можно улучшить. Дело не только в том, что созданные ими приложения стоили дешевле и разрабатывались быстрее, а в том, что они работают на своих пользователей. В случае с приложением для выбора школы в Бостоне источник представлял собой брошюру из двадцати восьми страниц, разбитую на восемь глав. Она содержала много информации, но, как и многие правительственные публикации, не могла разрешить какую-либо конкретную ситуацию, потому что каждая из них требовала рассчитать расстояние от дома ребенка до предполагаемых школ, поэтому фактически эта памятка не могла выполнить ту функцию, которую от нее требовали пользователи. Недовольство родителей, пытавшихся выбрать школу без таких простых инструментов, вылилось в публикацию ряда статей в газете «Бостон глоб», которые в течение года освещали усилия семей, пытающихся разобраться в этой путанице. Приложение для выбора школы стало победой не только для бостонских семей, но и для подвергавшихся критике политиков.
Создание приложения с использованием возможностей технологий, предназначенных для широкого круга потребителей, и клиентоориентированных методов (минуя каналы государственных закупок) было действенным способом показать, что раздутый чиновнический аппарат неэффективен и оторван от народа. Вместо того чтобы жаловаться на закостенелое правительство, «Код для Америки» показал всем (не только нашим правительственным партнерам, а также программистам и разработчикам, которые пожелают принять участие), что правительство может работать так, как хочет общественность. Наша теория изменений заключалась в том, что приложения перейдут под управление местных органов власти, для которых мы их создали, и, обладая открытым исходным кодом, смогут распространяться волонтерами, входящими в «Бригаду Кода для Америки», как сказано в уставе организации. В отличие от некоммерческой организации «Teach For America», которая разрасталась благодаря привлечению десятков тысяч учителей-волонтеров, наша цель заключалась в увеличении масштабов организации прежде всего за счет кода, подобно тому как это происходит в других приложениях с открытым кодом и интернет-приложениях.
Участие в проекте 2012 года открыло новые возможности. В том году четыре команды участников решили, что хотят создать стартап на базе разработанного ими проекта. После окончания года службы команды продолжили разрабатывать свои проекты и продавать их в другие города.
Рон Буганим, успешный венчурный инвестор, вызвался запустить бизнес-инкубатор и ускоритель для общественных стартапов. По прошествии двух лет он основал венчурный фонд Govtech Fund, специализирующийся на инвестициях в компании, которые внедряют передовой опыт XXI века в правительственные технологии. Многие стартапы, подготовленные участниками «Кода для Америки», были выкуплены; другие получили значительное венчурное финансирование. Remix, приложение, которое изначально создавалось для обеспечения возможности жителей видеть транзитные маршруты своего города, превратилось в мощный инструмент для специалистов по городскому планированию и было профинансировано ведущими венчурными капиталистами, которые оценили его в 40 миллионов долларов.
Концепция того, что правительство может стать платформой, подражая магазину приложений App Store компании Apple, оказалась плодотворной.
Впрочем, в 2013 году проект «Код для Америки» в городе и округе Сан-Франциско открыл нам глаза на еще большие возможности преобразований. Сан-Франциско попросил нас поработать над Американской программой льготной покупки продуктов, или SNAP, более известной как программа выдачи продуктовых талонов. Это федеральная программа, которая, как и многие другие программы, на местном уровне находится в ведомстве штатов и округов. Проблема, с которой служба социального обеспечения Сан-Франциско обратилась к проекту «Код для Америки», заключалась в следующем: люди подписывались на пособия по программе SNAP, но затем несколько месяцев спустя выбывали из этих списков, а поэтому были вынуждены подавать заявки повторно.
Эту проблему нельзя было решить при помощи приложения. Участников проекта просили наладить работу правительственной программы. Те спросили, могут ли они подать заявку на продовольственные талоны (но не пользоваться пособиями), и начали проходить через процедуру, как это делали обычные люди, наблюдая процесс изнутри.
Участники проекта попали в мир, знакомый читателям романа «Уловка-22» Джозефа Хеллера или зрителям фильма «Бразилия» Терри Гиллиама. По почте им пришли письма, написанные на не поддающемся пониманию юридическом языке, который не могли понять даже сотрудники службы, не говоря уже о предполагаемых получателях пособий, ведь для некоторых из них английский, возможно, был вторым языком.
До некоторых из них письмо даже могло не дойти, поскольку у них не было постоянного адреса проживания. Иногда письма были на другом языке – один англоговорящий гражданин получил свое письмо на китайском. Обнаружилось, что некоторые из писем, в которых назначалась встреча для дополнительного собеседования, были отправлены уже после даты предполагаемого собеседования. Документы, запрашиваемые в процессе подачи заявки, терялись, в то время как заявителю сообщалось, что они были успешно приняты, а в службе социального обеспечения обнаруживалось, что их никогда не получали.
Участники были настолько воодушевлены проектом, что один из них, Джейк Соломон, не захотел уходить из него по прошествии года. К нему присоединились двое других участников, которые работали над проектами в других городах, Алан Уильямс и Дэйв Гуарино. Они продолжали работать бесплатно до тех пор, пока организации не удалось привлечь финансирование, чтобы официально продолжить проект. Алан спал на кушетке у Джейка и пользовался продовольственными талонами, на этот раз по-настоящему.
Они обнаружили, что онлайн-приложение программы само по себе было камнем преткновения. Опрос в приложении занимал пятьдесят экранных страниц. Чтобы заполнить эту анкету, даже при помощи социального работника, требовалось сорок пять минут. Она содержала множество вопросов, не имеющих отношения к конкретному заявителю. Приложением невозможно было воспользоваться через мобильный телефон, несмотря на то что половина всех онлайн-соискателей обращались к программе с мобильных устройств. Вместо того чтобы осознать возможность создания древовидной структуры вопросов, веб-приложение просто дублировало все вопросы из всеобъемлющих бумажных формуляров.
Прежде всего в качестве метода сбора данных команда создала удобное мобильное приложение GetCalFresh, которое позволяет заявителям запустить приложение, загрузить документы и отправить запрос на собеседование меньше чем за восемь минут. Это приложение стало ключевым в их пользовательском исследовании, поскольку оно позволило сделать так, чтобы пользователи довели дело до конца, позволило поддерживать с ними связь при помощи текстовых сообщений и, с их согласия, отслеживать некоторые из их данных. Кроме того, приложение было взято на вооружение шестью другими округами Калифорнии, которые сочли, что оно лучше, чем их действующее онлайн-приложение для выдачи пособий. В настоящее время его собираются внедрить во всех пятидесяти восьми округах штата Калифорния.
Результатом этого проекта для нас стало осознание трех важных истин. Во-первых, приложения XXI века могут только затормозить нас, если построены на базе неработающей правительственной платформы XX века. Простое наложение цифрового интерфейса поверх неработающей бюрократической системы часто усугубляет проблему, потому что цифровая система воспроизводит существующие процессы, не переосмысливая их. Прежде чем мы сможем создать приложения, которые действительно преобразят опыт общения граждан с органами власти, особенно наиболее нуждающихся, мы должны улучшить основную деятельность государственных служб. Точно так же как впечатлением от работы приложения, которое вы используете на своем телефоне, в конечном счете является не точка в приложении Uber, а весь спектр услуг, который позволяет вам без проблем добраться из точки A в точку B, главное в продовольственных субсидиях – это не процесс подачи заявок в онлайновом режиме, а скорее возможность покупать здоровую пищу для вашей семьи. Работа над программой SNAP дала нам понять, что слишком во многих государственных службах после подачи заявления с пользователями происходит столько всего, что это ухудшает возможность, а то и вовсе препятствует фактическому предоставлению им услуг.
Вторая истина заключалась в том, что понимание того, что представляет собой процесс оказания услуг, является ключевым в формировании правильной политики. В ходе своей работы команды «Кода для Америки» столкнулись с политическими решениями и нормами регулирования, которые казались довольно безобидными, но которые препятствовали предоставлению услуг и осложняли существующее положение как для правительственных учреждений, так и для пользователей. Например, политика добавления вопросов, призванных помочь заявителям на предоставление продуктовых талонов проголосовать в процессе подачи заявки, была продиктована благими намерениями, но непреднамеренно создала путаницу (и риск) для заявителей, которые в действительности не имеют права регистрироваться в качестве избирателей.
Системы, призванные помогать людям в сложных обстоятельствах, вместо этого в конечном итоге становятся для них огромной проблемой. Поскольку директивные органы не переживают опыт пользователей, они имеют ограниченное представление о последствиях своей политики в реальном мире. Но когда опыт пользователей может быть наглядно продемонстрирован, те же самые итеративные методы, основанные на данных, которые использовали команды «Кода для Америки» для создания отличных приложений, можно использовать для разработки или изменения административных мер и норм регулирования, чтобы приблизиться к намеченным результатам.
Оказалось, что приложения, которые мы разрабатываем, являются еще одним инструментом для улучшения работы правительства, давая нам представление о стоящих за этой работой процессах. Каждая фирма в Кремниевой долине создает две взаимосвязанные системы: приложение, которое предоставляет услуги пользователям, и скрытый набор приложений, которые они используют, чтобы понять, что происходит, для постоянного улучшения своего обслуживания. Команда «Кода для Америки» поняла, что их приложение для программы SNAP является способом привлечь пользователей, а затем отслеживать их действия, чтобы задокументировать их путь через работу службы. Как только вы видите, что что-то идет не так, вы можете совместно с государственными органами поработать над устранением этой проблемы. Джен называет эту стратегию «от приложений к сбору информации».
Правительство может работать лучше; ему необходимы более глубокие преобразования. По принципу компании Amazon, переосмыслившей и перестроившей свое приложение для электронной коммерции в облачную вычислительную платформу, на которой теперь работает их собственный веб-сайт, а также тысячи других приложений, или Трэвиса Каланика и Гарретта Кэмпа, переосмысливших, как может работать служба такси в эпоху повсеместного использования смартфонов. Кое-где, как мы увидим, правительство поступает именно так.
Наша третья истина нашла блестящее отражение в отчете Джейка о проекте под названием «Люди, а не данные», который был опубликован в виде эссе в журнале «Medium» и в котором говорилось, что ключом к успешному переосмыслению государственных услуг является эмпатия, а не только технология. Очень важны дизайн и опыт пользователя, а не только сбор большого количества данных и программирование. Прежде всего государственные директивные органы должны поставить себя на место тех, кому они хотят предоставлять услуги.
Особенно это касается оказания услуг тем, кто больше всего нуждается в помощи правительства. Это услуги, взаимодействие с которыми действующих из лучших побуждений законодателей и их обеспеченных спонсоров наименее вероятно. С учетом того, что значительная часть отчетов о провале сайта healthcare.gov ошибочно характеризовала этот факт как единичную катастрофу, нежели как эпидемию, Эзра Клей пишет: «Привилегия, которой обладают застрахованные и обеспеченные лица, – это прощать то ужасное качество услуг, которые правительство обычно предоставляет бедным. Зачастую пресса попросту понятия не имеет о той боли и тех трудностях, которые ежедневно испытывают бедные, взаимодействуя с государственными чиновниками».
Осознание этой истины привело к тому, что проект «Код для Америки» сменил свой курс на создание более качественных услуг для тех, кто в них больше всего нуждается. В настоящий момент команды проекта «Код для Америки» работают над тем, чтобы сделать профессиональную подготовку более доступной, упростить процедуру коммуникации для людей, пытающихся пройти испытательный срок, и облегчить эту процедуру для людей с низким социальным статусом, в основном совершивших какое-либо уголовное преступление, связанное с наркотиками, – удалить их из реестра, чтобы они могли работать, иметь жилье и другие средства первой необходимости. На момент написания этой статьи штат Калифорния совместно со спонсорами-филантропами, включая предпринимателя Рида Хоффмана и венчурный инвестиционный фонд Omidyar Network, финансирует амбициозный проект, поддерживающий «Код для Америки» в создании масштабируемых цифровых услуг, которые можно будет оказывать на всей территории страны.
Тем временем в Вашингтоне, где началась наша история «правительство как платформа», в федеральном правительстве происходили похожие движения и преобразования.
В то время как команда участников проекта «Код для Америки» в Сан-Франциско начала изучать проблемы программы SNAP, мы с Джен отправились в Лондон, чтобы посетить Правительственную Цифровую Службу (ПЦС) Соединенного Королевства. Пока мы там находились, Джен поступил звонок от Тодда Парка, в то время занимавшего пост главного технического директора Соединенных Штатов и специального помощника президента. Тодд запустил новую программу под названием «Инноваторы президента», в определенной степени скопированную с «Кода для Америки». Он позвонил, чтобы предложить Джен помочь ему вести программу в качестве заместителя главного технического директора по правительственным инновациям.
Сначала она отказалась, ссылаясь на свои обязательства перед проектом «Код для Америки». Но Тодд настаивал. «Капля точит камень не силой, а частотой падения» – так описал этот процесс ее будущий коллега Ник Синай. В конце концов она согласилась. «Я приду, – сказала она Тодду, – но только если вы позволите мне работать над созданием нового подразделения, такого как Правительственная Цифровая Служба Соединенного Королевства».
Правительственная Цифровая Служба – это специальное подразделение, которое в то время подчинялось непосредственно секретариату кабинета министров Соединенного Королевства, группе, ответственной за деятельность правительства. Она была создана в 2011 году под руководством Майка Бракена, бывшего главы цифрового отдела в газете «Guardian». Вскоре Майк привлек самых талантливых специалистов из технологических и цифровых медийных кругов Великобритании, и Правительственная Цифровая Служба была оценена одним известным венчурным инвестором как «лучший стартап в Европе, в который мы не можем инвестировать». Проведенная командой полная модернизация веб-стратегии британского правительства, заменившая тысячи противоречащих друг другу веб-сайтов одним простым клиентоориентированным хабом, получила награды за дизайн, которые обычно получают высокотехнологичные компании, и сэкономила правительству Великобритании 60 миллионов фунтов. Но оказалось, что это только начало.
Панорамное окно в вестибюле офиса Правительственной Цифровой Службы на верхнем этаже старого офисного здания, возвышающегося над оживленной лондонской улицей, было закрыто большим листом плотной бумаги. Было лишь небольшое отверстие, сквозь которое вы могли видеть людей на улице внизу. К отверстию вела большая стрелка с надписью «Пользователи», напоминая всем, кто проходил мимо, кому должно служить это подразделение.
Правительственная Цифровая Служба увековечила это напоминание в первом из своих десяти принципов построения ПЦС, которые с тех пор стали своего рода библией цифрового правительства, сформулировав основные правила разработки высококлассных цифровых услуг. (Эти правила в равной степени эффективны и для коммерческих услуг.) Первый принцип гласит:
Начните с потребностей – с потребностей пользователей, а не с потребностей государства. Именно вокруг этих реальных потребностей пользователей должны строиться приложения, а не вокруг того, как происходит «официальный процесс» на данный момент. Мы должны досконально понимать эти потребности – проводить опросы для получения данных, а не просто строить предположения, и мы должны помнить, что то, что просят пользователи, – это не всегда то, что им нужно.
Второй принцип тоже звучит для меня как музыка, в нем сказывается влияние моей собственной стати и выступления на саммите Gov 2.0. Он гласит:
Делайте меньше. Правительство должно делать только то, что может сделать только правительство. Если мы открыли какой-то эффективный метод работы, мы должны найти способ его многократного и совместного использования вместо того, чтобы каждый раз изобретать колесо. Это означает создание платформ и регистров, на базе которых другие люди могут строить свои приложения, предоставляющих ресурсы (такие как API), которыми могут пользоваться другие, и связывающих работы разных разработчиков. Мы должны сконцентрироваться на создании минимального ядра.
Остальные принципы также отражают столь многое из того, чему нас научили технологии. Проектируйте, основываясь на данных. Сделайте тяжелую работу, чтобы сделать это простым. Сделайте итерацию. Затем снова сделайте итерацию. Создавайте цифровые услуги, а не веб-сайты. Делайте вещи открытыми.
Комитет проекта «Код для Америки» предоставил Джен один год отпуска, и в июне 2013 года она присоединилась к Тодду в Белом доме. Я поехал вместе с Джен в округ Колумбия и видел, как она боролась с трудностями на пути к созданию новой службы, включая выбор места ее размещения и написание руководящего документа под названием «Тактика предоставления цифровых услуг» в соавторстве с Хейли Ван Дейк, Чарльзом Уортингтоном, Ником Синаем, Райаном Панчадсарамом, Кейси Бернс и другими. Она, ее коллеги и союзники решили назвать эту службу Цифровой службой США в честь Цифровой Службы Соединенного Королевства и неустанно лоббировали ее создание.
Дело, за которое боролась Джен и другие, набирало силу, но было еще далеко от завершения, когда в октябре 2013 года был запущен сайт healthcare.gov… оказавшийся провальным. Внезапно усовершенствование правительственных технологий стало не теоретическим упражнением, а чрезвычайной ситуацией национального масштаба. Проводимая администрацией Обамы политическая инициатива готова была с треском провалиться из-за неспособности правительства создать функционирующий веб-сайт для обработки заявок.
За полтора года до этого Том Стайнберг из британской некоммерческой организации mySociety сделал серьезное предупреждение, которое теперь казалось пугающе пророческим: «Вы больше не сможете обеспечить надлежащее управление страной, если элита не будет так же хорошо разбираться в технологиях, как в экономике, идеологии или пропаганде… Теперь то, как выглядит хорошее правительство и хорошее общество, неразрывно связано с пониманием цифровых технологий».
Безусловно, кризис healthcare.gov обосновал безотлагательность создания Цифровой службы США. Он также обеспечил формирование ее первоначального штатного состава и назначение руководства. Тодд Парк набрал две команды талантливых технических специалистов, в основном из Кремниевой долины. Одну, чтобы собрать воедино недееспособный веб-сайт, который так подмочил репутацию администрации, а вторую – чтобы создать гораздо более простой вариант сайта, используя передовые практики стартапов, а не устаревшие технологии процесса закупок, которые привели к созданию катастрофического первого варианта сайта. Когда в августе 2014 года Цифровая Служба США была окончательно сформирована, первым ее руководителем стал Майки Дикерсон, бывший инженер Google по техническому обеспечению надежности сайта (SRE), который сыграл ключевую роль в спасении healthcare.gov.
Показательно, что первым руководителем Цифровой Службы США стал инженер по техническому обеспечению надежности сайта (SRE). У подразделения уже была своя архитектура цифровой сети и отмечалась глубокая приверженность к созданию клиентоориентированных услуг, сформировавшаяся благодаря его первоначальным вдохновителям, Правительственной Цифровой Службе Соединенного Королевства и команде проекта «Код для Америки», работавшей над программой выдачи продовольственных талонов в Калифорнии. Но инженерно-техническое обеспечение надежности сайта, по сути, практикует отладку несоответствий между разработкой программного обеспечения и операциями и занимается созданием новой соединительной ткани, а это именно то, что необходимо федеральному правительству.
В течение первых двух лет Цифровая Служба США принимала непосредственное участие в приоритетных проектах федеральных учреждений, в том числе оптимизируя в министерстве по делам ветеранов заявки на выплату компенсации в связи с потерей трудоспособности; совершенствуя систему оформления виз в Государственном департаменте; проводя работу в министерстве образования, чтобы помочь учащимся более осознанно выбрать колледж; и определяя уязвимости в безопасности сайтов министерства обороны. Кроме того, служба работает над модернизацией процессов закупок для цифровых услуг и над расширением использования общих платформ и инструментов. Также теперь у Цифровой Службы США есть филиалы в семи учреждениях на уровне кабинета министров – команды, действующие по принципу «Тактики предоставления цифровых услуг», но работающие внутри учреждений и на учреждения.
При всем при том, что Цифровая Служба США сделала для того, чтобы доказать, что правительство может быть компетентным – даже превосходно разбираться – в области технологий, самый ценный урок, который мы извлекли из этого эксперимента с федеральным правительством США, оказался тем же самым, что мы извлекли, работая с местными органами власти и с национальным правительством Соединенного Королевства. Чтобы добиться успеха, платформы должны не просто предлагать приложения или услуги. Они должны быть эффективными в установлении и приведении в соответствие норм, регулирующих поведение участников платформы.
Мы также узнали, что методы создания хороших приложений весьма актуальны и для создания хороших правил.
Рассмотрим, к примеру, положения, взятые из закона о медицинской помощи под названием MACRA (Medicare Access and CHIP Reauthorization Act, 2015 г). После околосмертного опыта healthcare.gov неудивительно, что команда MACRA хотела, чтобы подразделения Цифровой Службы Министерства здравоохранения и социального обеспечения создали веб-сайт, способствующий реализации этого закона, предусматривающего возможность более высокой оплаты за более качественное обслуживание по программе медицинского страхования «Медикэр». Но к тому времени руководители в Белом доме и за его пределами уже усвоили важный урок: как сказала глава Совета по внутренней политике при президенте Обаме Сесилия Муньос на мероприятии в Белом доме 16 декабря 2016 года: «При создании своего веб-сайта не тяните с приглашением технических специалистов». Когда команда MACRA обратилась с просьбой к Мине Сян, главе Цифровой Службы Министерства здравоохранения и социального обеспечения, помочь в проекте, Мина предложила несколько иное.
Обычно происходит так, что до того, как регулирующие органы нанимают команду технических специалистов для работы с веб-сайтом для пользователей (в данном случае для врачей и других поставщиков медицинских услуг), они посвящают много месяцев научно-исследовательской работе, создавая спецификацию, в которой подробно описываются правила, согласно которым будет кодироваться веб-приложение. Мина предложила команде, пишущей правила, предоставить предварительный проект, что заняло бы примерно одну пятую часть времени, необходимого на разработку окончательного варианта, и позволить ее команде сделать предварительную версию веб-сайта на основе этого проекта.
Для команды технических специалистов это обычная практика – тестировать сайт на пользователях в начале процесса разработки. Но на этот раз это было иначе. Регулятивные органы также могли видеть, как пользователи воспринимают и интерпретируют правила, которые они написали, и меняли свои формулировки с учетом поведения пользователя. Затем они получали возможность протестировать новые формулировки в следующей (все еще черновой) версии сайта, по мере того как команда разработчиков выпускала новые версии веб-сайта для своих пользовательских тестов. Так повторялось четыре раза, прежде чем регулирующие органы утвердили окончательные правила.
Регуляторы закона MACRA были в восторге от того, что они только что написали лучшие правила в своей карьере, впервые воспользовавшись результатами обратной связи в реальном времени.
Как в случае с проектом «Код для Америки», так и в случае с Цифровой Службой США мы извлекли один, последний урок: как известно каждому, кто знаком с жестокой конкуренцией лучших специалистов в Кремниевой долине, важное значение имеет талант. Майки Дикерсон заявил об этом прямо, призвав технических специалистов рассмотреть возможность поступления на государственную службу на конференции South by Southwest (SXSW) 2016 года в Остине: «Некоторые из вас сейчас работают над очередным приложением, чтобы люди могли делиться фотографиями еды, или над социальной сетью для собак. Я здесь, чтобы сказать вам, что у вашей страны есть лучшее применение вашим талантам». Он перечислил ряд насущных проблем, в которых правительству требуется помощь, и завершил речь так: «Все это – проблемы проектирования и обработки информации, и все они являются вопросами жизни и смерти миллионов граждан, и все это вы можете усовершенствовать, если захотите».
Выбирайте. Мы снова слышим это слово. От нашего выбора зависит будущее.
Есть основания полагать, что работа Цифровой Службы США будет продолжена под руководством администрации Трампа. Лучшее правительство – это вопрос вне политики. Тем не менее существуют тревожные признаки смены вектора. Администрация Трампа отменила множество политических решений администрации Обамы по предоставлению открытого доступа к данным и, как правило, отдает предпочтение идеологии, нежели аргументам. В своем стремлении «преобразовать административный аппарат» они замахнулись кувалдой на бюрократию, но неясно, чем они собираются ее заменить. Без инициативного руководства она, скорее всего, будет заменена чем-то очень похожим.
У нас есть возможность создать правительство заново. Мы не должны упустить эту возможность.
Клей Джонсон, один из соучредителей высокотехнологичной фирмы Blue State Digital, принимавшей участие в предвыборной кампании, позднее возглавлявший сообщество Sunlight Labs в Sunlight Foundation, организации, занимающейся обеспечением прозрачности государственного управления, а позднее ставший инноватором президента в Белом доме, любит напоминать, что закон Мура может иметь тревожные последствия для правительства. Если медленные, по сравнению с частным сектором, сопротивляющиеся переменам государственные процессы закупки технологий отстают на пять-шесть лет, то, согласно закону Мура, за три или четыре периода экспоненциального роста технологий потенциал правительства сократится в десять раз.
И в классическом стиле «новостей из будущего» это именно то, что мы видим. Компания Amazon может доставить посылку через несколько часов после того, как вы сделали заказ; Google почти в режиме реального времени может рассказать вам о том, что впереди случилось ДТП и необходимо поехать по другому маршруту. В то время как Министерству по делам ветеранов США требуется восемнадцать месяцев, чтобы определить, могут ли демобилизованные военнослужащие получить пособие.
Правительства всего мира и США на федеральном, местном уровне, на уровне штатов, а также некоммерческие организации, такие как «Код для Америки», венчурные фонды, такие как Govtech Fund и Ekistic Ventures, и все большее число коммерческих компаний работают над передачей передового опыта технологий правительству, ликвидируя разрыв между тем, что оно из себя представляет сейчас, и тем, каким оно могло бы быть. Обратная сторона каждой проблемы – это возможность.
Авраам Линкольн очень верно высказался по этому поводу: «Законная цель правительства – сделать для людей то, что необходимо сделать, но что они не могут сделать совсем или не могут сделать настолько же хорошо самостоятельно».
Хоть в Кремниевой долине, которая часто поддерживает борцов за свободу, и популярно высмеивать чрезмерное вмешательство правительства, перестройка правительства, для приведения его в соответствие с остальным современным обществом, является одной из главных задач XXI века.
Часть III. Мир, управляемый алгоритмами
Надеюсь, не много осталось лет до того момента, как человеческий разум и вычислительные машины станут очень сильно взаимосвязаны, и получившийся симбиоз будет мыслить так, как ни один человек ранее не мыслил, и обрабатывать данные так, как сегодня не может ни одна электронно-вычислительная машина.
Д. К. Р. Ликлайдер, 1960 г.
Глава 8. Управление силой джиннов
В 2016 году редакция журнала Mit Sloan Management Review попросила меня написать короткое эссе о будущем управления. Сначала я ответил, что мне больше нечего сказать, по крайней мере, ничего кроме того, что уже было сказано. Но потом понял, что я отвечаю на вопрос, используя старую карту.
Если вы мыслите понятиями предприятия XX века, вы, возможно, полагаете, что десятки тысяч инженеров-программистов в таких компаниях, как Google, Amazon и Facebook, проводят свои дни, в поте лица создавая продукцию, как и их предшественники из промышленного века, только сегодня они производят программное обеспечение, а не материальные товары. Но если вы сделаете шаг назад и посмотрите на эти компании глазами человека из двадцать первого века, вы поймете, что значительная часть того, что они делают – выдача результатов поиска, предоставление новостей и информации, обновление статусов в социальной сети, предоставление соответствующих товаров и услуг водителей по требованию, – осуществляется при помощи программ и алгоритмов. Эти программы – работники, а программисты, которые их создают, – их начальники. Каждый день эти «начальники» получают отзывы о работе своих подчиненных в виде данных рынка в режиме реального времени и в случае необходимости выдают работникам свои замечания в виде небольших изменений и обновлений программы или алгоритма.
Задачи, выполняемые этими работниками – программным обеспечением, – отражают оперативный рабочий процесс цифровой организации. На коммерческом веб-сайте один электронный работник помогает пользователю найти товары, которые могут соответствовать его или ее критериям поиска. Другой показывает информацию о товарах. Третий предлагает альтернативный вариант. После того как клиент решил купить товар, цифровой работник предлагает заполнить веб-форму для оплаты и проверяет введенные данные (например, действительна ли кредитная карта с таким номером или соответствует ли пароль тому, который хранится в базе данных сайта). Другой работник формирует заказ и связывает его с регистрационными данными клиента. Еще один формирует список товаров, которые человек или робот должен забрать со склада. Еще один сохраняет данные об этой транзакции в системе бухгалтерского учета компании, а другой отправляет клиенту подтверждение по электронной почте.
В предыдущем поколении компьютерных технологий эти действия могли осуществляться одним монолитным приложением, отвечающим на запросы одного-единственного пользователя. Но современные веб-приложения вполне могут одновременно обслуживать миллионы пользователей, а их функции разбиты на так называемые микросервисы – наборы отдельных структурных элементов, каждый из которых делает что-то одно, и делает это очень хорошо. Если бы традиционное монолитное приложение, такое как Microsoft Word, было переделано в набор микросервисов, вы могли бы легко изменить опцию проверки орфографии на более качественную или добавить новую функцию, которая превращала бы веб-ссылки в сноски, или наоборот.
Микросервисы – это эволюция ориентированного на коммуникации конструктивного шаблона, который мы видим в структуре Unix и Интернета, а также в меморандуме Джеффа Безоса. Микросервисы определяются входящими и исходящими данными – тем, как они сообщаются с другими сервисами. Они могут быть написаны на разных языках и работать на множестве машин. Если они правильно спроектированы, любой из компонентов может быть заменен на улучшенный вариант, который выполняет ту же функцию, не требуя обновления остальной части приложения. Это то, что позволяет осуществлять непрерывное использование, при котором новые функции могут обновляться постоянно, а не одним мощным рывком, а также проводить А/Б-тестирование, во время которого альтернативные версии одной и той же функции можно протестировать на отдельных группах пользователей.
По мере увеличения количества и скорости разработки интернет-приложений характер работы в сфере программного обеспечения для множества людей также изменился. Это чем-то похоже на замену пропеллеров на реактивные двигатели в авиации. Для широкой категории приложений этот «реактивный двигатель» появился в виде первой прикладной статистики и теории вероятности, затем в виде машинного обучения и все более изощренных алгоритмов ИИ.
В 2006 году Роджер Магоулас, вице-президент O’Reilly Media по научным исследованиям, впервые ввел термин «большие данные» для описания новых инструментов управления данными в масштабе, который позволяет обслуживать такие компании, как Google. Бывший научный сотрудник корпорации Bell Labs Джон Маши использовал этот термин еще в 1998 году, но для описания растущего объема собираемых и хранимых данных, а не для каких-то управляемых этими данными услуг, основанных на статистике, и не для обозначения крупных достижений в области программного обеспечения и рабочих процессов, которые делают возможным предоставление этих услуг.
Большие данные означают не просто более масштабную версию реляционной базы данных, такой как Oracle. Это нечто совершенно иное. В своем докладе 2009 года «Необъяснимая эффективность данных» (своим названием он обязан классическому докладу Юджина Вигнера 1960 года «Необъяснимая эффективность математики в естественных науках») исследователи машинного обучения корпорации Google Алон Халеви, Питер Норвиг и Фернандо Перейра объяснили растущую эффективность статистических методов при решении сложных тогда проблем, таких как распознавание речи и машинный перевод.
Большая часть предшествующей работы была основана на грамматике. Смогли бы вы сконструировать, по сути, огромный поршневой двигатель, который использовал бы свои знания грамматических правил для распознавания человеческой речи? Успех был бы незначительным. Но по мере появления в Интернете все большего количества документов ситуация менялась. Несколько десятилетий назад исследователи полагались на тщательно отобранные фигуры человеческой речи и литературные произведения, которые в лучшем случае содержали несколько миллионов слов. Но в конечном итоге в Интернете стало настолько много контента, что правила игры сильно изменились. В 2006 году корпорация Google собрала базу из триллиона слов для исследователей языка и разработала «реактивный двигатель» для их обработки. С того момента прогресс пошел быстро и решительно.
Халеви, Норвиг и Перейра отмечали, что эта база, взятая из Интернета, во многом отличалась от курируемых версий, которыми пользовались предыдущие исследователи. В ней было полно незаконченных предложений, грамматических и орфографических ошибок, она не была привязана к грамматическим конструкциям и не содержала аннотацию. Но тот факт, что она была в миллион раз объемнее, перекрывал все эти недостатки. «База объемом в триллион слов – вместе с другими фигурами речи из Интернета, из миллионов, миллиардов или триллионов ссылок, видео, изображений, таблиц и взаимодействий пользователей – охватывает даже очень редкие аспекты человеческого поведения», – писали они. Вместо того чтобы создавать все более сложные языковые модели, исследователи начали «использовать лучшего имеющегося союзника: необъяснимую эффективность данных». Путем к пониманию языка были не сложные, основанные на правилах модели: нужно было просто воспользоваться статистическим анализом и позволить данным самим рассказать им, какой должна быть модель.
Хотя в этом докладе основное внимание уделялось переводу с одного языка на другой, он обобщил понимание того, каким должен быть подход для успеха основного поискового сервиса Google. Достигнутое понимание того, что «простые модели и множество данных лучше, чем более сложные модели, основанные на меньшем количестве данных», стало основополагающим для прогресса во всех областях и легло в основу работы множества компаний Кремниевой долины. Еще более важное значение это имеет для последних достижений в области искусственного интеллекта.
В 2008 году Дж. Патил из компании LinkedIn и Джефф Хаммербачер из Facebook ввели термин «наука о данных», чтобы описать свою работу. Они дали название сфере деятельности, которую несколько лет спустя журнал Harvard Business Review назвал «самой сексуальной работой XXI века». Понимание менталитета науки о данных, подхода к ней и того, чем она отличается от старых методов программирования, имеет решающее значение для всех, кто решает сложные задачи XXI века.
Из того, как Google работает над качеством поиска, можно извлечь важные уроки. Вначале корпорация Google взяла на себя обязательство выдавать результаты поисковых запросов, основываясь на статистических методах, с явно предвзятым отношением к устранению проблем вручную. Ответ на поисковый запрос «Питер Норвиг» должен содержать такие вещи, как его страница в Википедии и его биография на официальном сайте компании, – это должно было находиться вверху поисковой выдачи. Если какая-то страница низкого качества выходила в топ, одним из способов исправить это могло бы стать добавление правила «для запроса «Питер Норвиг» не позволять такой-то странице выходить в топ-10». Google решил не делать этого, а искать корень проблемы. В этом случае решением могло стать нечто вроде «при поиске любого известного человека отдавать предпочтение высококачественным энциклопедическим источникам (например, Википедии)».
Функция приспособленности Команды качественных поисковых запросов Google всегда была актуальной: нашел ли пользователь то, что искал? Один из сигналов, используемых сейчас Google, предельно ясно отражает идею – это сравнение «длинного клика» с «коротким кликом». Если пользователь переходит по первому выданному результату поиска и не возвращается, он, скорее всего, удовлетворен результатом. Если пользователь нажимает на первый результат поиска, проводит некоторое время на этой странице, а затем возвращается, чтобы щелкнуть по строке второго результата, скорее всего, он не совсем удовлетворен. Если пользователи возвращаются сразу же, это сигнал того, что они увидели совсем не то, что искали, и так далее. Если «длинный клик» отмечается на втором, или третьем, или на пятом результате чаще, чем на первом, возможно, этот результат наиболее актуален. Когда один человек делает это, это может быть случайностью. Когда миллионы людей делают один и тот же выбор, это, безусловно, сообщает вам нечто важное.