8. Джини — нові трудові ресурси
У 2016 році видання MIT Sloan Management Review попросило мене написати есе про майбутнє менеджменту. Спершу я відмовився: мовляв, не знаю, про що писати, бо й без мене вже давно все сказано. Та потім я збагнув, що застряг на старій мапі.
Якщо розглядати питання з погляду уявлень ХХ століття, складається враження, що десятки тисяч розробників софту в компаніях Google, Amazon і Facebook тільки й роблять, що «штампують» продукцію, точнісінько так само, як промислові попередники. От тільки нині виробляють софт, а не реальні товари. Та, якщо поглянути на ці компанії очима людей ХХІ століття, стає зрозуміло, що більшість завдань (пошукові системи; новини й інформація, оновлення статусів у соціальних мережах, підбір товарів, що купуються онлайн; виклик автомобілів за запитом) виконують програми й алгоритми. Програми — це працівники, а програмісти, які їх створюють, — менеджери. Щодня «менеджери» отримують фідбек про роботу «працівників», тобто ринкові дані в реальному часі. Коли треба, «менеджери» теж дають фідбек «працівникам» у вигляді тонких налаштувань й оновлень у програмах чи алгоритмах.
Завдання, які виконують працівники-програми, відображають схему роботи цифрової організації. Уявімо таке: на сайті інтернет-магазину один електронний працівник допомагає покупцеві знайти товар, що відповідає запиту. Другий видає опис товарів із каталогу. Третій пропонує інші варіанти. Коли клієнт визначився з товаром, четвертий цифровий працівник видає онлайн-форму, вимагаючи оплати й перевіряючи введені дані (наприклад, чи дійсна кредитна картка або чи відповідає введений пароль збереженому в системі). П’ятий цифровий працівник оформляє замовлення і додає його до облікового запису клієнта. Шостий працівник формує перелік замовлених товарів, який обробить людина або робот. Сьомий працівник зберігає дані про транзакцію в обліковій системі компанії. Восьмий надсилає клієнтові емейл, підтверджуючи замовлення.
З обчислювальною технікою старого покоління всі ці операції виконувала одна монолітна програма, яка обробляла запити одного користувача. А от сучасні веб-додатки можуть одночасно обслуговувати мільйони користувачів. Функції таких додатків розподілені на такі собі «мікросервіси» — добірки окремих функціональних модулів, кожний з яких робить щось одне, але дуже добре. Якщо традиційну монолітну програму, як-от Microsoft Word, задіяти як низку мікросервісів, спелчекер можна замінити на кращий або додати новий сервіс, який автоматично переадресовує з посилань у зноски чи навпаки.
Мікросервіси — це результат еволюції розробки софту, заснованої на комунікації (за такою схемою розробляли Unix та інтернет, а також платформу Джеффа Безоса). Для мікросервісів головне — вхідні та вихідні дані, тобто взаємодія з іншими сервісами, а не внутрішня функціональність. Вони можуть бути написані різними мовами програмування і запускатися на багатьох комп’ютерах. Якщо мікросервіс належно запрограмовано, у нього легко додати вдосконалений компонент, що виконує ту саму функцію й не вимагає оновлення всієї програми. Завдяки цьому процес розробки є безперервним: можна постійно додавати нові фічі, ніж проводити кардинальне оновлення час від часу; можна застосовувати A/B-тестування, випробовуючи різні версії однієї фічі на певних групах користувачів.
Незбагненна ефективність даних
Разом із розвитком інтернет-додатків змінювалися й програми-працівники. Це нагадує зрушення в аеронавтиці: від пропелерів до реактивних двигунів. Великої швидкості можна було досягти лише з двигуном на механічному поршні й рухомих деталях, тому вимагалася радикальна зміна підходу — безпосереднє згоряння пального. Для більшості програм «реактивний двигун» починався з прикладної статистики і теорії ймовірностей, а не з машинного навчання й удосконалених алгоритмів штучного інтелекту.
2006 року Роджер Маґулас, директор із дослідження ринку O’Reilly Media, уперше вжив термін «великі дані» стосовно нових інструментів управління даними такого масштабу, якого вимагають сервіси рівня Google. Колишній дослідник Bell Labs Джон Меші вживав цей термін ще 1998 року, але стосовно зростання обсягу даних, які збиралися й зберігалися, а не щодо сервісів, які використовують великі масиви даних і статистику, і не щодо розробки програмного забезпечення чи бізнес-процесів, на яких базуються ці сервіси178.
