У мене тоді була одна традиція. Наприкінці дня в пятницю я завжди виставляв у своєму кабінеті вино та пиво, щоб усі члени команди могли розслабитись і неформально поспілкуватися після важкого тижня. На ці посиденьки я запрошував також моїх сусідів робототехніків, і однієї пятниці до мене завітав Родні Брукс. Цей викладач штучного інтелекту МТІ був одним із засновників компанії. Я спитав його, як працюють ці бродячі роботи.
«Ми десятками років намагалися створити дійсно розумну машину, сказав він мені. Витратили мільярди доларів і багато-багато років праці, збудувавши найбільші компютери, які тільки могли, з найбільшими базами даних, але отримали лише компютер, здатний обіграти людину в шахи».
Він пояснив, що до його роботів застосовується зовсім інакший підхід. Замість спроб побудувати щось із одним-єдиним центральним мозком, вони збудували робота, у якого кожна із шести ніг мала власний мозок. Процесор у спині мав лише кілька простих правил: уперед, назад, не наступати на інші ноги. Чип нейронної мережі в голові робота контролював дотримання цих правил і діяв як рефері для всіх частин. Він повідомляв ногам про те, що бачив крізь свою камеру, коли натикався на перешкоду, та й усе.
За словами Брукса, цікавим було те, що кожного разу, коли робота вмикали, він учився ходити заново. У нього не було бази даних про розташування інших предметів у кімнаті. Натомість його базою даних був сам світ. Кожного разу після вмикання він визначав розташування інших предметів, немов уперше. Натикався на речі й сприймав їх як реальне оточення, що означало його здатність адаптуватися до будь-якого середовища.
За словами Брукса, цікавим було те, що кожного разу, коли робота вмикали, він учився ходити заново. У нього не було бази даних про розташування інших предметів у кімнаті. Натомість його базою даних був сам світ. Кожного разу після вмикання він визначав розташування інших предметів, немов уперше. Натикався на речі й сприймав їх як реальне оточення, що означало його здатність адаптуватися до будь-якого середовища.
«Давайте я вам покажу», сказав Брукс, затягнувши мене до їхньої лабораторії. Він сунув чистий нейронний чип в одного комахоподібного робота, і я побачив, як той оживає. Спочатку робот невпевнено заспотикався кімнатою, наче новонароджене теля, яке вперше намагається стати на ноги. З кожним кроком він ставав усе впевненішим. Ноги швидко вчилися співдіяти. Уже через декілька хвилин робот бігав навколо. Його вміння ходити не було ані збереженим, ані запрограмованим. Усі складники працювали разом за рахунок кількох простих функцій. Ці ноги не думали, а просто діяли. Я був надзвичайно вражений геніальністю та простотою цієї системи. Тут було щось, що робило саме те, чого мене вчили робити, коли я літав над Вєтнамом: Оглядати, Орієнтуватись, Вирішувати й Діяти. Цей робот був інтегрований у довкілля й рішуче діяв на основі даних із довкілля.
А що б сталося, спитав я Брукса, якби ми змогли розробити набір простих інструкцій для груп людей працювати разом, точно як оці ноги? Вони б самоорганізувались та самооптимізувались, як і цей робот?
Не знаю, відповів він. Чому б вам не спробувати це й не повідомити мені, що із цього вийшло?
Не женіться за каскадною моделлю
Я дедалі краще розумів: якщо зможу створити систему, яка, подібно до цього робота, координуватиме незалежні центри рішень із постійним відгуком про стан справ, буде досягнуто значно вищих рівнів продуктивності. Розподіляючи потік інформації між «ногами» групи, можна буде досягти ефективності, якої раніше не досягав ще ніхто.
Моя розмова з Родні Бруксом відбулася понад два десятиліття тому. Протягом багатьох років він був завідувачем кафедри робототехніки та штучного інтелекту МТІ, а той схожий на павука робот, якого я бачив, на прізвисько Чингізхан, тепер зберігається в музеї Смітсонівського інституту. Сьогодні ви, мабуть, чули про одну з компаній Брукса iRobot, що виробляє пилосос Roomba та використовує для прибирання ваших кімнат той самий адаптивний інтелект, який Чингізхан використовував, щоб ганятися за мною по кабінету. Його остання новинка в Rethink Robotics, робот Бакстер, може успішно співпрацювати з людьми в спільному робочому просторі.
Праця Брукса мене надихнула. І в 1993 році я приніс ці ідеї із собою в компанію Easel, куди мене запросили на посаду віце-президента з обєктних технологій. Керівництво Easel хотіло, щоб моя команда за шість місяців розробила абсолютно нову серію продуктів для деяких із їхніх найбільших клієнтів, таких як Ford Motor, які використовували їхнє програмне забезпечення в проектуванні та створенні власних додатків. Я сів порадитись зі своїми розробниками й сказав їм, що, на мою думку, вони не зможуть цього зробити за допомогою старого способу розробки програмного забезпечення.
Тією старою методикою була каскадна модель, яку я вже описував у попередньому розділі: усе, що стосується проекту, ретельно зображувалося на масштабних діаграмах Ґантта, кожне завдання точно оцінювалось у годинах і виділялося симпатичними кольорами, що стікали сторінкою, немов каскад. Ці діаграми здавалися дуже гарними й точними, але були цілковитою нісенітницею.
Я знав, що в Easel каскадна модель викине нас за межі дедлайнів на місяці, якщо не роки. Ми мали розробити зовсім інакший спосіб управління проектами. Я пішов до генерального директора і сказав, що діаграми Ґантта не для нас. Він був шокований і вимагав пояснити чому.
Скільки діаграм Ґантта ви бачили за свою карєру? спитав я.
Сотні, сказав він.
А скільки з них справдилися?
Жодної, відповів він після паузи.
Саме тоді я й пояснив йому, що збираюся презентувати наприкінці місяця робоче програмне забезпечення, а не невиконану діаграму Ґантта. Він зможе випробувати його сам і переконатися, що ми на правильному шляху. Ми маємо спробувати це, якщо хочемо вкластись у відведені строки.
Кілька тижнів ми з командою витратили на читання сотень документів, книжок та статей з організації команд і розробки продукту. А потім один розробник якось приніс статтю з Harvard Business Review від 1986 року, написану двома японськими викладачами економіки Гіротакою Такеучі та Ікуджиро Нонакою. Вона називалася «Розробка нового продукту. Нові правила гри». Такеучі та Нонака вивчали команди кількох найбільш продуктивних та інноваційних компаній світу: Honda, Fuji-Xerox, 3M, Hewlett-Packard та інших. Вони стверджували, що старий спосіб розробки продукту, заданий фазовою системою планування програм NASA, каскадна модель дефектний у своїй основі. Натомість найкращі компанії використовують ступеневий процес розробки, який є швидшим та гнучкішим. Ці команди мають різнопрофільних фахівців, автономію та взаємопідтримку. При цьому вони ставлять перед собою мету вийти за межі досягнутого раніше. Вони прагнуть чогось більшого за самих себе. Менеджмент не диктує їм, що робити. Навпаки, керівники компаній виступають у ролі лідерів-слуг та посередників, зосереджених на прибиранні перешкод зі шляху їхніх команд, а не на вказівках, котрий продукт розробляти і як. Японські викладачі порівнювали робочий процес із грою в регбі й казали, що найкращі команди діють так, немов гуртуються задля досягнення спільної мети, що й називається Scrum: «мяч пасується всередині команди, яка рухається полем як єдине ціле»[6].
Саме тоді я й пояснив йому, що збираюся презентувати наприкінці місяця робоче програмне забезпечення, а не невиконану діаграму Ґантта. Він зможе випробувати його сам і переконатися, що ми на правильному шляху. Ми маємо спробувати це, якщо хочемо вкластись у відведені строки.
Кілька тижнів ми з командою витратили на читання сотень документів, книжок та статей з організації команд і розробки продукту. А потім один розробник якось приніс статтю з Harvard Business Review від 1986 року, написану двома японськими викладачами економіки Гіротакою Такеучі та Ікуджиро Нонакою. Вона називалася «Розробка нового продукту. Нові правила гри». Такеучі та Нонака вивчали команди кількох найбільш продуктивних та інноваційних компаній світу: Honda, Fuji-Xerox, 3M, Hewlett-Packard та інших. Вони стверджували, що старий спосіб розробки продукту, заданий фазовою системою планування програм NASA, каскадна модель дефектний у своїй основі. Натомість найкращі компанії використовують ступеневий процес розробки, який є швидшим та гнучкішим. Ці команди мають різнопрофільних фахівців, автономію та взаємопідтримку. При цьому вони ставлять перед собою мету вийти за межі досягнутого раніше. Вони прагнуть чогось більшого за самих себе. Менеджмент не диктує їм, що робити. Навпаки, керівники компаній виступають у ролі лідерів-слуг та посередників, зосереджених на прибиранні перешкод зі шляху їхніх команд, а не на вказівках, котрий продукт розробляти і як. Японські викладачі порівнювали робочий процес із грою в регбі й казали, що найкращі команди діють так, немов гуртуються задля досягнення спільної мети, що й називається Scrum: «мяч пасується всередині команди, яка рухається полем як єдине ціле»[6].
Коли стаття Такеучі та Нонаки тільки вийшла, вона наробила галасу, але то було за сім років до того, як ми прочитали її в Easel. Усі нею захоплювались, але ніхто нічого із цим не робив. Пересічний американський менеджер був не здатний осмислити її ідеї, навіть попри те, що Toyota швидко збільшувала свою частку ринку, використовуючи цей підхід. В Easel нам не було чого втрачати. Ми вирішили спробувати, хоча стаття й описувала більше виробничу сферу, а не розробку програмного забезпечення. Я вважав, що їхні ідеї приведуть до чогось фундаментального, процедури, що описувала б найкращий спосіб співпраці людей у будь-якій сфері діяльності. Адже вони чудово вкладалися в усі інші експерименти, які я проводив іще з моєї першої роботи у приватному секторі в MidContinent.
Це стало офіційним народженням Scrum. Ми здали готовий продукт вчасно, ще до закінчення шести місяців, не перевищивши бюджет і з меншою кількістю помилок, ніж у будь-якому попередньому замовленні.
Можливості цієї нової форми управління проектами так мене надихнули, що вся моя майбутня робота зосередилась на вдосконаленні Scrum для компаній. У 1995 році разом із Кеном Швабером я презентував на дослідницькій конференції Асоціації обчислювальної техніки працю під назвою «Спосіб розробки SCRUM», яка систематизувала ці практики. Після того ми відмовилися від слів великими літерами та дещо допрацювали цю ідею, але основні принципи залишаються незмінними; а компанії, які прийняли цей спосіб, зазвичай отримують негайні переваги[7].