Про цю діаграму треба думати всім компаніям. Якщо концентруватися лише на тому, що ви здатні створити, це може закінчитись виготовленням насправді нікому не потрібних речей, навіть якщо ви маєте до них пристрасть. Якщо робити ставку лише на те, що ви можете продати, можна наобіцяти речі, які не вийде створити. Якщо ж створювати лише те, що ви можете продати, але до чого не маєте пристрасті, це закінчиться важкою роботою заради посередності. Але в центрі, перехресті, лежить бачення, що проростає з реальності, бачення з реальною можливістю стати чимось видатним. У цьому розділі я збираюсь показати вам, як до цього прийти. Попередні розділи зосереджувались на тому, як робити все швидше та краще. Цей розділ розповість, як змусити «швидше та краще» працювати на вас як досягти надзвичайності.
Скотт Максвелл каже, що справжня сила Scrum полягає в його готовому, пріоритетному й вимірюваному беклозі переліку завдань, які треба виконати. Ось чому Скотт запровадив Scrum у венчурній групі та вважає його вирішальною конкурентною перевагою.
Беклог: що й коли робити
Перше, що потрібно зробити, застосовуючи Scrum, скласти беклог. Він може бути завдовжки в сотні пунктів або містити лише кілька речей, з якими слід розібратися передусім. Безумовним є лише одне: ви маєте чітко уявляти, що хочете отримати наприкінці роботи. Це може бути якийсь продукт, весілля, послуга, нова вакцина, пофарбовані стіни будинку тощо. Це може бути будь-що, але одразу після створення в голові картинки бажаного результату слід продумати, чого потребуватиме його досягнення.
Нещодавно я працював із компанією, яка виробляє автоматизовані системи для будинків: опалення, охолодження, електрики, сантехніки, усього потроху. Одним із їхніх нових продуктів є система побутової автоматики. Вони створюють систему, здатну контролювати всі аспекти вашого побуту: від відчинення вхідних дверей та вмикання світла в кімнатах до контролю витрат на опалення і все з вашого мобільного пристрою. Отже, спочатку вони сідають і складають перелік усього, що для цього потрібне: перемикачів, контролерів, інтерфейсів, датчиків, протоколів звязку тощо. По суті, не конкретних правил та шматків роботи, а всіх сюжетів та побажань замовника.
Тому вони записують такі речі: «Як домовласник я хочу мати можливість бачити, хто стоїть біля моїх дверей, щоб можна було відчиняти їх лише тим, кого я вирішу пустити». Вони пишуть побажання про відчинення гаражних воріт, увімкнення всіх систем, контроль освітлення. Перелік продовжується доти, доки до нього не ввійдуть усі речі, які, на їхню думку, має робити їхній продукт, щоб бути ринково привабливим.
У цьому випадку перелік якраз і був завдовжки в сотні пунктів, адже йшлося про велику, складну систему автоматики. Беклог базується на ідеї, що в нього має входити все, що тільки можна включити в продукт. Звичайно, всього вбудувати вам не вдасться, але треба мати перелік усіх речей, які можна було би включити в бачення цього продукту.
Ключ тут у тому, що ви вирішите зробити спочатку. Для цього потрібно відповісти на таке питання: «Які пункти мають найбільший бізнесовий вплив, найважливіші для клієнта, можуть принести найбільше грошей та найлегші для виконання?» Треба розуміти, що в цьому переліку є ціла купа речей, за які ви ніколи не візьметесь, і передусім вам потрібні ті, що принесуть найбільшу цінність із найнижчим ризиком. У поетапній системі розробки та завершення проекту Scrum треба починати з речей, які негайно принесуть прибуток, ефективно знизивши ризики. І робити це треба на рівні характеристик продукту. Слід починати створювати цінність для ваших клієнтів якомога раніше. Адже вам потрібне буде щось повністю виконане що можна показати. Це може бути просто невеличка частина більшого проекту, але вона має бути готова для демонстрації. Якщо ви фарбуєте будинок, можливо, першим таким виконаним пунктом буде повне завершення всіх робіт у вітальні.
У розробці продуктів є безумовне правило, що підтверджувалося багато разів. Я вже говорив про нього раніше: 80 відсотків цінності закладені в 20 відсотках характеристик. Задумайтесь над цим на хвилину. В усьому, що ви купуєте, основна цінність те, чого люди хочуть найбільше, складає лише пяту частину створеного. У випадку цієї компанії співробітники дивилися на свій величезний перелік речей, які можна включити в їхню систему побутової автоматики, і розуміли (знали), що насправді клієнти хочуть лише 20 відсотків із цього. Scrum дозволяє визначити, як створити ці 20 відсотків передусім. У традиційній розробці продуктів команди не знають, у чому полягають ці 20 відсотків, доки не завершать увесь проект. Це означає, що цілих 80 відсотків їхніх зусиль марнуються. А ви знаєте, як я ставлюсь до марнування.
А якби ви могли завершувати проекти в пять разів швидше за ваших конкурентів, з упятеро більшою цінністю? Це шлях до перемоги.
Тому працівники цієї компанії з автоматизації засіли за свій величезний перелік характеристик і спитали себе: «Гаразд, із чого нам починати завтра? Що є найважливішим для клієнтів? Як нам принести їм цінність швидше за будь-кого іншого?» Як каже Скотт Максвелл, складність тут у визначенні не чого ви хочете досягти, а чого ви можете досягти. Це справджується для всього: будуєте ви будинок чи виробляєте авто, пишете книжку чи створюєте відеогру, вичищаєте сміття чи боретеся зі злочинністю. Визначте, де можна принести найбільшу цінність за найменших зусиль, і зробіть це одразу. Потім продовжуйте збільшувати цінність крок за кроком. Озирнутись не встигнете, як створите чи презентуєте щось із реальними результатами, які можна продемонструвати. Ключем до цього є розставляння пріоритетів у роботі.
Як вам це зробити? Насамперед вам потрібен хтось, хто може визначити як бачення, так і цінність. У Scrum ми називаємо таку особу власником продукту.
Власник продукту
У Scrum є лише три ролі. Ви є або членом команди та виконуєте роботу, або Scrum-майстром та допомагаєте команді визначити кращі методи роботи, або власником продукту. Усі ці ролі детально описано в додатку цієї книжки. Власник продукту вирішує, якою має бути робота. Він чи вона розпоряджається беклогом переліком завдань і, найважливіше, пріоритетністю їх виконання.
Створюючи першу Scrum-команду в 1993 році, я не мав власника продукту. Я був членом керівної команди та мав купу інших обовязків, окрім визначення, що саме повинна робити команда в кожному спринті. Я займався керівництвом та маркетингом, вирішував питання з клієнтами та накреслював загальну стратегію. Але в тому першому спринті я виявив, що цілком можу керувати беклогом. Потрібно було просто слідкувати за тим, щоб мати досить сюжетів, побажань та характеристик для роботи команди протягом наступного спринту. Проблема полягала в тому, що після другого спринту ми запровадили щоденні стендапи обговорення стоячи. Уже в наступному спринті швидкість роботи підвищилась на 400 відсотків, і команда за тиждень закінчила те, що мало б зайняти в нас місяць. У них закінчилися завдання з беклогу, над якими треба було працювати! Я ж собі думав, що маю місяць для планування нових завдань. Доволі велика проблема, погодьтеся, але її треба було якось розвязувати. Тому я й подумав про цю роль власника продукту та про якості, потрібні для належного її виконання.
Розробляючи її, я надихався роллю головного інженера компанії Toyota. Людина на цій посаді відповідає за всю виробничу лінію окремої моделі, наприклад, Corolla чи Camry. Для цього вона має задіяти таланти груп працівників, які спеціалізуються на створенні корпуса, коліс, електропроводки тощо. Головний інженер має обєднати групи окремих фахівців, щоб створити єдину багатофункціональну команду, здатну зібрати авто. За межами Toyota цих легендарних головних інженерів (або шуса, як їх називають у Японії) вважають всесильними лідерами так званого «шляху Toyota». У певному розумінні це правда. Але влади при цьому вони не мають. Ніхто їм не підзвітний радше вони самі підзвітні своїм групам. Люди можуть вказувати головним інженерам на їхні помилки, тому вони мають стежити за правильністю своїх рішень. Вони не дають нікому оцінок продуктивності, підвищень чи заохочень. Вони лише приймають рішення щодо бачення авто і способів його виготовлення шляхом переконання, а не примусу.
Саме цю ідею я й хотів утілити в системі Scrum. Джон Шук з Інституту ощадливого підприємництва якось почав свій опис ролі головного інженера цитатою з інструкції для командного складу морської піхоти США:
Відповідальність людини за лідерство не залежить від влади глибоко вкорінене припущення, що влада має дорівнювати відповідальності, є коренем великого організаційного негаразду. Я вважаю, що непорозуміння навколо цього питання загрозливе й проблемне, воно проникло в нашу свідомість так глибоко, що ми цього навіть не усвідомлюємо[41].
Згадуючи свій досвід, набутий у Вест-Пойнті та Вєтнамі, я цілком погоджуюсь, що лідерство не має нічого спільного із владою. Радше воно серед іншого стосується знань та готовності служити людям. Головний інженер Toyota не може просто наказувати виконати щось конкретним способом. Він має переконувати, лестити й демонструвати, що його спосіб є правильним, найкращим. Зазвичай, щоб грати цю роль, потрібні десятиліття досвіду. Я хотів запровадити її у Scrum, але я також добре знав, що дуже небагато людей мають такий рівень досвіду та навичок. Тому я розбив цю роль на дві, віддавши питання як робити Scrum-майстрові, а що робити власникові продукту.
Згадуючи свій досвід, набутий у Вест-Пойнті та Вєтнамі, я цілком погоджуюсь, що лідерство не має нічого спільного із владою. Радше воно серед іншого стосується знань та готовності служити людям. Головний інженер Toyota не може просто наказувати виконати щось конкретним способом. Він має переконувати, лестити й демонструвати, що його спосіб є правильним, найкращим. Зазвичай, щоб грати цю роль, потрібні десятиліття досвіду. Я хотів запровадити її у Scrum, але я також добре знав, що дуже небагато людей мають такий рівень досвіду та навичок. Тому я розбив цю роль на дві, віддавши питання як робити Scrum-майстрові, а що робити власникові продукту.
Навіть у перші дні Scrum я знав, що мені потрібний хтось для тісного звязку з клієнтом. Після кожного спринту власник продукту має передавати команді відгуки споживачів. Він повинен проводити половину свого часу за розмовами з людьми, які купують продукт (дізнаючись їхні думки про найсвіжіший реліз та його цінність для них), а другу половину з командою, розробляючи беклог (показуючи їм, що клієнт цінує, а вони ні).
Запамятайте: «клієнтом» може бути масовий споживач, великий банк, ваш чоловік або хтось, хто потребує ротавірусної вакцини та залежить від вас, щоб її дістати. Клієнтом є той, хто отримає цінність від того, що ви робите.