Чоловік моєї племінниці Пітер Кромгаут служив капітаном піхотинських військ Збройних сил США в Афганістані, тож я знаю про підхід генерала з перших вуст. «До Маккрістала нам давали місію. Ми висаджувалися, але зявлялися нові дані, що вимагали термінового реагування. Ми звязувалися з базою, щоб отримати нові інструкції,розповів Пітер.До того часу, як надходила відповідь, ситуація могла знову змінитися. Коли ж запровадили Доктрину Маккрістала, ми висаджувалися, бачили, що місія змінилася, і повідомляли базі про відповідні дії».
Підхід «навиворіт» орієнтований на результат й означає, що команда обіцяє результат і не зобовязується зробити це певним чином. Так само як солдатам в Афганістані, розробникам інтернет-сервісів потрібна автономність, щоб маневрувати за умов, які стрімко змінюються.
Високий рівень автономності дає змогу розвязувати непередбачувані конфлікти між командами. У книжці «Шлях Amazon» (The Amazon Way) колишній віце-президент компанії Джон Россмен розповідає, як компанія запозичила цей підхід з японської системи ощадливого виробництва «андон». Виявивши проблему на конвеєрі, будь-який робітник заводу Toyota може потягнути за мотузку, зупинити процес і подати сигнал керівництву ліхтариком (андоном). Як пише Россмен, коли в Amazon зявилася «мотузка андон», «клієнти скаржилися на якийсь дефект товару, служба підтримки клієнтів вилучала його з сайту і надсилала продавцеві повідомлення приблизно такого змісту: Поки не виправите дефекту, продавати товар не можна»142.
«Система андон була запроваджена в Amazon після того, як Джефф зробив для себе відкриття, випробувавши Звязок із клієнтами. Це в компанії такий механізм, що допомагає орієнтуватися на клієнта»,розповіла Кім Рахмелер. На той час кожний менеджер сьомого рівня й вище мав що два роки практикуватися в службі підтримки клієнтів. Це стосувалося й Джеффа Безоса. У рамках програми менеджер під егідою представника клієнтської служби відповідав на кілька дзвінків від клієнтів.
Кім згадувала, як Джефф прийняв дзвінок: «Доброго дня! Мене звуть Джефф Безос, чим можу допомогти?. Клієнт не зрозумів, із ким говорить, і заходився пояснювати проблему: мовляв, отримав стіл, а стільниця пошкоджена. Із допомогою представника клієнтської служби Джефф організував заміну товару. Коли розмова завершилася, представник зазначив: Цей стіл завжди привозять пошкодженим. Очевидно, під час доставки щось стається через невдале пакування. Джефф довідався, що працівники служби підтримки клієнтів володіють цінною інформацією, яка не доходить до відділу роздрібної торгівлі. Отож він запропонував використовувати механізм, подібний до мотузки андон, і відтоді система змінилася».
Мотузка «андон» втілює головний принцип системи «обіцяних результатів». Надсилає простий сигнал усім учасникам робочого процесу і різко контрастує з традиційним підходом до менеджменту. Кожна група працівників має власну «функцію пристосування» і весь час її оптимізує; функції груп часом суперечать одна одній; «функцію пристосування» будь-якої групи можна перевірити за допомогою такої самої функції іншої групи. Вдалий менеджментце координація функцій, завдяки якій уся компанія рухається в правильному напрямку і має спільну «функцію пристосування».
В IT-компаніях, де панує культура автономності, поширені літучки. Ці короткі зустрічі проводяться щодня, зазвичай стоячи, і сприяють тому, що працівники діють разом заради спільної мети, тримаючи один одного в курсі про виконання «обіцянок».
Якщо організація працює незлагоджено, літучкичудове рішення. Вони допомагають зясувати, що пішло не так, і запровадити нові системи комунікації.
Майкі Дікерсонколишній інженер Google, якого восени 2013 року Білий дім запросив рятувати невдалий сайт healthcare.gov143. Пізніше Майкі став директором новоствореної Цифрової служби США. Він розповів мені, як завдяки літучкам усього за сто днів налагодив взаємодію підрядників Білого дому так, що провальний сайт запрацював. Зустрічі проходили приблизно в такому форматі:
Джо, ти обіцяв на сьогодні підняти три додаткових сервери. Що там із цим?
Майк ще не скинув мені параметри доступу.
Майку, в чому річ?
Я не отримував від Джо запиту на доступ.
Та як це, Майку? Дивися, ось моє повідомлення.
Слухай, Джо. У мене тут список усіх запитів, і від тебе нічого!
Ось так «Джо» і «Майк», які працювали на різних підрядників (до розробки сайту healthcare.gov залучили 33 компанії і підписали 60 різних угод144), зясовували, що користувалися різними системами відстеження робочих завдань. Виходило, що команди розробників надсилали запити в нікуди й марно сподівалися, що колеги виконають завдання. Не розуміючи взаємозалежності, учасники процесу зайшли в глухий кут: кожна команда, не в змозі продовжувати, чекала результатів від іншої.
За рахунок веб-сервісів, API, систем відстеження робочих завдань чи багів схема роботи «Обіцяні результати» в будь-якому разі забезпечує належний рівень автономності працівників. Адже кожний автономний учасник процесу особисто дає обіцянки і відповідає за їхнє виконання.
Усівсередині програми
Новий підхід до розробки програмного забезпечення вплинув і на роботу компаній. Раніше метою девелоперів був кінцевий продукт: скажімо, «вихідний еталон» наступної версії Microsoft Windows, яку розробляли протягом кількох років, а в день випуску заливали на мільйони CD-ROM і розповсюджували серед десятків тисяч роздрібних продавців і корпоративних клієнтів. Та згодом розробка софту стала безперервним процесом, спрямованим на поступове вдосконалення продукту.
Добре памятаю слова Марка Луковскі, колишнього провідного інженера Microsoft, про те, як змінилася його робота після переходу в Google: «Я щось змінюю і відразу скидаю оновлення мільйонам користувачів онлайн». Марк говорив про кардинальну трансформацію в розробці ПЗ за доби хмарних технологій. Жодних «вихідних еталонів». Нині софт завжди в розробці, програмісти крок за кроком вносять значні чи незначні зміни. Із погляду компанії, яка надає послуги онлайн, софт перетворився з продукту на процес, а врешті й на потік бізнес-операцій. Ті операції треба оптимізовувати не тільки для девелоперів софту, а й для користувачів, бо ті запускають програми, які оновлюються мало не щодня.
Тепер компаніягібридний організм, сформований із людей і машин. Я поділився цією ідеєю зі співробітниками Amazon 2003 року. Розповів їм про механічного турка, який грав у шахи. Автоматизованого шахіста сконструював Вольфґанґ фон Кемпелен. Наприкінці XVIIIна початку XIX століття диво показували по всій Європі. Турок дивував і перемагав таких видатних людей, як Наполеон і Бенджамін Франклін. Насправді ж робот був ілюзією: усередині ховався справжній чемпіон із шахів; спеціальні лінзи дозволяли бачити дошку, а важелірухати руками «автоматизованого» гравця. На мою думку, це чудова метафора для аналізу нового покоління веб-додатків.
Співробітникам Amazon я нагадав: програмине просто софт, а ще й стрімкий потік контенту, який безперервно створює мережа постачальників і підтримується відгуками, рейтингами та іншими видами зворотного звязку з широкою мережею клієнтів. Усі поповнення контенту форматуються, обробляються й розширюються зусиллями персоналу компанії (редакційні огляди, оновлення, програмування). Динамічним потоком контенту щодня управляють працівники Amazon. Пригадую, я сказав слухачам: «Усі випрограмісти, дизайнери, контент-менеджери, менеджери продукту, покупці, представники служби підтримки клієнтівусередині програми».
Пізніше я собі гадав, що, розповівши ту історію на лекції, надихнув творців служби Amazon Mechanical Turk (Механічний турок), яка за допомогою краудсорсингової мережі працівників виконує дрібні, але складні для компютерів, завдання. Та, виявилося, хоч служба запрацювала 2005 року, заявку на відповідний патент Amazon подала ще 2001-го (щоправда, отримала патент лише 2007-го). Принаймні я сподіваюся, що підказав компанії влучну назву, а запатентували розробку за назвою «Хунта»145.
До ідеї про те, що, розробляючи інтернет-сервіси, девелопери перебувають «усередині програми», я дійшов поступово. Спершу намагався зрозуміти, чому програмування мовою Perl так багато важило в часи зародження веб-технологій.