Найняти Продакт Оунера: 82 питання для співбесіди

Усе просто. 82 запитання для співбесіди на роль Продакт Оунера від Стефана Уолперса, відомого коуча з Age of Product, що має 16-річний практичний досвід роботи з XP і Scrum, у тому числі в ролі Product Owner і Scrum Master, а також досвід найму продактів і скрам-майстрів у команди.

Вступ

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

Сама по собі роль власника продукту ускладнює процес найму. Продакт Оунер — найменш чітко визначена і водночас найбільш багатоаспектна роль у Scrum.

Власник продукту є інноватором, а отже, створює цінність для клієнтів і організацій, якщо отримує змогу працювати гнучко. Власник продукту також є найбільш вразливою роллю Scrum. Зробіть з нього “руки”, які реалізовують лише ідеї стейкхолдерів, позбавте Продакта права говорити «ні» — наприклад, захищаючи беклог продуку — і власник продукту швидко стане ахілесовою п’ятою будь-якої гнучкої організації.

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

Наступні запитання для співбесіди не підходять і не призначені для того, щоб перетворити недосвідченого інтерв’юера на спритного експерта з розробки програмного забезпечення. Але в руках досвідченого фахівця вони підтримують з’ясування того, хто з кандидатів успішно працював у гнучких окопах у минулому. Пам’ятайте, «Agile» – це спосіб мислення, а не методологія. Отже, жоден контрольний список не може привести ваш успіх у наборі до бажаного результату.

Питання для співбесіди з власником продукту в цьому PDF-файлі змодельовані на основі цілісної моделі розробки гнучкого продукту для програмних продуктів:

Ця стаття містить як запитання, так і підказки щодо можливих очікувань від відповідей кандидата. Це повинно дозволити інтерв’юеру глибше зануритися в розуміння кандидатами Scrum і їх гнучке мислення. Однак зауважте, що:

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

Набір питань для співбесіди з власником продукту №1: Роль Scrum Product Owner

Ця категорія стосується мета-рівня ролі Власника продукту та процесу Scrum.

• 1. Яка головна мета аджайлу?

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

• 2. Як би ви охарактеризували свою роль як власника продукту? Ви фасилітатор, тренер, менеджер, провидець, тактик, координатор чи драйвер?

Це відкрите запитання, щоб краще побачити розуміння кандидатами своєї ролі. Власник продукту — це керівна роль, яка не надає повноважень у традиційному розумінні управління. Таким чином, власник продукту частково представлений усіма лейблами, згаданими в запитанні. Роль власника продукту також називають «ботлнеком» або «ахіллесовою п’ятою скраму»; будь-яка згадка про це, безсумнівно, буде плюсом. Якщо кандидат здебільшого говорить речі на кшталт «Я створюю історії користувачів», варто детальніше розпитати його, що він має на увазі.

• 3. Як би ви описали різницю між Продакт Оунером і Продакт Менеджером? Чи може, обидві ролі – це просто різні назви для ідентичних обов’язків?

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

• 4. Чи пересікаються між собою ролі Product Owner і Product Manager?

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

• 5. Коли ви востаннє говорили стейкхолдерам «Ні»? За яких обставин і які ваші висновки з ситуації?

Здатність говорити «ні» — це важлива кваліфікація і розширення можливостей для кожного Продакт Оунера. Наприклад, потрібно захистити команду від улюбленого, але сумнівно цінного проєкту стейкхолдера. Або покінчити з відокремленим мисленням і локальною оптимізацією всередині організації. Власники продуктів створюють цінність, доставляючи потрібний продукт і максимізуючи обсяг навмисно невиконаної роботи. Через це організація має поважати їхнє «ні». Інакше вони не виконуватимуть своєї ролі: максимізації цінності продукту для всієї організації. Застосування Scrum без уповноваженого власника продукту створює чудовий процес Waterfall 2.0. Таким чином, повноваження власника продукту у продуктовому беклозі можуть слугувати лакмусовим папірцем прийняття організацією принципів гнучкості.

