ХЗ. Хто знає, яким буде майбутнє - Тім О’Райлі
Короткий екскурс в історію засвідчує, як легко сплутати мету й засоби. Якщо проблему визначено так: «розвантажити дороги та мати відповідальніших візників» (за версією Карла I), то здається, що обмеження кількості ліцензій збігається з першочерговою метою — менше заторів і чистіше повітря. (За тих часів, кінський гній був таким самим лихом, як смог у ХХ столітті). Якщо надлишкова пропозиція, як підкреслив представник Мінтранспорту 1933 року, призвело до тарифних війн і не давало таксистам заробляти (користуватися таксі стало небезпечно, і водії їздили без страховок), то здається, що мета влади — зменшити кількість водіїв і запровадити обов’язкові перевірки. Проте «світ змінився» (чи як там було в «Темній вежі» (Dark Tower) Стівена Кінґа?), і тепер знайдуться кращі рішення.
Ми й досі ризикуємо натрапити на поганих водіїв. Противники Uber за нагоди нагадують про злочини, скоєні водіями компанії. Та все ж будь-який автомобіль Uber чи Lyft, пересування якого відстежується в реальному часі і який дозволяє зберігати важливі дані, як-от точний час, пункт призначення і маршрут поїздки, а також імена та прізвища водія і пасажира, є, безсумнівно, безпечнішим за таксі. Крім того, після кожної поїздки водій і пасажир оцінюють один одного, і поступово відсіюються люди, які не вписуються в систему. Гел Варіан наголосив, що транспортні й інші комп’ютерні транзакції кардинально змінюють правила гри у сфері нагляду: «Транзакція моніториться від початку до кінця. Коли щось не так, можна скористатися збереженими записами й розібратися»214.
Стосовно заторів: якщо нині алгоритми оптимізовані так, щоб максимально скоротити час очікування для пасажирів, чому б програмам не враховувати інших факторів, що поліпшують клієнтський досвід і зменшують вартість послуг (наприклад, розраховувати, скільки треба автівок у години-пік, щоб час очікування виклику не збільшувався, але й не утворювалися затори)? Насправді алгоритмічні диспетчери й маршрутизація тільки починають розвиватися, бо інакше й еволюцію пошуковика Google треба було вважати завершеною ще 1998 року, коли винайшли PageRank. Для мультифакторної оптимізації компанії Uber та Lyft повинні невтомно покращувати алгоритми, враховуючи потреби всіх зацікавлених осіб ринку. Наразі незрозуміло, чи переймаються вони цим.
Важливо розрізняти мету й засоби, адже лише так вдасться покласти край суперечкам між мережевими транспортними компаніями й органами контролю над службами таксі й лімузинів.
Обидві сторони прагнуть, щоб кваліфіковані водії безпечно перевозили кожного пасажира, який хоче викликати машину, але щоб таких водіїв було не забагато (надлишок пропонування призводить до того, що перевізники замало заробляють і не можуть утримувати автівки в належному стані). Органи державного нагляду вважають, що для цього треба обмежувати кількість водіїв і сертифікувати їх ліцензіями. Uber та Lyft певні того, що набагато ефективніше досягають тієї самої мети на ринку, яким управляють комп’ютерні системи. Без сумніву, можна було б визначити найдієвіший із двох підходів, скориставшись даними.
У Розділі 7 ми говорили, що культура й методи роботи компаній Кремнієвої долини й державних установ істотно різняться. Зокрема, у цьому й проблема. У Кремнієвій долині кожний новий додаток чи послуга починається як експеримент. Із першого дня, коли компанія отримує фінансування від венчурних капіталістів або починає працювати без фінансування, її успіхи залежать від таких ключових метрик, як адаптація користувача, кількість користувачів чи приваблення користувачів. Завдяки тому, що це онлайн-сервіси, фідбек надходить майже в реальному часі. Послуговуючись термінологією руху Еріка Ріса «Ощадливий стартап» (Lean Startup), перша версія називається «мінімально життєздатним продуктом» (MVP). Це новий продукт, який дозволяє команді зібрати максимум інформації про клієнтів, доклавши мінімум зусиль215. Мета кожного підприємця — поступовий розвиток MVP до стадії «відповідності продукту й ринку», що зрештою веде до стрімкого зростання.
Такий підхід прищеплюється кожному підприємцю в Кремнієвій долині. Запускають додаток чи послугу, і поступово додають фічі й тестують новинку. Таким чином завжди можна оцінити нові фічі: ті, що не сподобалися користувачам, мовчки прибирають або модифікують. До того ж різні версії кожної фічі — розташування або розмір кнопки, механізм повідомлення чи графіка — можна тестувати на рендомних групах користувачів і розуміти, яка версія краще працює. Розробники будують міцні ланцюги зворотного зв’язку, і ці ланцюги — ключ до успіху216.
Натомість, попри зміни за президентства Обами, про які йшлося в Розділі 7, законодавці й чиновники звикли до іншої системи: розглядаємо певну тему, вислуховуємо зацікавлених осіб на відкритих засіданнях (а часто й на приватних зустрічах із лобістами), приймаємо рішення і невідступно його дотримуємося. Оцінки результатів можуть здійснюватися (якщо взагалі здійснюються) у вигляді наукових досліджень через багато років після реалізації проекту. Очевидно, про фідбек у процесі прийняття рішень немає мови. Ось чому трапляються такі випадки: виділяють багато мільйонів доларів на розробку сайту з пошуку роботи для ветеранів, який приваблює лише кілька сотень користувачів, а угоду з розробниками все одно подовжують. Я запитав у високопоставленої чиновниці, яка відповідала за проект, чи рахували вони, у скільки обійшовся сайт на одного користувача. «О, непогана ідея!» — сказала вона. Непогана ідея? Та в Кремнієвій долині засміяли б підприємця, що не може відповісти на це запитання. На саміті Code for America 2015 року Том Лузмор, колишній операційний директор Цифрової служби Великої Британії, наголосив, що для них типовий проект нормативно-правових змін розтягується на «500 сторінок неперевірених припущень»217.
Так само відбувається в державних органах влади, коли ті беруться за технологічний проект. Пишуть довжелезні специфікації, де відображено найкращі ідеї всіх учасників, уточнюється кожнісінька деталь проекту, і тільки після цього подається заявка на фінансування. Продукт зазвичай розробляють роками, а припущення розробників уперше перевіряються, коли сервіс запущено. Може, скидається на обернену схему роботи Amazon, але насправді то зовсім