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

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

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

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

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

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

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

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

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

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