Product Owner: як розвивати кар’єру і які книги прочитати вже зараз?

Що потрібно власнику продукту, щоб виправити помилки, підвищити компетентність і розвиватися професійно? Яку літературу має опрацювати кожен Product Owner?

У Agile.Live ми неодноразово наголошували на тому, що попит на професію власника продукту тільки зростатиме у найближчому майбутньому через стрімкий розвиток цифрових технологій у світі.

До того ж, брак компетенції Product Owner та нерозуміння цієї ролі топ-керівництвом може надто дорого коштувати компанії.

Тому, підготувавши понад 1000 власників продукту для банків, авіакомпаній, розробників, ми ділимося цінними порадами для тих, хто починає свій шлях власника продукту.

Питання, які нам часто ставлять початківці, приблизно такі:

Василь: “Здається, мене ненавидять усі. Розробники мене не сприймають. Керівники постійно виставляють претензії. Сьогодні їм давай одне, завтра інше. В команді напруга. Хто в усьому винен? Я. Що роблю не так?”
Ден: “У нас не було ні продукт-овнера, ні фінансів, щоб його найняти. Так я став власником продукту. Здається, дуже багато на себе взяв. Що робити?”
Надя: “Працюю продукт-овнером недавно. Сертифікації поки що не маю, але хочу розвиватися в цій сфері. Що порадите почитати?”

Щоб дати відповідь на ці та схожі проблеми, розгляньмо три питання:

1. Проблеми початківців.
2. Три напрямки роботи власника продукту.
3. Два початкові рівні Product Owner: Analyst і Proxy.

I. Проблеми початківців

Звернімо увагу на три типові проблеми початківців:

1. Критика продукт-овнерів.
2. Непослідовність.
3. Перевантаження.

1. Критика продукт-овнерів

Річ у тім, що людям притаманно шукати ідеали й вірити у них. Недарма кажуть, “Щоб не розчаровуватися — не зачаровуйся”. Керівники й команда уявляють перед собою ідеал, а коли власник продукту йому не відповідає, звинувачують його у всіх смертних гріхах.

Певна річ, легендарні особистості, що змінили світ, існують. Наприклад, багато хто вважає ідеальним продукт-овнером Джейн Меннінг (Jane Manning). За два роки вона створила продукт Google Adwords, маючи в команді лишень десятьох співробітників.

Спочатку пошукова система Google була надзвичайно простою для користувачів і не дратувала їх барвистою рекламою, на відміну від конкурентів. Саме легкістю й простотою Ґуґл і покорив серця користувачів.

Джейн Меннінг знайшла потрібні слова й аргументи, щоб переконати топ-менеджерів Google у необхідності запровадити рекламний сервіс, зберігаючи водночас місію і принципи Ґуґл.

Результат — плюс $60 млрд.

Відтоді кожен топ-менеджер дивується, чому їхній продукт-овнер — не Джейн Меннінг.

Хоча критика власників продукту часто має підґрунтя. Наприклад, у разі, коли він не зовсім розуміє три головні напрямки своєї роботи (див. далі) й автономності в межах скрам-системи, через що діє непослідовно.

2. Непослідовність

Більшість проблем виникає через непослідовність власника продукту.

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

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

3. Перевантаження

Непослідовність початківця веде до його перевантаження.

Намагаючись догодити всім, власник продукту бере на себе надто багато обов’язків, занурюється у подробиці (якими має займатися команда), слабо комунікує з керівництвом, бо воно постійно зайняте й не має часу на обговорення.

Тож як навести лад у роботі власника продукту? Чим насправді він має займатися?

II. Три напрямки роботи власника продукту

Власник продукту відповідає за три напрямки роботи:

1. Постійна взаємодія з командою.

Разом із командою інженерів, розробників, тестувальників власник продукту має з’ясувати, як у найдешевший спосіб вирішити завдання бізнесу.

Експертна думка:

“Типова помилка початківців — тонути в деталях. Не знаючи, як правильно писати вимоги, власники продукту починають прописувати їх надто детально. Вдаються до технічних подробиць, специфікацій, надмірної деталізації. Цього робити не потрібно.

Аджайл-підхід передбачає опис ПРОБЛЕМИ, яку потрібно вирішити, а традиційний — готове РІШЕННЯ. Різниця між підходами кардинальна.

Від такої “класики” потрібно відучитися. Адже рішень може бути декілька, і це вже справа команди — надати різні варіанти.

Рішенням має бути конкретна пропозиція того, що справді можна реалізувати в обмежений часом період”.
— В’ячеслав Москаленко,
сертифікований тренер Scrum, співзасновник Agile.Live

2. Взаємодія зі стейкхолдерами.

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

Ідеальним прикладом взаємодії з топ-менеджментом є Джейн Меннінг (див. вище), яка, окрім власної компетентності, уміла знаходити спільну мову і з бізнесом, і з командою.

3. Зв’язок із користувачами.

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

Ось чому роль продукт-овнера не така проста, якою здається на перший погляд.

Тож як власникам продукту розвиватися професійно?

