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

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

Кілька років тому я побував у Каліфорнії, де виступав перед розробниками з компанії Palm . Вони виготовляли те, що пізніше було названо персональними цифровими асистентами, які ми тепер знаємо як смартфони. Усі свої дії ці люди відстежували автоматично. Одним із багатьох моментів, які вони вимірювали, була тривалість виправлення помилок у програмі. Іншими словами, скільки часу займало у програміста виправлення проблеми, яку він створив у системі. Кожного разу цей час ретельно відслідковувався комп’ютером.

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

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

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

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

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

Переконаний, вам доводилося самим стикатися з таким у роботі. Напевне, вам ще в дитинстві казали: «Роби все правильно з першого разу». Єдине, що додалося сьогодні: якщо ви робите помилку – а ми всі їх робимо, – виправляйте її, щойно помітите. Інакше пізніше вони вам дорого коштуватимуть.

Коли Скотт Максвелл, засновник фірми OpenView Venture Partners , працював консультантом у McKinsey & Company на початку 1990-х, він отримав настанову, яка здалася йому доволі дивною. Джон Катценбах, тоді директор компанії, а нині автор кількох книжок та голова Центру Катценбаха при Booz Allen Hamilton , дав Скотту одну пораду, яку той ніколи не забуде. Джон розповів, що в далекі сімдесяті, коли він починав свою діяльність, усі в McKinsey працювали сім днів на тиждень. Такою була корпоративна культура, і саме це очікувалось від усіх співробітників. Якщо ви не працювали стільки годин, вважалося, що ви не тягнете, не приносите достатньої користі команді.

З релігійних причин Джон Катценбах не ходив на роботу по суботах. І він дещо помітив. Працюючи менше годин, він насправді виконував більше за тих, хто працював кожного дня – а такими в той час були майже всі його колеги. Тоді він вирішив спробувати працювати лише п’ять днів на тиждень і виявив, що почав робити ще більше. Якщо працювати забагато, зрозумів він, устигаєш менше. Він розповів Скотту, що завжди хотів скоротити свій робочий тиждень до чотирьох чи навіть трьох днів, щоб побачити, що із цього може вийти, але не знав, чи погодиться на це компанія.