Конференція ScrumDayUkraine 2021 — зовсім скоро! Ловіть early bird price, поки не відлетіла
29 Квітня, 2021 | 127 | 0.0  0.0

Кращі практики Власників Продукту: чекліст для самооцінки

Кращі практики Власників Продукту

Навіть поверхневий пошук за ключовими словами Product Owner best practices показує: думок про кращі практики безліч, та рідко хто відважиться говорити про роботу власника продукту системно, в форматі чек-листа або схеми. Одна з цікавих спроб створити систему — фреймворк для оцінки роботи PO від Роберта Гелена, аджайл-коуча й сертифікованого скрам-тренера з Нью-Йорка з 17-річним досвідом. Публікуємо статтю в українському перекладі й закликаємо поставитися до неї з інтересом, та не без критики.

За словами Гелена, його фреймворк побудований за аналогією з індексом опанування аджайлу Agile Maturity Index Біла Кребса (Bill Krebs). Цей індекс, у свою чергу, з’явився з багаторічної практики XP та скраму в командах Кребса і пов’язаний з інструментом самоперевірки команд IBM (IBM Rational Self-check for Software Teams TM).

Навіщо це оцінювати

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

Основні практики власників продукту узагальнені в чотирьох розділах:

  1. Програма-мінімум
  2. Базові практики
  3. Комунікація
  4. Управління

Розглянемо їх по черзі.

Програма-мінімум

Перше й головне — інвестиції в володіння продуктом, або точніше, у власника продукту в організації. Чи є у вас по PO на кожну команду і чи дійсно їхній основний обов’язок — робота з командою? Часто компаніям складно перейти на скрам саме через те, що доводиться інвестувати у власників продукту і скрам-майстрів. [А часом власнику продукту доводиться виконувати непосильний об’єм роботи, тому що організація не готова оплачувати йому тільки одну роль].

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

І нарешті, має значення беклог продукту. Тут багато протиріч: це вимоги/історії чи щось зовсім інше? Чи це часом не приблизний план релізу? Коротка відповідь: це все, що потрібно, щоб ефективно спрямовувати поставки команди. А той, хто керує цим процесом, і є власником продукту.

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

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

Історії користувачів

  • Чи використовуєте ви їх у полегшеному варіанті, а чи досі дотримуєтеся традиційних суворих вимог?
  • Якщо ви користуєтеся історіями користувачів, то чи розумієте ви, з яких трьох частин вони складаються і як правильно їх писати?
  • Чи є у вас розуміння критеріїв прийому й готовності (entry or readiness criteria)?
  • Що ви вкладаєте в формулювання критеріїв прийому як спосіб донести “що” й “чому” вашого бізнесу?

Беклог продукту

  • Чи працює у вас багатоаспектна пріоритизація з урахуванням потреб бізнесу, команди й технологій?
  • Хто володіє беклогом продукту — власник продукту чи команда?
  • Чи виконується активне уточнення беклогу і чи перевіряються історії так, щоб вони були описані максимально зрозуміло і реально для виконання?
  • Чи прогнозує власник продукту, як розвивається ситуація, щоб поділитися розумінням з командою?

Базові практики

Власник продукту не займається оцінками (естимацією) напряму. Але він створює потрібне середовище через уточнення беклогу, де елементи уточнює команда. Окрім командних оцінок, участь у таких активностях дає власнику продукту розуміння рівня складності і зусиль, потрібних команді для поставки фіч. Ця інформація корисна для продуктової стратегії та розкладу (workflow).

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

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

Оцінка

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

Пріоритизація

  • Стежте, щоб у вас була збалансована стратегія оцінки (пріоритизації) беклога продукту, яка враховуватиме бізнес, запити замовника і технічні фактори. Добре, коли стейкхолдери включаються в процес напряму (value poker).
  • Не бійтеся розбивати елементи беклогу на складові, зменшуючи їх об’єм і спонукаючи до експериментів, роздумів та пошуку фактів, щоб усі краще розуміли цінність.
  • Нехай у ваших критеріях релізу будуть метрики ROI з дорелізними цілями і реаліями пост-релізів. Навчайтеся і пристосовуйтеся до реалій за актуальними результатами команд і зворотним зв’язком на ретроспективі.

Постановка цілей

  • Для початку, чи є у вас послідовні цілі і на рівні спринту, і на рівні релізу? Чи достатньо вони чіткі та зрозумілі? Чи залучаєте ви команду до визначення їхньої реалістичності й раціональності?
  • Автор чек-листу вважає визначення готового (Definition of Done) своєрідною ціллю, що об’єднує роботу команди з очікуваннями стейкхолдерів.
  • Чи прозоре у вас досягнення цілей, а чи ви частково його приховуєте? Чи вбудовуєте ви в цілі певні хитрощі, щоб команда мала простір для інновацій і творчості?

Комунікація

Важлива частина такої необхідної для власників продукту комунікації — вміння отримувати максимальний ефект від скрам-подій і церемоній. Надто це важливо на огляді спринту й демо. Саме тут потрібно стежити, щоб команда поговорила про просування, про плани на майбутнє, а стейкхолдери побачили повну картину.

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

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

Огляд спринту

  • Чи показуємо ми програми, що постійно працюють, при цьому повністю дотримуючись критеріїв готовності (Definition of Done)?
  • Чи затвердили всю роботу, чи прийняли її, чи досягла команда цілей спринту?
  • Чи ходять на огляд спринту ключові стейкхолдери? Окрім відвідування, чи допомагають вони якось іще — чи задають питання, чи дають фідбек тощо?
  • Чи прив’язуєте ви результати до плану релізу? Скажімо, чи синхронізуєте ви результати попереднього спринту з задачами, до яких плануєте взятися далі?

Спілкування

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

Уміння слухати

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

Управління

Управління в цій частині сконцентроване на тому, щоб спрямовувати зусилля команди до бізнес-цілей, орієнтованих на клієнтів.

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

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

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

Продакт-менторинг і професійна спільнота

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

Бачення

  • Команда має розуміти місію і візію організації чи глобального проєкту, в рамках якого вона робить продукт.
  • Можна проводити project chartering, щоб почати роботу над проєктом. Часто це необхідність планувати реліз (наприклад, у SAFe існує поняття про Chartering в плануванні PSI…)
  • Використовуйте поняття Minimal Marketable і Minimal Viable (мінімально конкуретно- і життєздатного) для пояснення фокусу й цілей проєкту. Сюди ж входить сторімепінг, який прояснює, як розкриється функціональність і як вона вирішить проблеми клієнта.

Планування релізу. Дорожня карта

  • Тут ми рухаємось від бачення беклога продукту як “серії вимог і фіч” до динамічного потоку роботи, спрямованого на досягнення цілей бізнесу.
  • Правильним є втримувати баланс між активностями, пов’язаними з фічами, технічними вкладеннями і технічним боргом. Беклог не має прив’язуватися винятково до фіч.
  • Планування релізу має бути заняттям всієї команди і призводити до створення дорожньої карти та зобов’язань перед бізнесом з приводу результатів роботи. Тобто, команду потрібно залучати у створення бачення, планування поставки і прийняття зобов’язань (commitments). А у бізнесу таким чином з’являється розуміння варіативності цих зобов’язань.

Перекладено й адаптовано командою BrainRain за статтею Роберта Гелена Measuring Product Ownership — What Does ‘Good’ Look Like?Сам інструмент оцінки для власників продукту можна переглянути тут.