Читати книгу - "Scrum"

…німецький завод докладав більше зусиль для виправлення проблем, ніж японському було потрібно для виготовлення майже ідеального авто відразу[29].

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

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

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

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

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

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

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

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

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

Понаднормова праця збільшує обсяг роботи

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

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

Скотт та інші молоді консультанти тоді підняли цю ідею на глум. Працювати менше годин? Це ж девіз ледацюг, чи не так? Але ідея залишилася зі Скоттом на довгі роки, коли він просувався кар’єрними щаблями. Ставши ж засновником та генеральним директором OpenView Venture Partners, він почав інвестувати гроші в технологічні компанії, декотрі з яких практикували Scrum. Він почув, що я, винахідник Scrum, живу з ним в одному місті, й одного ранку запросив мене на сніданок. За кавою з круасанами Скотт розповів мені історію однієї з компаній, у які він інвестував, де команда розробників запровадила Scrum і змогла покращити свою продуктивність спочатку на 25, а потім і на 35 відсотків. Він був дійсно вражений. Моя ж щира реакція була такою: «Двадцять п’ять? Тридцять п’ять? Та вони явно роблять щось не так!!!»

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

Подвійна користь від скорочення робочого навантаження