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

Читать онлайн.
Название Scrum. Навчись робити вдвічі більше за менший час
Автор произведения Джефф Сазерленд
Жанр Управление, подбор персонала
Серия
Издательство Управление, подбор персонала
Год выпуска 2014
isbn 978-617-12-2352-3, 9786171223530



Скачать книгу

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

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

      Пройдіть цей цикл тричі, і, хоч що ви виробляєте – паперові літачки чи справжні космічні кораблі, – ви станете кращими, значно кращими (прискорившись у два-три рази і щонайменше подвоївши якість). Саме завдяки цьому циклу Демінга – радикальній ідеї на той час, коли її презентували японцям, – компанія Toyota і стала автовиробником номер один у світі. Саме так працює будь-який різновид «ощадливого» виробництва (американський термін для використання концепцій виробничої системи Toyota) або розробка продукту в Scrum.

      Змінюйтесь або помріть

      Причина того, чому новий спосіб управління проектами був таким важливим і чому стільки різних компаній його прийняли, почасти полягала в надзвичайно поганому стані розробки програмного забезпечення. Проекти майже завжди не вкладалися в строки та бюджет, а часто й взагалі не працювали. І це було не через тупість чи жадібність людей – скоріше річ була в способі їхнього мислення про роботу. Вони наполягали на застосуванні каскадної моделі, казали, що все можна планувати заздалегідь, навіть що умови не змінюються в ході багаторічного проекту. А це вже просто божевілля перед лицем таких змін.

      Я переконався в цьому на власному досвіді в компанії BellSouth, коли відвідував їх як консультант багато років тому. Вони мали висококласних інженерів, багато з яких прийшли з відомого дослідницького центру Bell Labs. Вони ідеально дотримувались каскадної моделі. Бралися за величезні проекти на 10 чи 20 мільйонів доларів. Могли зібрати всі вимоги замовника, потім зачинитися на вісімнадцять місяців і вчасно й чітко в межах бюджету видати саме те, що просив замовник. Вони були однією з дуже й дуже небагатьох компаній у всьому світі, яким це вдавалося. Проблема полягала в тому, що на цьому етапі замовники хотіли вже іншого. Обставини змінювались. Ділові цикли скорочувались, а клієнти вимагали більш інтерактивного обслуговування.

      Мене запросили подивитися,