• 6. Беклог продукту контролюється «продуктовою радою». Він регулярно збирається та застосовує своєрідний процес а-ля Stage Gate® для затвердження пріоритетів. Чи можете ви діяти як уповноважений власник продукту, якщо ви не контролюєте Беклог продукту?

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

• 7. Які «ярлики» спадають вам на думку, коли ви думаєте про свою роль як власника продукту?

СЕО продукту, візіонер, стратег, слуга-лідер без повноважень, підприємець, новатор, системний мислитель.

• 8. Як ви співпрацюєте з іншими членами скрам-команди?

Рано, часто, з повагою, прозоро, респонсивно, відповідаю з належною швидкістю та увагою. Як зазначено в Скрам Гайді 2020:

• 9. Якби ваш Scrum Master запропонував можливий курс продукту, як би ви відреагували?

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

• 10. Якщо ви «клієнт», який замовляє фічі, а скрам-майстер – представник команди, яка здійснює доставку, як вам найкраще співпрацювати?

Найкращий спосіб співпраці для PO та Scrum Master ґрунтується на цінностях Scrum. Обидвоє займають керівні посади, не поступаючись жодними повноваженнями. Обидва залежать одне від одного у досягненні мети спринту. Обидва є союзниками у навчанні організації аджайлу. Щодня власник продукту несе відповідальність за оперативне надання відгуків щодо продукту, роз’яснення цілей і забезпечення того, щоб кожен член скрам-команди розумів візію і стратегію продукту. Scrum Master, у свою чергу, має підтримувати Власника продукту у формуванні дієвого Беклогу продукту, одночасно сприяючи ефективній співпраці всередині скрам-команди.

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

У ідеальному світі члени кросфункціональної команди оволодівають усіма навичками, які необхідні Scrum-команді для самостійного надання цінності клієнтам. Це може працювати для продукту на ранній стадії, коли одна команда займається всім. Коли організації потрібно масштабуватись, робота з взаємозалежностями (іншими командами) стає необхідністю. Фактичний склад команди сильно залежить від її задач. Типовими ролями в кросфункціональних командах є бізнес-аналітики або дата-аналітики, UX/UI дизайнери, розробники (front-end, back-end), QA й AQA, DevOps тощо.

• 12. У яких скрам-подіях має брати участь власник продукту?

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

• 13. Чи потрібно мати візію продукту, щоб бути успішним у ролі власника продукту?

Безумовно так. Або, цитуючи Льюїса Керролла:

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

• 14. Як власник продукту стає ботлнеком для скрам-команди?

Сповільнення роботи скрам-команди відбувається часто тому, що процес керування Беклогом продукту є недосконалим: елементи Product Backlog створюються незадовго до початку спринту або не відповідають стандартам якості, оскільки PO не може виділити достатньо часу на їх створення та доопрацювання. PO може бути недоступним для питань, які задаються під час спринту. Щоб зменшити ризик такого впливу власника продукту на команду, потрібно залучати інших членів скрам-команди раніше або й узагалі – заохочувати колективне володіння продуктом. Цей підхід значною мірою підтримується створенням спільного розуміння цілей на рівні команди. (Почніть із «Чому ми це робимо?»)

• 15. Як ви знаєте, що ви гарний власник продукту?

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

Набір №2: Продакт Діскавері та зовнішні стейкхолдери

Ця категорія запитань для співбесіди з Продакт Оунером говорить про діскавері (відкриття) та управління продуктом.

• 1. Чи вважаєте ви, що Scrum адекватно керує процесом відкриття продукту?

Lean UX, Lean Startup, Design Thinking або Service Design — це інші гнучкі практики, які набагато краще підходять для відкриття продукту, ніж Scrum. Усе, на що посилається Scrum, це те, що власник продукту несе відповідальність за керування Беклогом продукту. Вважається, що Product Owner – та людина, яка знає, що несе цінність у будь-який момент часу. Але Scrum не пояснює, як власник продукту отримує цю інформацію.

