зроблено літачків, які дійсно можуть літати. Друга буде частиною виробничого процесу разом з усіма, але також звертатиме увагу на сам процес та шукатиме способи покращення якості літачків і прискорення їх виробництва. Усі інші концентруватимуться на виготовленні якомога більшої кількості літачків, дійсно здатних пролетіти задану відстань за відведений на це час.
Потім я кажу, що ми маємо виконати три шестихвилинні цикли виробництва паперових літачків. Одну хвилину кожного циклу команди мають Планувати, як вони збираються робити літачки, три хвилин – Робити (виготовляти й тестувати якомога більше літачків, дійсно здатних літати). І нарешті, дві хвилини вони мають Перевіряти. На цьому етапі команда дивиться, як можна покращити процес виготовлення їхніх паперових літачків. Що пішло правильно? Що – неправильно? Чи не слід змінити дизайн? Як можна покращити процес виготовлення? А потім вони Діятимуть. У системі Демінга «діяти» означає змінювати ваш спосіб роботи на основі реальних результатів і реального впливу зовнішніх умов. Та сама стратегія використовувалась і в роботах Брукса.
Пройдіть цей цикл тричі, і, хоч що ви виробляєте – паперові літачки чи справжні космічні кораблі, – ви станете кращими, значно кращими (прискорившись у два-три рази і щонайменше подвоївши якість). Саме завдяки цьому циклу Демінга – радикальній ідеї на той час, коли її презентували японцям, – компанія Toyota і стала автовиробником номер один у світі. Саме так працює будь-який різновид «ощадливого» виробництва (американський термін для використання концепцій виробничої системи Toyota) або розробка продукту в Scrum.
Змінюйтесь або помріть
Причина того, чому новий спосіб управління проектами був таким важливим і чому стільки різних компаній його прийняли, почасти полягала в надзвичайно поганому стані розробки програмного забезпечення. Проекти майже завжди не вкладалися в строки та бюджет, а часто й взагалі не працювали. І це було не через тупість чи жадібність людей – скоріше річ була в способі їхнього мислення про роботу. Вони наполягали на застосуванні каскадної моделі, казали, що все можна планувати заздалегідь, навіть що умови не змінюються в ході багаторічного проекту. А це вже просто божевілля перед лицем таких змін.
Я переконався в цьому на власному досвіді в компанії BellSouth, коли відвідував їх як консультант багато років тому. Вони мали висококласних інженерів, багато з яких прийшли з відомого дослідницького центру Bell Labs. Вони ідеально дотримувались каскадної моделі. Бралися за величезні проекти на 10 чи 20 мільйонів доларів. Могли зібрати всі вимоги замовника, потім зачинитися на вісімнадцять місяців і вчасно й чітко в межах бюджету видати саме те, що просив замовник. Вони були однією з дуже й дуже небагатьох компаній у всьому світі, яким це вдавалося. Проблема полягала в тому, що на цьому етапі замовники хотіли вже іншого. Обставини змінювались. Ділові цикли скорочувались, а клієнти вимагали більш інтерактивного обслуговування.
Мене запросили подивитися,