Джефф Сазерленд - Scrum. Навчись робити вдвічі більше за менший час

За словами Брукса, цікавим було те, що кожного разу, коли робота вмикали, він учився ходити заново. У нього не було бази даних про розташування інших предметів у кімнаті. Натомість його базою даних був сам світ. Кожного разу після вмикання він визначав розташування інших предметів, немов уперше. Натикався на речі й сприймав їх як реальне оточення, що означало його здатність адаптуватися до будь-якого середовища.

«Давайте я вам покажу», – сказав Брукс, затягнувши мене до їхньої лабораторії. Він сунув чистий нейронний чип в одного комахоподібного робота, і я побачив, як той оживає. Спочатку робот невпевнено заспотикався кімнатою, наче новонароджене теля, яке вперше намагається стати на ноги. З кожним кроком він ставав усе впевненішим. Ноги швидко вчилися співдіяти. Уже через декілька хвилин робот бігав навколо. Його вміння ходити не було ані збереженим, ані запрограмованим. Усі складники працювали разом за рахунок кількох простих функцій. Ці ноги не думали, а просто діяли. Я був надзвичайно вражений геніальністю та простотою цієї системи. Тут було щось, що робило саме те, чого мене вчили робити, коли я літав над В’єтнамом: Оглядати, Орієнтуватись, Вирішувати й Діяти . Цей робот був інтегрований у довкілля й рішуче діяв на основі даних із довкілля.

– А що б сталося, – спитав я Брукса, – якби ми змогли розробити набір простих інструкцій для груп людей працювати разом, точно як оці ноги? Вони б самоорганізувались та самооптимізувались, як і цей робот?

– Не знаю, – відповів він. – Чому б вам не спробувати це й не повідомити мені, що із цього вийшло?

Я дедалі краще розумів: якщо зможу створити систему, яка, подібно до цього робота, координуватиме незалежні центри рішень із постійним відгуком про стан справ, буде досягнуто значно вищих рівнів продуктивності. Розподіляючи потік інформації між «ногами» групи, можна буде досягти ефективності, якої раніше не досягав ще ніхто.

Моя розмова з Родні Бруксом відбулася понад два десятиліття тому. Протягом багатьох років він був завідувачем кафедри робототехніки та штучного інтелекту МТІ, а той схожий на павука робот, якого я бачив, на прізвисько Чингізхан, тепер зберігається в музеї Смітсонівського інституту. Сьогодні ви, мабуть, чули про одну з компаній Брукса iRobot , що виробляє пилосос Roomba та використовує для прибирання ваших кімнат той самий адаптивний інтелект, який Чингізхан використовував, щоб ганятися за мною по кабінету. Його остання новинка в Rethink Robotics , робот Бакстер, може успішно співпрацювати з людьми в спільному робочому просторі.

Праця Брукса мене надихнула. І в 1993 році я приніс ці ідеї із собою в компанію Easel , куди мене запросили на посаду віце-президента з об’єктних технологій. Керівництво Easel хотіло, щоб моя команда за шість місяців розробила абсолютно нову серію продуктів для деяких із їхніх найбільших клієнтів, таких як Ford Motor , які використовували їхнє програмне забезпечення в проектуванні та створенні власних додатків. Я сів порадитись зі своїми розробниками й сказав їм, що, на мою думку, вони не зможуть цього зробити за допомогою старого способу розробки програмного забезпечення.

Тією старою методикою була каскадна модель, яку я вже описував у попередньому розділі: усе, що стосується проекту, ретельно зображувалося на масштабних діаграмах Ґантта, кожне завдання точно оцінювалось у годинах і виділялося симпатичними кольорами, що стікали сторінкою, немов каскад. Ці діаграми здавалися дуже гарними й точними, але були цілковитою нісенітницею.

Я знав, що в Easel каскадна модель викине нас за межі дедлайнів на місяці, якщо не роки. Ми мали розробити зовсім інакший спосіб управління проектами. Я пішов до генерального директора і сказав, що діаграми Ґантта не для нас. Він був шокований і вимагав пояснити чому.

– Скільки діаграм Ґантта ви бачили за свою кар’єру? – спитав я.

– Сотні, – сказав він.

– А скільки з них справдилися?

– Жодної, – відповів він після паузи.

Саме тоді я й пояснив йому, що збираюся презентувати наприкінці місяця робоче програмне забезпечення, а не невиконану діаграму Ґантта. Він зможе випробувати його сам і переконатися, що ми на правильному шляху. Ми маємо спробувати це, якщо хочемо вкластись у відведені строки.

Кілька тижнів ми з командою витратили на читання сотень документів, книжок та статей з організації команд і розробки продукту. А потім один розробник якось приніс статтю з Harvard Business Review від 1986 року, написану двома японськими викладачами економіки Гіротакою Такеучі та Ікуджиро Нонакою. Вона називалася «Розробка нового продукту. Нові правила гри». Такеучі та Нонака вивчали команди кількох найбільш продуктивних та інноваційних компаній світу: Honda, Fuji-Xerox, 3M, Hewlett-Packard та інших. Вони стверджували, що старий спосіб розробки продукту, заданий фазовою системою планування програм NASA , – каскадна модель – дефектний у своїй основі. Натомість найкращі компанії використовують ступеневий процес розробки, який є швидшим та гнучкішим. Ці команди мають різнопрофільних фахівців, автономію та взаємопідтримку. При цьому вони ставлять перед собою мету вийти за межі досягнутого раніше. Вони прагнуть чогось більшого за самих себе. Менеджмент не диктує їм, що робити. Навпаки, керівники компаній виступають у ролі лідерів-слуг та посередників, зосереджених на прибиранні перешкод зі шляху їхніх команд, а не на вказівках, котрий продукт розробляти і як. Японські викладачі порівнювали робочий процес із грою в регбі й казали, що найкращі команди діють так, немов гуртуються задля досягнення спільної мети, що й називається Scrum : «…м’яч пасується всередині команди, яка рухається полем як єдине ціле» [6] Takeuchi, Hirotaka, and Ikujiro Nonaka. «The New New Product Development Game.» Harvard Business Review (січень— лютий 1986 р.): 285–305. .