• 2. Як народжуються нові ідеї та вимоги до них?

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

• 3. Які практики та структури ви можете використати, щоб дізнатися про потреби своїх клієнтів?

Кандидат має назвати декілька провідних гнучких фреймворків, таких як Jobs-to-be-done, Lean UX, Lean Startup, Design Sprints, Service Design, design etnography та lean user testing, NPS, Voice of Customer та інші.

• 4. Як включити дослідження користувачів у процес відкриття продукту?

Дослідження користувачів або краще: тестування користувачів, має бути безперервним, регулярним заняттям у будь-якій організації, що керується продуктом. Це важлива частина гнучкого циклу створення-вимірювання-навчання. На практиці це означає, що спілкування з дизайнерами та UX researchers стає невід’ємною частиною роботи PO та всієї команди. (В ідеалі вони належать до самої команди.) Крім того, відгуки клієнтів постійно збираються шляхом проведення частих інтерв’ю та спостережень користувачів. Ці речі стосуються і технічних проєктів, наприклад, API-сервісів.

• 5. Скільки часу ви приділяєте дослідженню користувачів і розумінню потреб клієнтів?

Проводити 50% часу з клієнтами було б чудово. Менше 10%, і якщо ніхто інший не займається діскавері продукту від імені Власника продукту, означає що процес потребує покращення. Наприклад, потрібно звільнити PO від адміністративних завдань, таких як написання історій користувача. (Примітка: власник продукту не має бути головним автором user stories.)

• 6. Як би ви хотіли щоб виглядав процес роботи з ідеями з боку стейкхолдерів та інших членів організації?

Активне залучення зацікавлених сторін і членів загальної організації до процесу відкриття продукту – це правильний підхід. Людям подобається мати мету і бути частиною чогось більшого, ніж вони самі. Надання можливості робити внесок кожному, незалежно від його посади в організації, полегшує роботу PO. Процес такого рівня включення не потребує хитромудрих технологій. Щоб запустити його, досить буде навіть звичайної загальнодоступної excel-таблички або форми. Перший шаблон для пропонування фіч може містити питання, типу “чому”, “що” та “для кого”. Він може відповідати тактичному чи стратегічному характеру пропозиції, можливим часовим рамкам або оцінці очікуваного повернення інвестицій. Найважливіше те, що розробка процесу має бути гнучкою: починаємо з MVP, а потім вдосконалюємо його, коли вже отримано перший досвід.

• 7. На якому етапі ви залучаєте Scrum-команду до діскавері продукту?

Якомога раніше. Для такої практики є три головні причини:

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

• 8. Як визначити, чи ідея варта інвестицій?

Існують кількісні та якісні категорії, як-от збільшення доходу, вигоди від скорочення витрат завдяки вдосконаленню внутрішніх процесів, підвищення рівня задоволеності клієнтів (NPS), підписки клієнтів на нові продукти, позитивні відгуки клієнтів у службі підтримки тощо. Кандидати на позицію Продакт Оунера повинні продемонструвати свої знання щодо того, який Беклог продукту придатний до реалізації, максимізуючи цінність роботи розробників від імені клієнтів. Це дозволяє обговорювати результати продукту, а не результати роботи, уникнути зростання “фабрики фіч” і подолати індустріальну парадигму загалом.

• 9. Як уникнути неправильного розподілу ресурсів на функції чи продукти, які нікому не потрібні?

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

• 10. На яких етапах власники продуктів беруть участь у плануванні?

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

Набір питань №3: управління внутрішніми стейкхолдерами

Ця категорія питань для співбесіди з Продакт Оунером стосується конкретних аспектів стосунків власника продукту з внутрішніми стейкхолдерами.

• ​​1. Нещодавно ваша організація вирішила стати гнучкою та орієнтованою на продукт. Як ви проінформуєте стейкхолдерів про наслідки?

