ХЗ. Хто знає, яким буде майбутнє - Тім О’Райлі

6. Тих, хто порушить це правило, буде звільнено134.

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

Отож протягом наступних кількох років Amazon переформатувала систему: було створено комплекс фундаментальних сервісів (зберігання, обчислювання, очікування тощо), до яких девелопери компанії мали доступ через стандартизовані програмні інтерфейси. До 2006 року ці сервіси були достатньо надійними, гнучкими, із чітко визначеними інтерфейсами, і їх можна було пропонувати клієнтам Amazon.

Споживачі відразу пожвавилися. Завдяки низьким цінам і великим масштабам Amazon швидко опанувала ринок. Компанія суттєво обмежила бар’єри для стартапів (дала можливість експериментувати з новими ідеями), забезпечивши стабільність та ефективність висококласної інтернет-інфраструктури. Для цього знадобилися мінімальні зусилля — усього лише самотужки побудувати інфраструктуру. Тривалий інтернет-бум останнього десятиліття пояснюється стратегічним рішенням Amazon про будівництво власної інфраструктури, яка буде відкритою для світу. Йдеться не тільки про стартапи. Великі компанії, як-от Netflix, розміщують свої сервіси, послуговуючись AWS. Нині цей бізнес приносить 12 мільярдів доларів на рік.

Microsoft, Google і багато інших компаній намагаються наздогнати успішного конкурента у хмарному просторі, але запізно. Amazon мала одну велику перевагу. Про неї Джефф розповів мені невдовзі після того, як 2006 року Amazon офіційно представила хмарні сервіси: «Я починав із роздрібної торгівлі. Це напрочуд малоприбутковий бізнес. Тож нижче скотитися ми не могли. А от Microsoft і Google починали з високої планки, тому в них завжди є загроза занепаду». На той час, як Microsoft і Google усвідомили розмах бізнесу у хмарних технологіях, вони вже безнадійно відстали.

Найголовніший висновок про сутність мережевих організацій слід шукати серед підказок компанії Amazon, яка сформувала внутрішню структуру так, щоб мати орієнтовану на сервіси платформу. Технічний директор Amazon Вернер Воджелс писав 2006 року у блозі: «У сервісах відображається не тільки структура програмного забезпечення, а й структура самої організації. У сервісів чітко визначене право власності, і розробляють їх нечисленні команди, а це створює сприятливі умови для інновацій. Певною мірою сервіси — ніби маленькі стартапи у великій компанії. Кожний чітко орієнтується на своїх користувачів, байдуже зовнішніх чи внутрішніх»135.

Розробку здійснюють команди з кількох фахівців. (Amazon називає таку форму роботи «командою на дві піци»: учасників так мало, що достатньо замовити дві піци). Команди працюють незалежно одна від одної, починаючи з високорівневого опису завдань. Будь-який проект Amazon розробляють за оберненою схемою. Як відомо, компанія зосереджена на клієнтах, тому починає з прес-релізу, де пояснює, як і чому робитиме готовий продукт. (Якщо це сервіс або продукт для внутрішнього використання, «клієнтом» слугує інша команда).

Потім публікуються «Найпоширеніші запитання та відповіді». Amazon створює макети і визначається з клієнтським досвідом. Розробники навіть пишуть інструкцію з експлуатації, де пояснюють, як користуватися майбутнім продуктом. Тільки після цього керівництво дає «зелене світло». Розробка здійснюється в кілька етапів: враховуються додаткові дані, отримані від користувачів під час створення й тестування продукту. Та все починається з обіцянки про кінцевий продукт.

Фахівець у галузі інформатики й управління комп’ютерами Марк Бурджесс називає такий підхід «Обіцяні результати». Він пише: «У кулінарних книжках на кожній сторінці спочатку обіцяють гарний результат (спокусливе зображення страви), а вже потім дають рецепт, як приготувати таку красу. Кулінари не просто підкидають рецепт, змушуючи вас сумлінно виконувати вказівки й довіряти авторові. Спершу вони показують, на що сподіватися. А в програмуванні й управлінні комп’ютерами ми не завжди даємо користувачам таку змогу»136.

Звісно, прес-реліз (чи зображення страви за рецептом) — це лише перший етап робочого процесу за принципом «обіцяні результати». Далі треба пройти зворотний шлях від обіцянки клієнтам до обіцянки, яку кожна ланка організації дає одна одній, і зрештою досягнути поставленої мети. Багато важать у цьому процесі маленькі команди, а також єдина, чітко визначена «функція пристосування» для кожної з них (головне завдання, яке команда обіцяє виконати; результат, який можна оцінювати і вдосконалювати).

На зустрічі топ-менеджерів Amazon пролунала пропозиція поліпшити комунікацію між командами, і от досі переповідають, як Джефф Безос відповів: «Ні-ні, комунікація — це жахливо!»137. Чому він так сказав? Боявся, що буде, як у давньому анекдоті: «Один чувак сидить і випиває. Двоє сидять, чокаються і випивають. Що більше чуваків, то більше чокаються й випивають». Отож в організації треба налагодити взаємодію так, щоб працівники «чокалися» лише з тими, чия робота перетинається з їхньою, а не бозна з ким. Проста арифметика: що більша команда, то гірша комунікація між працівниками.

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

Тепер зрозуміло, чому Джефф забороняє PowerPoint і вимагає, щоб усі пропозиції й презентації оформлювалися письмово. Працівники висувають ідеї й наводять аргументи, уникаючи штучного спрощення усталених ієрархій. Як зазначив Білл Джейнвей, Джефф «хотів плідних і відкритих дискусій у процесі прийняття рішень і добре структурованих комунікацій під час виконання завдань».

За Бурджессом, підхід «Обіцяні результати» допомагає зрозуміти, як незалежні учасники робочого процесу обмінюються обіцянками — це основа добре структурованої комунікації. Учасниками можуть бути модулі програмного забезпечення, які обіцяють реагувати певним чином на запит API, або маленькі команди, які обіцяють певний результат. Бурджесс пише: «Уявіть низку принципів, що підказують, як окремі частини поєднуються й утворюють ціле і як кожна частина бачить ціле. Якщо це вдалі принципи, байдуже, до якої взаємодії їх застосовувати: між людьми в команді, між птахами у зграї, між комп’ютерами в датацентрі чи між гвинтиками у швейцарському годиннику. Теорія співпраці — досить універсальна, а отже, доречна і в технологіях, і у відносинах між колегами»138.

Декому з читачів може здатися, що це якось не по-людськи — порівнювати людей із гвинтиками в механізмі! Утім зовсім навпаки. Насправді не по-людськи влаштована традиційна командно-адміністративна організація, де треба коритися наказам, не