Scrum - Джефф Сазерленд

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

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

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

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

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

Відповідальність людини за лідерство не залежить від влади… глибоко вкорінене припущення, що влада має дорівнювати відповідальності, є коренем великого організаційного негаразду. Я вважаю, що непорозуміння навколо цього питання загрозливе й проблемне, воно проникло в нашу свідомість так глибоко, що ми цього навіть не усвідомлюємо[41].

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

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

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

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

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

З роками я звів головні характеристики власника продукту до чотирьох.

По-перше, власник продукту має розбиратися у своїй сфері діяльності. Маю на увазі дві речі. Він повинен досить добре розуміти, чим займається команда, щоб знати, що може бути виконане і, не менш важливо, що не може. Але він також має розуміти це що достатньо добре, щоб знати, як перетворити його на справжню цінність, яка має сенс. Це може бути комп’ютерна система, що допомагає ФБР ловити терористів, чи методика навчання, яка покращує успішність учнів середніх шкіл. Власник продукту повинен знати ринок достатньо добре, щоб розуміти, що саме може змінити ситуацію на краще.

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

По-третє, власник продукту має бути доступним для команди, пояснюючи, що саме треба виконати і чому. Хоча врешті за беклог відповідає власник продукту, він повинен підтримувати постійний діалог з командою. Дуже часто