Текст бизнес-книги "Scrum. Навчись робити вдвічі більше за менший час"

Автор книги: Анатолий Верчинский

Раздел: Управление и подбор персонала, Бизнес-книги

Для журналістів це стало грандіозною подією історичної ваги. Серед тих, хто приїхав до Каїра її висвітлювати, була й бригада Національного громадського радіо (NPR), одного з провідних медіа Сполучених Штатів. Але спочатку продюсери та репортери були настільки заскочені зненацька, що не встигали за подіями, губили матеріали, плутали репортажі та ледь-ледь задовольняли вимоги свого керівництва у Вашингтоні.

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

На диво, через деякий час команда почала успішно працювати, причому саме через складнощі зв’язку з вашингтонським керівництвом. Адже радійникам довелося діяти переважно на власний ризик. Постійні прямі вказівки отримувати було просто неможливо, а події розвивалися дуже швидко, тому для виконання роботи команді довелося самоорганізовуватись. Однією з ключових концепцій у системі Scrum є якраз те, що члени команди самі вирішують, як вони збираються працювати. Керівництво відповідає лише за виставлення стратегічних цілей, а вже як їх досягти, має вирішувати команда. Той, хто не був тоді в Каїрі, просто не міг слідкувати за тим, що відбувається. Майже щодня команда NPR готувала низку репортажів на наступний день, але події змінювались так блискавично, що всі ці повідомлення майже миттєво застарівали. На площі Тахрір відбувалася масштабна сутичка, лунала якась гучна заява, хтось подавав у відставку, і вся робота команди йшла псу під хвіст. Раптом виявлялося, що їм майже нема чого вчасно видати в ефір.

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

Як же це все покращилось? Можу вас запевнити, що хаос, пов’язаний із загальною непевністю, особистими сварками та нездатністю миттєво видавати новини, швидко перетворився на добре змащений механізм, яким начальству навіть не доводилось керувати. Натомість члени команди керували самі собою. Протягом наступних кількох тижнів бригада NPR у Каїрі підготувала більше репортажів, ніж хтось узагалі вважав за можливе. Причому якість усіх цих новин була вищою, ніж пропонували конкуренти, за що журналісти врешті-решт отримали навіть кілька нагород. То був справжній успіх, якого не вдалося б досягти, якби команду не захопило відчуття мети (розповісти про одну з найвидатніших подій у їхній кар’єрі) і якби вона не мала автономії (здатності самим вирішувати, як висвітлювати різні аспекти великої події).

Сьогодні Scrum використовується в усіх сферах роботи Національного громадського радіо – від веб-дизайну до журналістського збирання даних та створення нових передач. Використовують його також команди Chicago Tribune, New York Times, Washington Post і ProPublica. Адже, коли дедлайни підпирають, швидкість потрібна всім.

Одна команда для всієї роботи

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

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

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

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

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

Розгляньмо інший приклад. У компанії Salesforce.com за гнучку інфраструктуру релізів відповідає Нікола Дурамбе. Вона керує роботою приблизно двохсот Scrum