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

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

Класичним прикладом цього є так звана модель «фаза-брама», за допомогою якої розробляли програму космічних шатлів та інші проекти NASA в 1960-ті – 1980-ті роки. Сьогодні ця модель дуже змінилась, але ось як вона працювала колись. Першою йшла фаза дослідження, коли люди вирішували, на що вони збираються замахнутись – можливо, збудувати ракету, що полетить на Місяць. Група стратегів збиралась у кімнаті й починала про це фантазувати. А далі йшла «брама», коли менеджер або група менеджерів підписували проект як вартий розробки. Другою фазою було визначення масштабу робіт, коли спеціалісти з вимог та стандартів вирішували, що має бути зроблено. Потім ішла друга «брама» та ще ряд зустрічей, після яких усі підготовані документи вели до наступної фази – створення підприємницького завдання та плану проекту. Далі всі ці плани проходили ще ряд обговорень та узгоджень, після чого наставала ще одна фаза – розробки, де починалося справжнє створення продукту. Пройшовши ще кілька обговорень та процес підготовки документів, продукт передавався абсолютно іншій групі для наступної фази – тестування. Ці люди ніколи не бачили продукту раніше, але тестували його, підписували, що з ним усе гаразд, а потім проштовхували його до наступної «брами» або ряду нескінченних обговорень, із наступною купою документів, яких ніхто не читав. І лише після цього продукт потрапляв до шостої групи людей, які дійсно вводили його в експлуатацію. Виснажливо навіть просто писати про це. А для NASA така робота була звичною.

Якось на початку 1980-х керівники компанії Fuji-Xerox приїхали до Америки повчитись, як працює відома космічна агенція. Коли ж вони запровадили ті самі процедури в себе в Японії, то відразу зіткнулися з падінням якості. Кількість збоїв пішла вгору, а від їхньої продуктивності лишилися тільки кола на воді. Вони швидко відмовились від цього процесу, боячись, що він може призвести до повної катастрофи.

Із цим цілком може погодитись комісія під керівництвом Вільяма Роджерса, яка розслідувала причини катастрофи космічного корабля «Челленджер» у 1986 році. Як написав у своєму відомому «Додатку F» до звіту комісії фізик Річард Фейнман: «Цілком може виявитись, що з будь-якою метою, чи то для внутрішнього споживання, чи то для зовнішнього, керівництво NASA перебільшує надійність своєї продукції до фантастичних показників»[13].

Факт залишається фактом: якщо поглянути на найкращі команди (схожі на ті, що існували в Toyota чи 3M, коли Такеучі й Нонака писали свою працю, або на ті, що існують у Google, Salesforce.com чи Amazon сьогодні), ви не побачите там такого розподілу ролей. Члени всіх команд разом виконують усю роботу, від початку до кінця.

Розгляньмо інший приклад. У компанії Salesforce.com за гнучку інфраструктуру релізів відповідає Нікола Дурамбе. Вона керує роботою приблизно двохсот Scrum-команд у компанії, яка постійно потрапляє в рейтинги ста найкращих роботодавців за версією журналу Fortune та найбільш інноваційних компаній світу за списком Forbes. Вона каже, що вважає Scrum «таємним соусом» своєї роботи. «Коли ми були стартапом, то робили якийсь великий реліз три чи чотири рази на рік. Але в 2005–2006 роках, коли ми зросли та розширились, управляючи проектами типовим каскадним способом, цей показник упав до одного разу на рік. Так залишати було не можна. Тому ми запровадили Scrum