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

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

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

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

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

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

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