Варто усвідомити, що для початку кар’єри Product Owner зовсім не обов’язково бути гуру. Однак необхідно навчитися аналізувати, працювати у зазначених трьох напрямках, поступово розширювати свою “експертизу”.
З цією метою до нас, власне, і звертаються для проходження тренінгу чи сертифікації (див. розклад тренінгів), проте кожен може опрацьовувати професійну літературу самостійно.

Які саме книги ми рекомендуємо, щоб розвивати ці три напрямки власника продукту?

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

Адже для кожного рівня є своя література. Розгляньмо два такі рівні й рекомендації для кожного з них.

III. Два початкові рівні професійного розвитку власника продукту

Отже, найперше, що має з’ясувати продукт-овнер, це свій теперішній рівень на шкалі професійної компетентності Product Owner:

Звернімо увагу на перші дві сходинки: Analyst і Proxy.

Для багатьох вони найважливіші, бо, не зрозумівши їхню специфіку, власник продукту постійно наступатиме на одні й ті ж ґраблі й не зможе досягти суттєвих результатів.

1. РІВЕНЬ ANALYST

Що повинен уміти власник продукту на цьому рівні:

• аналізувати;
• пріоритезувати.

Вміння аналізувати

1. Власник продукту повинен уміти аналізувати інформацію і доносити її в зрозумілій формі до розробників. Іншими словами, відповідати на запитання: “Що хоче від команди бос?” При тому, розуміти бюджетні, технологічні та інші можливості компанії.

2. Формулювати проблему.

Власник продукту повинен уміти формулювати проблему.

Чому постановка проблеми — “проблема”? Бо зазвичай керівники приходять до розробників із надто абстрактними, загальними, не до кінця зрозумілими ідеями.

Це передбачає серйозні ризики. Наприклад, команда може щиро й віддано вкладати час, енергію та ресурси зовсім не в те, що хотів отримати бізнес. Усе через невміння чітко формулювати проблему.

Розгляньмо реальний приклад:

Керівник відділу продажів світової корпорації з виробництва спортивного одягу та взуття звернувся до розробників із проханням створити сервіс для збільшення продажу.

Він спостеріг цікаву тенденцію у поведінці споживачів: люди підходять із товаром до каси. Побачивши перед собою чергу, відкладають його і йдуть собі геть, нічого не купуючи. Проблема була системною і свідчила про “втрачені можливості”.

Тож менеджер поставив завдання: “Знайдіть якесь рішення”.

Власник продукту буквально передав ці слова команді, яка, недовго думаючи, узялася за реалізацію задуму.
За шість місяців потуг і витрачених ресурсів стейкхолдер прийшов на презентацію “рішення”. Хлопці показали інноваційну версію каси самообслуговування. Керівник департаменту з продажу ледь устояв на ногах. Він побачив зовсім не те, що хотів!

По-перше, програмісти й гадки не мали, наскільки витратним виявилося би втілення такого рішення для компанії. По-друге, якби менеджер хотів “каси самообслуговування”, то сам чітко про це би і сказав: “Зробіть мені нову версію кас самообслуговування”!

Як бачимо, невміння сформулювати проблему дорого коштує. Відповідно, на рівні Analyst кожен власник продукту має відшліфувати цю золоту навичку.

3. Розуміти основи організаційного менеджменту.

У великих організаціях між різними ланками (розробники, маркетологи, фінансові директори тощо) існує певна дистанція, що прямим чином ускладнює внутрішню комунікацію між відділами чи фахівцями із різних галузей.
До того ж, бізнесмени такого рівня зазвичай дуже зайняті люди, що відповідають за 500, 1000 і більше співробітників та відповідні процеси.

У такому контексті роль власника продукту рушійна.

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

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

5. Комунікувати. Власник продукту повинен уміти спілкуватися із вічно зайнятими керівниками. Домовитися про конкретний час із босом для узгодження дій, прояснення очікувань, обміну ідеями, узгодження напрямку, консенсусу (цього не відбулося у зазначеному вище випадку з касами самообслуговування).

→ Що читати?

Для рівня Analyst ми рекомендуємо опрацювати книгу Майка Кона “Користувацькі історії: гнучка розробка програмного забезпечення” (User Stories Applied for Agile Software Development. Mike Cohn. Foreword by Kent Beck). Російськомовна версія: “Пользовательские истории: гибкая разработка программного обеспечения. Майк Кон”.

Власник продукту має бути майстром формулювання “користувацьких історій” (User Story). Кожна User Story має тривати не довше, ніж одна ітерація (2 тижні), за час якої команда має реалізовувати 4-5 користувацьких історій.

Для опанування мистецтва формулювати користувацькі історії, власник продукту має володіти навички аналізу, завдяки чому усі (менеджерам, розробникам та іншим, кого стосується продукт) мають розуміти, над чим працюватиме команда, а за два тижні побачити результат, щоб узгодити наступні кроки.

Користувацькі історії формулюють таким чином, щоб команда могла оцінити їх з точки зору обсягу й часу для виконання.

