Я знав, що в Easel каскадна модель викине нас за межі дедлайнів на місяці, якщо не роки. Ми мали розробити зовсім інакший спосіб управління проектами. Я пішов до генерального директора і сказав, що діаграми Ґантта не для нас. Він був шокований і вимагав пояснити чому.
– Скільки діаграм Ґантта ви бачили за свою кар’єру? – спитав я.
– Сотні, – сказав він.
– А скільки з них справдилися?
– Жодної, – відповів він після паузи.
Саме тоді я й пояснив йому, що збираюся презентувати наприкінці місяця робоче програмне забезпечення, а не невиконану діаграму Ґантта. Він зможе випробувати його сам і переконатися, що ми на правильному шляху. Ми маємо спробувати це, якщо хочемо вкластись у відведені строки.
Кілька тижнів ми з командою витратили на читання сотень документів, книжок та статей з організації команд і розробки продукту. А потім один розробник якось приніс статтю з Harvard Business Review від 1986 року, написану двома японськими викладачами економіки Гіротакою Такеучі та Ікуджиро Нонакою. Вона називалася «Розробка нового продукту. Нові правила гри». Такеучі та Нонака вивчали команди кількох найбільш продуктивних та інноваційних компаній світу: Honda, Fuji-Xerox, 3M, Hewlett-Packard та інших. Вони стверджували, що старий спосіб розробки продукту, заданий фазовою системою планування програм NASA, – каскадна модель – дефектний у своїй основі. Натомість найкращі компанії використовують ступеневий процес розробки, який є швидшим та гнучкішим. Ці команди мають різнопрофільних фахівців, автономію та взаємопідтримку. При цьому вони ставлять перед собою мету вийти за межі досягнутого раніше. Вони прагнуть чогось більшого за самих себе. Менеджмент не диктує їм, що робити. Навпаки, керівники компаній виступають у ролі лідерів-слуг та посередників, зосереджених на прибиранні перешкод зі шляху їхніх команд, а не на вказівках, котрий продукт розробляти і як. Японські викладачі порівнювали робочий процес із грою в регбі й казали, що найкращі команди діють так, немов гуртуються задля досягнення спільної мети, що й називається Scrum: «…м’яч пасується всередині команди, яка рухається полем як єдине ціле»[6].
Коли стаття Такеучі та Нонаки тільки вийшла, вона наробила галасу, але то було за сім років до того, як ми прочитали її в Easel. Усі нею захоплювались, але ніхто нічого із цим не робив. Пересічний американський менеджер був не здатний осмислити її ідеї, навіть попри те, що Toyota швидко збільшувала свою частку ринку, використовуючи цей підхід. В Easel нам не було чого втрачати. Ми вирішили спробувати, хоча стаття й описувала більше виробничу сферу, а не розробку програмного забезпечення. Я вважав, що їхні ідеї приведуть до чогось фундаментального, процедури, що описувала б найкращий спосіб співпраці людей у будь-якій сфері діяльності. Адже вони чудово вкладалися в усі інші експерименти, які я проводив іще з моєї першої роботи у приватному секторі в MidContinent.
Це стало офіційним народженням Scrum. Ми здали готовий продукт вчасно, ще до закінчення шести місяців, не перевищивши бюджет і з меншою кількістю помилок, ніж у будь-якому попередньому замовленні.
Можливості цієї нової форми управління проектами так мене надихнули, що вся моя майбутня робота зосередилась на вдосконаленні Scrum для компаній. У 1995 році разом із Кеном Швабером я презентував на дослідницькій конференції Асоціації обчислювальної техніки працю під назвою «Спосіб розробки SCRUM», яка систематизувала ці практики. Після того ми відмовилися від слів великими літерами та дещо допрацювали цю ідею, але основні принципи залишаються незмінними; а компанії, які прийняли цей спосіб, зазвичай отримують негайні переваги[7].
Перевіряйте та адаптуйте
У системі Scrum команди, які добре працюють, здатні досягти того, що ми називаємо гіперпродуктивністю. Важко повірити, але серед груп, які добре впроваджують Scrum, ми регулярно бачимо десь так від 300 до 400 відсотків покращення продуктивності. Найкращі команди можуть досягти підвищення продуктивності аж до 800 відсотків, а потім повторювати цей успіх знову й знову. Крім того, в результаті використання цієї системи подвоюється якість їхньої роботи.
То як створити в Scrum-команді автономію, прагнення перевершити самих себе, взаємозаохочення – а потім досягти гіперпродуктивності за рахунок поєднання всього цього? Мова про це піде в решті розділів цієї книжки, але базові принципи я збираюся подати вам тут. У скороченій формі їх можна також побачити в додатку.
Оскільки Scrum бере початок із технік, використовуваних у японському виробництві, не завадить трохи дізнатися, звідки їх узяли японці. За іронією долі, вони багато чого навчилися в одного американця – Вільяма Едвардса Демінга. Під час американської окупації Японії після Другої світової війни Демінг працював на генерала Дуґласа Мак-Артура. Підхід Мак-Артура до відновлення економіки полягав у тому, щоб звільнити більшу частину вищого керівництва японських компаній, підвищити керівників середньої ланки та залучити до ділових операцій експертів зі Сполучених Штатів, таких як Демінг. Вплив Демінга на японське виробництво був надзвичайним. Він навчив сотні інженерів того, що називається «статистичним контролем процесів». Основною ідеєю було точне вимірювання зробленого та його якості, а також прагнення до безперервного покращення. Не просто разового покращення, а постійного. Слід завжди шукати, що можна покращити, і ніколи не зупинятися на досягнутому. Для цього потрібно постійно проводити експерименти, які вказуватимуть на можливість досягти кращих результатів. Якщо спробувати цей метод, чи не буде він кращим за старий? Як щодо іншого? Що як змінити один цей момент?
Відомий виступ Демінга перед керівниками японських підприємств у 1950 році. Серед слухачів були й такі люди, як Акіо Моріта, засновник компанії Sony. Демінг тоді сказав їм:
…хоч які чудові у вас технічні фахівці, саме ви, лідери, повинні прагнути успіхів у покращенні якості та однорідності продукції, а ваші техніки мають бути здатні на ці покращення. Отже, перший крок – за керівництвом. Перш за все, техніки вашої компанії та робітники ваших заводів повинні знати, що ви маєте завзяття для вдосконалення якості та однорідності продукції, а також почуття відповідальності за якість продукції.
Якщо лише говорити про це, нічого не вийде. Важливо діяти[8].
Найбільше Демінг відомий якраз своїм методом дій – циклом ПРПД (Планувати, Робити, Перевіряти, Діяти). Цей цикл можна застосувати до виробництва практично всього: автомобіля, відеогри чи навіть паперового літачка.
Коли я навчаю когось застосовувати Scrum, то використовую саме їх – паперові літачки. Я поділяю людей на команди й ставлю перед ними завдання зробити якомога більше паперових літачків, які літатимуть кімнатою. У команді буде три категорії людей. Одна людина перевірятиме, скільки зроблено літачків, які дійсно можуть літати. Друга буде частиною виробничого процесу разом з усіма, але також звертатиме увагу на сам процес та шукатиме способи покращення якості літачків і прискорення їх виробництва. Усі інші концентруватимуться на виготовленні якомога більшої кількості літачків, дійсно здатних пролетіти задану відстань за відведений на це час.
Потім я кажу, що ми маємо виконати три шестихвилинні цикли виробництва паперових літачків. Одну хвилину кожного циклу команди мають Планувати, як вони збираються робити літачки, три хвилин – Робити (виготовляти й тестувати якомога більше літачків, дійсно здатних літати). І нарешті, дві хвилини вони мають Перевіряти. На цьому етапі команда дивиться, як можна покращити процес виготовлення їхніх паперових літачків. Що пішло правильно? Що – неправильно? Чи не слід змінити дизайн? Як можна покращити процес виготовлення? А потім вони Діятимуть. У системі Демінга «діяти» означає змінювати ваш спосіб роботи на основі реальних результатів і реального впливу зовнішніх умов. Та сама стратегія використовувалась і в роботах Брукса.
6
Takeuchi, Hirotaka, and Ikujiro Nonaka. «The New New Product Development Game.» Harvard Business Review (січень— лютий 1986 р.): 285–305.
7
Schwaber, Ken. «Scrum Development Process,» у збірці OOPSLA Business Object Design and Implementation Workshop, J. Sutherland, D. Patel, C. Casanave, J. Miller, and G. Hollowell, eds. (London: Springer, 1997).
8
Deming, W. Edwards. «To Management.» Промова в Конференц-центрі на горі Хаконе, Японія, 1950 р.