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

764
0
26.04.22
В нашій бібліотеці можна безкоштовно в повній версії читати книгу онлайн українською мовою "Scrum" автора Джефф Сазерленд. Жанр книги: 💙 Бізнес-книги. Наш веб сайт ReadUkrainianBooks.com дає можливість читати повні версії улюблених книг на Вашому гаджеті (IPhone, Android) або комп’ютері абсолютно безкоштовно, без реєстрації та СМС. Також маєте можливість завантажити книги на свій гаджет у форматі PDF, EPUB, FB2. Файли електронних книг - це цифрові файли, які призначені для перегляду на спеціальних пристроях, що відомі як читальні пристрої для електронних книг.

Шрифт:

-
+

Інтервал:

-
+

Добавити в закладку:

Добавити
1 ... 14 15 16 ... 60
Перейти на сторінку:

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

Класичним прикладом цього є так звана модель «фаза-брама», за допомогою якої розробляли програму космічних шатлів та інші проекти 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. Після того релізи в нас пішли тричі на рік. Не так уже багато великих підприємств здатні похвалитися тим самим».

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

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

Scrum під час війни

Одним із найбільш вражаючих прикладів багатофункціональних команд є військова служба. Адже саме за цим принципом працюють американські сили спеціального призначення. Типова армійська «команда А» (загін «Альфа») має у своєму складі дванадцятьох людей: командира (офіцера), прапорщика, головного сержанта (який керує повсякденною діяльністю команди), сержанта розвідки та по двоє сержантів зі спеціального озброєння, вибухівки, медицини та зв’язку. Кожна команда має всі можливості для виконання свого завдання від початку до кінця. Причому вони проводять перехресні тренування з кожного набору вмінь та навичок. Вони хочуть бути впевнені, що, наприклад, якщо обох медиків уб’ють, зв’язківець зможе «залатати» збройового. Крім того, спецпризначенці відрізняються від більшості звичайних військових тим, що не відокремлюють збір розвідданих від планування операцій. Між командами немає «зіпсованого телефону», коли можливі помилки. Силам спеціального призначення не потрібні катастрофи на кшталт «Челленджера». Тому між розвідкою, відділом планування операцій і тими, хто безпосередньо їх виконує, підтримується постійний діалог.

Під час війни в Іраку команди сил спеціального призначення показали, що вони надзвичайно добре вміють убивати людей. Вони могли виявити ціль та знищити її в одну ніч. Між 2003 і 2007 роками вони виконали тисячі завдань, спрямованих на придушення іракського спротиву, особливо терористичної діяльності «Аль-Каїди». У своїх завданнях вони майже завжди досягали тактичного та оперативного успіху. Їхні багатофункціональні, чудово підготовані команди стали однією з найбільш смертоносних сил, які колись бачив світ. Однак, попри всі свої вміння, навички й таланти, вони мали майже нульовий стратегічний вплив. Протягом цих перших чотирьох років війни атаки на американські сили та іракських цивільних лише посилювалися мало не щодня. У деякі найчорніші дні війни на американських військових здійснювалося більш ніж сто нападів, і навіть смертоносність сил спеціального призначення не могла цьому зарадити. Наприкінці 2006 та на початку 2007 року майже всі компетентні коментатори вважали Ірак справою безнадійною. Кожна нова загибель американця почала розглядатись як марна жертва.

А потім у 2007-му генерал Девід Петреус очолив стратегію, що стала відома як «Велика хвиля» й передбачала додаткове введення до країни десятків тисяч солдатів та розміщення їх у населених пунктах. Ця нова стратегія дала дивовижний ефект. Однією з причин було те, що

1 ... 14 15 16 ... 60
Перейти на сторінку:

 Увага!

Сайт зберігає кукі вашого браузера. Ви зможете в будь-який момент зробити закладку та продовжити читання книги «Scrum», після закриття браузера.

Коментарі та відгуки (0) до книги "Scrum"