Споживачі відразу пожвавилися. Завдяки низьким цінам і великим масштабам 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.
Декому з читачів може здатися, що це якось не по-людськипорівнювати людей із гвинтиками в механізмі! Утім зовсім навпаки. Насправді не по-людськи влаштована традиційна командно-адміністративна організація, де треба коритися наказам, не розуміючи навіщо й заради чого. На думку Кім Рахмелер, яка впродовж багатьох років очолювала службу підтримки клієнтів Amazon, «клієнтський досвід користувачів сервісів цілковито залежить від команди», яка розробляє інтерфейс для доступу до своїх сервісів. Виникає ланцюгова реакція між командою розробників і користувачами, завдяки якій у розробці нових функцій керівництво може покладатися на творчий підхід і досвід команди.
Кім пояснила, що «прес-релізце механізм, який конкретизує орієнтацію на клієнта». Таку саму роль відіграють команди «на дві піци», які розробляють кращі API. «Компанії Amazon більше, ніж будь-якій іншій компанії, такі механізми допомагають реалізувати корпоративні цінності,додала Кім.Більше, ніж будь-хто з конкурентів, Amazon будує роботу на першочергових принципах (цінностях)».
Музичний сервіс Spotifyще одна компанія, яка налагоджує взаємозвязок між онлайн-сервісом й організаційною структурою. Компанія розвинула досить впливову культуру. В анімованих відеороликах Spotify наголошує на двох аспектах: узгодженості й автономності139. Традиційні організації дбають про узгоджену роботу, але нехтують автономністю: керівники кажуть підлеглим, що і як робити. Тому в організаціях такого штибу (у коміксі Dilbert на них опублікували пародію) ані керівник, ані працівники й гадки не мають, навіщо їм те чи інше завдання. Це компанії з низьким рівнем узгодженості та автономності140. Сучасна високотехнологічна організація (або компанія типу Amazon чи Spotify) прагне налагодити узгоджену й автономну діяльність працівників. Кожному відома мета діяльності, але дійти до неї можна власним шляхом.
Схожий підхід спричинив революцію у військовій справі. «Революціонером» був генерал Стенлі Маккрістал в Афганістані, де в зоні бойових дій швидко змінювалися умови. Я слухав презентацію генерала на саміті New York Times «Нова робота» (New Work) влітку 2016 року і почув такі слова: «Я своїм людям кажу: Не виконуйте моїх наказів. Виконуйте накази, які я дав би вам, якби був поруч і знав те, що знаєте ви»141. Тобто Маккрістал хотів, щоб солдати розуміли спільну мету підрозділу і приймали доцільні рішення, які допоможуть її досягти.