Принципы умного самоуправления для платформ

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

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

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

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

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

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

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

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

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

6. Всякий, кто этого не сделает, будет уволен.

7. Спасибо, всем хорошего дня!

Строгому применению этого принципа прозрачности обязана своим успехом Amazon Web Services (AWS), гигантский облачный сервис платформы компании. Эндрю Джасси, вице‑президент по технологии, наблюдал за тем, как различные подразделения Amazon были вынуждены развивать сетевые сервисные операции, чтобы сохранять, находить и передавать данные[163]. Джасси требовал, чтобы эти проекты могли объединяться в единый процесс с одним чистым, гибким и универсальным набором протоколов. Решение этой задачи сделало обширную базу данных Amazon доступной и полезной всем в компании.

А главное, Джасси признал, что решение этой проблемы может иметь более масштабные последствия. Он пришел к выводу, что если многочисленные подразделения внутри Amazon решат эту задачу, то созданный надежный сервис управления данными может быть полезен внешним компаниям со схожими потребностями. Так родился AWS — один из первых бизнесов, предлагающих облачное хранение данных и услуги менеджмента компаниям, сталкивающимся с проблемой обработки массивов данных. Благодаря идеям Джасси сегодня AWS имеет больше рыночных возможностей, чем следующая за ним дюжина облачных сервисов, вместе взятых[164].

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

Хороший отрезвляющий пример — корпорация Sony. Плееры Walkman доминировали на рынке с 1970‑х. В 2007 г., когда появился Apple iPhone, положение Sony в мире электронных устройств казалось непоколебимым. У Sony были MP3‑плеер мирового уровня, передовая модель электронной книги, и она выпускала одни из лучших фотоаппаратов. Осенью того же года Sony представила новое поколение PlayStation Portable (PSP), лучшее игровое устройство в мире. Sony даже принадлежали кино— и телестудия Time Warner, что позволяло компании предлагать уникальный контент. И несмотря на эти преимущества, Sony так и не догадалась создать платформу. Вместо этого компания трудилась над отдельными линейками продуктов и сосредоточивалась на индивидуальных системах.

Изолированное видение бизнеса Sony помешало ей создать единую платформенную экосистему. Спустя несколько лет Apple iPhone и приложения, построенные на его растущей платформе, заполонили рынок. Через два года после кризиса 2008 г. цена акций Sony все еще была почти на треть ниже предшествовавшей, а цена акций Apple взлетела на исторический пик.

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

В своей книге «Лидерство платформ» Аннабель Гоуэр и Майкл Кусумано предлагают яркий пример того, как предоставление права голоса партнерам может стать отличным вариантом управления платформой. Экосистема, построенная вокруг универсальной шины (USB), продвигаемой Intel, была одним из первых стандартов облегчения передачи данных и заряда между периферийными устройствами — клавиатурами, картами памяти, мониторами, камерами, роутерами и т. д. — и компьютерами. Однако создание периферийных устройств выходило за пределы бизнеса Intel по производству интегральных микросхем[165]. Intel столкнулась с особенно острым случаем «проблемы курицы и яйца» при запуске платформы (см. главу 5). Никто не захочет создавать периферийные устройства для компьютерного стандарта, который никто не признал, и никто не захочет покупать компьютер, для которого нет периферийных устройств. Потенциальные партнеры‑производители сомневались, связываться ли с Intel: как владелец стандарта она имела возможность в будущем изменять его, что могло сделать конкурирующие товары несовместимыми и тем самым лишить партнеров выгоды от вложений в долгосрочной перспективе.

Intel разрубила гордиев узел, доверив USB своему подразделению лабораторий архитектуры Intel (IAL). Как новый департамент IAL не подпадала под власть какой‑либо внутренней производственной линии. Он служил нейтральным посредником между партнерами экосистемы и внутренними подразделениями и решить проблему мог только благодаря своей независимости. IAL заработал доверие партнеров, защищая и внедряя практики, которые улучшили здоровье экосистемы, пусть даже порой за счет подразделений Intel. В течение года команда IAL посетила более 50 компаний, прося их помочь в создании лицензии стандарта и дизайна, чтобы успокоить потенциальных партнеров. Благодаря IAL Intel удалось не разрушить партнерские рынки. Intel использовала свою репутацию и заключение договоров, чтобы ограничить собственные перспективы (см. врезку о правилах самоуправления IAL).