Хорошою відправною точкою було б працювати з «Маніфестом гнучкої розробки програмного забезпечення», переконавшись, що люди розуміють, що адаптація до змін замість дотримання плану має першочергове значення для майбутнього успіху організації. Зацікавлені сторони також повинні розуміти, що «вимоги» (і, отже, ймовірно, зусилля з локальної оптимізації) більше не є дійсною формою процесу доставки продукту. Натомість безперервне відкриття продукту, ітеративна й поступова розробка стають основними принципами, що дозволяють вдосконалювати експерименти та навчатися на помилках передових практик. Стати гнучким означає конкурувати з іншими — ймовірно, більш цінними — ідеями продукту за дефіцитні ресурси та визнати, що PO є воротарем беклогу. Більше немає довільних дат доставки, натомість є інтервали доставки, під час яких знання сьогоднішнього дня проєктуються в майбутнє. Зрештою, стейкхолдери мають усвідомити масштаб наслідків відмови від командно-контрольного стилю управління та надання повноважень автономним і самоорганізованим командам для доставки продукції.

• 2. Як ви організовуєте співпрацю зі стейкхолдерами та вдосконалюєте її з часом?

Комунікація та прозорість мають вирішальне значення для ефективної співпраці із зацікавленими сторонами. Існують різні способи формування та вдосконалення цього спілкування з часом. Наприклад, можна встановити регулярні зустрічі з кожним зі стейкхолдерів або попросити їх вказати на когось, хто буде так званим “послом” продукту, виступатиме в ролі “зв’язкового”. Організувати воркшопи зі стейкхолдерами й послами, попросивши Scrum-майстра та розробників про допомогу. Об’єднатися з UX-фахівцями й організувати зустрічі по user journeys або сторімапінгу. Запросити стейкхолдерів на зустрічі Product Backlog Refinement, щоб пояснити цінність історій користувачів Scrum-команді. Також підходять сесії огляду спринту (спринт рев’ю) та інтерв’ю з користувачами.

• 3. Як ви комунікуєте зі стейкхолдерами, які не хочуть співпрацювати?

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

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

Згодом непогано працюватимуть і типові події, як Sprint Reviews, демонструючи цінність, поставлену скрам-командою протягом спринту. У крайньому разі, якщо геть нічого не спрацює, PO може попросити про підтримку стейкхолдера C-рівня.

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

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

• 5. Як ви ставитеся до пет-проєктів?

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

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

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

• 7. Відділ продажів обіцяє клієнтам фічі заради укладання з ними угод без попередньої домовленості з вами. Як ви з цим справляєтеся?

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

• 8. Як ви ставитеся до пропозицій стейкхолдерів та інших членів організації щодо нових фіч і продуктів?

Гарною відправною точкою є створення системи управління ідеями. Це може бути простий шаблон, який охоплює питання про те, що, чому, коли, для кого та рентабельність інвестицій. Оцінюючи ідею, обов’язково слід спілкуватися з людиною, яка її подала. Якщо ідею взято в реалізацію, залучіть автора до процесу. Наприклад, запросіть його на воркшоп зі складання історій користувача або тестування продукту користувачами. Забезпечте безперервний зворотний зв’язок протягом усього циклу розробки та доставки з регулярними контрольними точками щодо початкових цілей. Нарешті, через 3–12 місяців після доставки, повідомте зацікавленій стороні, чи результати виправдали очікування (наприклад, рентабельність інвестицій, економія коштів, залученість та інші KPI).

Набір №4: Портфоліо і планування дорожньої карти продукту

Питання в цьому наборі стосуються однієї з найбільш суперечливих тем у професії: як сформувати гнучкі родмапи продуктів?

• 1. Бачення продукту та стратегія у вашій організації зберігаються під грифом “Секретно”, щоб запобігти викраденню ідей конкурентами. Чи завадить це вашій роботі як власника продукту?

Так, це значно ускладнить роботу власника продукту, оскільки задля ефективного впровадження інновацій необхідна прозорість. Сьогодні інновації – це командний вид спорту. Блискуча особистість, яка самотужки створює великі інновації, — це міф. (Навіть пан Джобс не вважав себе такою людиною.) Ну, а спільна командна робота починається зі спільного розуміння бачення продукту та його стратегії.