Приклад звичайної користувацької історії: “Як постійний фасилітатор онлайн-сесій я хочу мати можливість проводити голосування для ухвалення ідеї за допомогою інтерактивних карток невеличкою командою із 3-4 осіб — для того, щоб не витрачати час на додаткові інструменти”.

Вміння пріоритезувати

Окрім аналізу, власник продукту відповідає за Product Backlog — “артефакт”, в якому збираються і пріоритезуються всі User Story (як один із методів опису завдання чи проблеми, яку потрібно вирішувати; проблема має бути лаконічною, зрозумілою і реалістичною для виконання за одну ітерацію).

Отже, окрім уміння формулювати користувацькі історії, власник продукту бере на себе більшу відповідальність — відповідає за беклог продукту, де пріоритезує їх з точки зору першочерговості й важливості.

→ Що читати?

Щоб формувати навичку пріоритезації, рекомендуємо для прочитання книгу “Професійний власник продукту. Використання скрам як конкурентної переваги”, автори Дон Макґреал і Ральф Джочем (The Professional Product Owner. Leveraging Scrum As A Competitive Advantage. Don McGreal, Ralph Jocham. Foreword by Ken Schwaber).

Сформувавши ці дві навички, аналізу й пріоритезації, можемо говорити про наступний рівень, Proxy.

2. РІВЕНЬ PROXY

Опанувавши навички аналітики й пріоритезації завдань, власник продукту має розвивати лідерські здібності.

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

Це передбачає таке:

• Власник продукту рівня Proxy володіє навичками планування (Agile Estimating and Planning);
• Наділений автономністю у межах Agile і Scrum.
• Проте автономність передбачає компетентність, обізнаність у “механіці”. Власник продукту добре розуміє, що таке storypoints і як їх використовувати для прогнозування.
• Вихід за межі вузького кола команди. Власник продукту комунікує з кінцевими споживачами.
• Тайм-менеджмент. Власник продукту володіє техніками керування часом.
• Уміння делегувати завдання в межах культури Scrum, долучати Скрам-майстра, команду.
• Розуміє розподіл ролей і подробиці скраму.
• Взаємодіє зі Скрам-майстром, який може дати цінну пораду щодо того чи того питання.
• Добре володіє аналітичними навичками попереднього рівня — уміє конкретизувати завдання, відсіяти зайве внаслідок діалогу з різними сторонами, досягає консенсусу.

→ Що читати?

Радимо прочитати книги:

• Майк Кон. Agile. Оцінювання й планування проектів (рос. версія: “Agile. Оценка и планирование проектов. Майк Кон”, англ. оригінал: Agile Estimating and Planning. Mike Cohn).
• Гунтер Вергеєн. Скрам. Мудрий путівник мандрівкою Скрамом (Scrum. A Smart Travel Companion. A Pocket Guide. Gunter Verheyen)
• Джефф Паттон. Користувацькі історії. Мистецтво гнучкої розробки. (Рос. версія: “Пользовательские истории. Искусство гибкой разработки ПО. Паттон Дж.”, англ. оригінал: User Story Mapping: Discover the Whole Story, Build the Right. Discover the whole story, build the right product. Jeff Patton, with Peter Economy. Forewords by Martin Fowler, Alan Cooper, and Marty Cagan).

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

Підсумки

У цій статті ми розкрили три питання: типові проблеми початківців у ролі власника продукту, три їхні головні напрямки роботи, два рівні професійного розвитку: Analyst і Proxy.

Таким чином, на початку професійного шляху власник продукту має звернути увагу на таке:

1. Щоб мати успіх, не обов’язково бути гуру. Достатньо починати з простих, але чітко окреслених обов’язків у межах Скрам.
2. Найперша навичка — уміння аналізувати інформацію щодо розробки продукту, що надходить із різних джерел.
3. Уміння формулювати проблему, чітко ставити завдання, зрозуміло змальовувати користувацькі історії.
4. Продукт-овнер уміє пріоритезувати й зосереджуватися на головному.
5. Власник продукту розуміє свою автономність, а тому забезпечує послідовність у роботі й захист команди від втручань ззовні.
6. Product Owner активно комунікує — з’ясовує необхідні відомості, відповідає на запитання, роз’яснює.
7. У взаємодії з різними учасниками розробки власник продукту знаходить оптимальні рішення для бізнесу, враховує можливості бюджету, команди, технологій.

Ми також з’ясували, яку саме літературу кожен власник продукту має опрацювати самостійно для розвитку цих навичок.

Опанувавши перші два рівні професійної компетентності, Analyst і Proxy, власник продукту стане професіоналом, який робить усе для того, аби допомогти команді, захистити її, забезпечити її усім необхідним для плідної реалізації задуму. Таких поважатимуть і розробники, і представники бізнесу. За такими успіх.

ДОЛУЧИТИСЯ ДО AGILE.LIVE

Найближчі сертифікаційні тренінги Agile.Live: Professional Scrum Master (PSM), Professional Agile Leadership Essentials (PAL-E)
Підписатися на сторінку у LinkedIn
Підписатися на Telegram-канал Agile.Live
Підписатися на You-канал Agile.Live