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

У розробці продуктів є безумовне правило, що підтверджувалося багато разів. Я вже говорив про нього раніше: 80 відсотків цінності закладені в 20 відсотках характеристик. Задумайтесь над цим на хвилину. В усьому, що ви купуєте, основна цінність – те, чого люди хочуть найбільше, – складає лише п’яту частину створеного. У випадку цієї компанії співробітники дивилися на свій величезний перелік речей, які можна включити в їхню систему побутової автоматики, і розуміли (знали), що насправді клієнти хочуть лише 20 відсотків із цього. Scrum дозволяє визначити, як створити ці 20 відсотків передусім. У традиційній розробці продуктів команди не знають, у чому полягають ці 20 відсотків, доки не завершать увесь проект. Це означає, що цілих 80 відсотків їхніх зусиль марнуються. А ви знаєте, як я ставлюсь до марнування.

А якби ви могли завершувати проекти в п’ять разів швидше за ваших конкурентів, з уп’ятеро більшою цінністю? Це шлях до перемоги.

Тому працівники цієї компанії з автоматизації засіли за свій величезний перелік характеристик і спитали себе: «Гаразд, із чого нам починати завтра? Що є найважливішим для клієнтів? Як нам принести їм цінність швидше за будь-кого іншого?» Як каже Скотт Максвелл, складність тут у визначенні не чого ви хочете досягти, а чого ви можете досягти. Це справджується для всього: будуєте ви будинок чи виробляєте авто, пишете книжку чи створюєте відеогру, вичищаєте сміття чи боретеся зі злочинністю. Визначте, де можна принести найбільшу цінність за найменших зусиль, і зробіть це одразу. Потім продовжуйте збільшувати цінність крок за кроком. Озирнутись не встигнете, як створите чи презентуєте щось із реальними результатами, які можна продемонструвати. Ключем до цього є розставляння пріоритетів у роботі.

Як вам це зробити? Насамперед вам потрібен хтось, хто може визначити як бачення, так і цінність. У Scrum ми називаємо таку особу власником продукту.

Власник продукту

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

Створюючи першу Scrum-команду в 1993 році, я не мав власника продукту. Я був членом керівної команди та мав купу інших обов’язків, окрім визначення, що саме повинна робити команда в кожному спринті. Я займався керівництвом та маркетингом, вирішував питання з клієнтами та накреслював загальну стратегію. Але в тому першому спринті я виявив, що цілком можу керувати беклогом. Потрібно було просто слідкувати за тим, щоб мати досить сюжетів, побажань та характеристик для роботи команди протягом наступного спринту. Проблема полягала в тому, що після другого спринту ми запровадили щоденні стендапи – обговорення стоячи. Уже в наступному спринті швидкість роботи підвищилась на 400 відсотків, і команда за тиждень закінчила те, що мало б зайняти в нас місяць. У них закінчилися завдання з беклогу, над якими треба було працювати! Я ж собі думав, що маю місяць для планування нових завдань. Доволі велика проблема, погодьтеся, але її треба було якось розв’язувати. Тому я й подумав про цю роль власника продукту та про якості, потрібні для належного її виконання.

Розробляючи її, я надихався роллю головного інженера компанії Toyota. Людина на цій посаді відповідає за всю виробничу лінію окремої моделі, наприклад, Corolla чи Camry. Для цього вона має задіяти таланти груп працівників, які спеціалізуються на створенні корпуса, коліс, електропроводки тощо. Головний інженер має об’єднати групи окремих фахівців, щоб створити єдину багатофункціональну команду, здатну зібрати авто. За межами Toyota цих легендарних головних інженерів (або шуса, як їх називають у Японії) вважають всесильними лідерами так званого «шляху Toyota». У певному розумінні це правда. Але влади при цьому вони не мають. Ніхто їм не підзвітний – радше вони самі підзвітні своїм групам. Люди можуть вказувати головним інженерам на їхні помилки, тому вони мають стежити за правильністю своїх рішень. Вони не дають нікому оцінок продуктивності, підвищень чи заохочень. Вони лише приймають рішення щодо бачення авто і способів його виготовлення – шляхом переконання, а не примусу.

Саме цю ідею я й хотів утілити в системі Scrum. Джон Шук з Інституту ощадливого підприємництва якось почав свій опис ролі головного інженера цитатою з інструкції для командного складу морської піхоти США:

Згадуючи свій досвід, набутий у Вест-Пойнті та В’єтнамі, я цілком погоджуюсь, що лідерство не має нічого спільного із владою. Радше воно – серед іншого – стосується знань та готовності служити людям. Головний інженер Toyota не може просто наказувати виконати щось конкретним способом. Він має переконувати, лестити й демонструвати, що його спосіб є правильним, найкращим. Зазвичай, щоб грати цю роль, потрібні десятиліття досвіду. Я хотів запровадити її у Scrum, але я також добре знав, що дуже небагато людей мають такий рівень досвіду та навичок. Тому я розбив цю роль на дві, віддавши питання як робити Scrum-майстрові, а що робити – власникові продукту.

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

Запам’ятайте: «клієнтом» може бути масовий споживач, великий банк, ваш чоловік або хтось, хто потребує ротавірусної вакцини та залежить від вас, щоб її дістати. Клієнтом є той, хто отримає цінність від того, що ви робите.

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