• 2. Хіба планування портфоліо і продукту не є анахронізмом у гнучкій організації?

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

• 3. Який ваш підхід до створення дорожніх карт продукту?

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

• 4. Як часто слід планувати родмапи продуктів?

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

• 5. Як підключити команди до бачення продукту? Як донести до них, як їхній внесок впливає на втілення візії в життя?

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

• 6. Хто має брати участь у плануванні дорожньої карти продукту?

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

• 7. Скільки часу ви витрачаєте на спілкування з клієнтами та дослідження галузевих тенденцій?

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

• 8. Яке відношення має Монте-Карло до запланованих дат доставки?

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

Набір №5: Беклог продукту, уточнення беклогу, робочі елементи, прогнози та оцінки

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

• 1. Яка мета Product Backlog Refinement?

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

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

• 2. Скільки часу потрібно витратити на доопрацювання беклогу?

Незважаючи на те, що Скрам Гайд 2020 скасовує попередні вказівки щодо розподілу часу, загальноприйняте правило – до 10% часу скрам-команди для уточнення Беклогу продукту.

• 3. Як би ви організували процес уточнення елементів Беклогу продукту?

Загалом, корисно структурувати процес уточнення навколо таких питань, як:

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

• 4. Над якою кількістю елементів продуктового беклогу ви можете паралельно працювати, щоб забезпечити постійну доставку цінності для клієнтів і компанії?

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

• 5. Ви любите використовувати Backlog продукту як свого роду сховище, додаючи ідеї, щоб продовжити роботу над ними на пізнішому етапі. З часом ви створили понад 500 тікетів на різних етапах. Як гадаєте: чи може команда Scrum працювати ефективно на 500 тікетах?

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

Особливо не варто заспокоювати настирливих стейкхолдерів, просто додаючи їхні ідеї до Product Backlog. Це не вирішує проблеми; це просто відкладає неминуче обговорення, оскільки тепер зацікавлені сторони очікуватимуть, що скрам-команда створить їм Інкремент.

• 6. На якому рівні ви залучаєте інших членів команди до процесу рефайнменту?

По готовності каркасу задачі.

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

• 7. Як визначити цінність елемента беклогу продукту?

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

Додаткові показники доступні в моделі Scrum.org Evidence-based management.

• 8. Як ви пояснюєте членам команди цінність елемента продуктового беклогу?

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

Бажано, щоб члени Scrum-команди знали про це заздалегідь, оскільки вони мають регулярно брати участь у user testing (тестуванні на користувачах)..

• 9. Які хороші практики замовлення елементів продукту Backlog?

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

• 10. Як ви справляєтеся з помилками та технічним боргом, коли багато цінних нових функцій конкурують за ресурси?

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

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

Тому доцільно виділяти близько 20% потенціалу скрам-команди для компенсації технічного боргу в будь-який момент часу. Досвідчені власники продуктів підтримують це довгострокове мислення.

• 11. Чому user story mapping є корисною технікою для власників продуктів?

Картування історій користувачів — чудовий спосіб візуалізації «загальної картини» в беклозі продукту. Крім того, юзер сторі мепінг (пробачте, це калькування винятково щоб люди, які так гуглять, знайшли те, що їм потрібно) є інструментальним засобом для покращення спілкування із зацікавленими сторонами та командою. Ці зустрічі формують спільне розуміння продукту в різних командах, позиціях та відділах.

• 12. Як найкраще створювати елементи беклогу продукту?

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

• 13. Як має виглядати хороша історія користувача? Яка її структура?

Для розробки програмного забезпечення атрибутами зразкової історії користувача є:

• Наявність опису
• Визначеність критеріїв готовності
• Поміщається в спринт
• Містить усі елементи інтерфейсу
• Виявлено всі ймовірні залежності та блокери
• Визначено метрики успішності
• Оцінено командою

Читайте «Три-К» Рона Джеффріса і “Принцип ІНВЕСТУВАННЯ” Білла Уейка.

• 14. Де ви обговорюєте історії користувачів, лише під час доопрацювання?

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

Асинхронні обговорення – скоріше виняток, ніж правило, для кейсів, коли члени команди або продакт не можуть з’явитися на зустріч.

Уникайте тривалих обговорень тікетів. Це ознака слабкості попереднього відбору.

• 15. Які типові підводні камені уточнення беклогу (Product Backlog Refinement)?

• Недостатньо сеансів уточнення, що робить беклог неякісним.
• Забагато сеансів уточнення, що робить беклог надто детальним, схожим на каскадну модель.
• Перетворення вимог у юзер сторі без залучення скрам-команди.
• Залучення до уточнення лише провідного інженера команди.
• Відсутність стейкхолдерів.

Це відкрите питання дозволяє кандидату у Продакт Оунери поділитися своїм попереднім досвідом і тим, як він вплинув на їх поточне розуміння керування беклогом продукту.

• 16. Чи потрібно писати детальні критерії готовності разом з історією користувача?

Загалом критерії готовності (Acceptance criteria) визначають функціональні та нефункціональні вимоги до продукту або його фічі. Рівень деталізації може відрізнятися залежно від характеру завдання. До їх створення доцільно залучати Scrum-команду, оскільки деякі з них можуть бути уже враховані у визначенні готового.

• 17. Команді потрібен час, щоб дослідити технічну проблему з історією користувача, щоб краще зрозуміти вимоги. Як ви продовжуєте процес уточнення конкретної історії користувача?

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

• 18. Один зі стейкхолдерів надає вам такі докладні вимоги, що ви просто копіюєте їх у елементи беклога. Та ваша скрам-команда не задоволена таким підходом. Чому так?

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

• 19. Коли б ви видалили фічу?

Краще б і зовсім таку фічу не створювати.

Якщо, незважаючи на всі етапи перевірки під час Product Discovery, фіча з низькою цінністю прослизне в Product Backlog і буде доставлена, слід її якнайшвидше видалити. Те саме стосується наявної фічі, яка втратила корисність.

Набір №6: Планування Спринту, Спринт, Рев’ю (Огляд) Спринту, Ретроспектива

Шоста категорія питань адресується власне до Спринту.

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

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

• 2. Чи варто Продакт Оунеру асайнити робочі елементи на конкретних членів Скрам-команди?

Це неприйнятно. Це мають робити самі розробники.

• 3. Чи має Продакт Оунер брати участь у всій події Планування Спринту?

Давайте поглянемо на Планування Спринту детальніше.

Продакт Оунер презентує бізнес-цілі наступного Спринту Скрам-команді. У співпраці з ним Скрам-команда створює Ціль Спринту. Тоді розробники обирають – враховуючи обставини, наприклад, доступну капасіті, – елементи Беклогу, які вони вважають необхідними, щоб досягти Цілі Спринту. Тут присутність Продакт Оунера просто необхідна.

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

• 4. Чи має Продакт Оунер відвідувати Дейлі Скрами?

Обов’язково. Це допоможе швидко надати відповіді розробникам і уникнути затримок.

• 5. Ваша Скрам-команда, з ваших відчуттів, регулярно оцінює елементи за найвищими можливими рамками. Виглядає, що вони намагаються щоразу “підстелити соломки” у випадку, якщо щось піде не так. Як ви з цим справляєтеся?

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

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

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

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

• 7. Чи має власник продукту право вето, коли йдеться про випуск інкрементів продукту?

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

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

• 8. Чи потрібно релізити кожен інкремент продукту, який було завершено під час спринту?

Scrum-команда вирішує, коли і який інкремент для клієнтів потрібно релізити.

• 9. Як би ви організували Sprint Review?

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

• 10. Під час Sprint Review розробники показують фічі, яких ви ніколи раніше не бачили. Як ви реагуєте?

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

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

• 11. Після закінчення спринту ви берете участь у Ретроспективі?

Звісно, адже власник продукту так само є членом скрам-команди.