Доброто познаване на правилата в Scrum е необходимо, но съвсем не достатъчно условие за добрия ProductOwner (PO).  Тази роля е от изключителна важност за проекта и продукта като цяло, тъй като добре свършената работа може да направи вашата компания лидер в областта си, докато в обратния случай ви изпрати след всички конкуренти. Това налага много допълнителни изисквания към PO – като начало, добро разбиране за бизнес сферата, към която е ориентиран продуктът, умения за работа с клиенти от една страна, и с екипа от друга, и т.н.  И всеки проект и продукт имат своя специфика, затова е трудно да се дават готови рецепти за „добър PO“.

Въпреки това има въпроси, които винаги изникват по време на обученията или впоследствие, когато започнат първите спринтове. В този блог ще се опитам да дам насоки, в които да търсите решенията на тези въпроси, когато се сблъскате с тях.

В: Колко детайлни трябва да са описаниятa на елементите от продуктовия списък?

О: Едно от предизвикателствата за PO е да се научи да казва на екипа „какво“, а не „как“ трябва да се направи, особено когато той/тя е запознат със технологичните специфики на продукта. Ето защо писането на много детайлни описания на елементите в списъка може да се превърне в създаване на дизайн или подробна спецификация, която не оставя твърде много свобода на екипа да реши как да свърши поставената задача. Дори и да сте убедени, че с вашия голям опит давате най-доброто решение, при описанието на продуктовия списък се ограничете до това да дефинирате проблема и оставете екипът да търси отговора – така решението може да се окаже по-иновативно и ефективно от всичко, правено досега.

В същото време обаче, не бива да оставяте вашия продуктов списък твърде абстрактен и неконкретен. Виждала съм това да се случва, когато се използват потребителски истории (user stories) като инструмент. Те наистина предполагат кратка формулировка и много допълнителна комуникация междy PO и екипа, но много важен и често забравян елемент от тях е дефиницията за завършеност (или acceptance criteria/test). Чрез дефинирането на тестовете, с които искате да проверите дали продуктът се държи според изискванията, вие всъщност дефинирате какъв резултат очаквате за дадената история и давате на екипа насоките на проблема, който те трябва да решат.

По отношение на екипа, факторите, които също определят необходимостта от по-детайлно описание, е зрелостта на екипа (времето, което членовете му са работили заедно като екип) и степента на сработеност с PO. Когато работите с по-млади или непознати за вас екипи, е добра идея да вложите повече детайли в описанието на продуктовия списък, докато намерите оптималния вариант за комуникация и уточняване на изискванията.

В: Как PO приоритизира?

О: Приоритизирането започва още при началното дефиниране на продуктовия списък. След определянето на елементите и преди началната им оценка с екипа, е добре да разделите изискванията в следните групи:

1. Елементи, без които продуктът не може (must-haves)
2. Елементи, които продуктът би трябвало да има (should-haves)
3. Елементи, които продуктът е добре да има и биха се превърнали в негово предимство на пазара (nice-to-haves или exciter features, както ги нарича Майк Коон)
4. Елементи, които са интересни, но не и важни (за текущата версия на продукта) и могат да изчакат

Ясно е, че на първо място екипът ще се фокусира върху първите 3 групи в този ред. С това вие вече сте определили приоритетите на най-общо ниво. Следващата стъпка е оценката от екипа. Когато вече знаете колко би струвало да се направи всеки един от елементите, бихте могли да махнете някои от нещата във групите на should- и nice-to-haves, ако те са прекалено скъпи и не донасят голяма допълнителна стойност на продукта. Ако се налага, може да зададете и по-детайлни приоритети вътре в самите групи (обикновено е наложително за should- и nice-to-have, но понякога и за задължителните функционалности – например, ако планирате да издадете алфа- или бета-версия на продукта и искате тя да съдържа определени функционалности). Интересен инструмент, който може да ви помогне в това упражнение, можете да намерите на http://www.mountaingoatsoftware.com/tools/relative-weighting.

В: Какво да прави PO, ако няколко неща са спешни?

О: В зависимост от проекта и мащабите му имате различни варианти за реакция. Ако работите с няколко екипа, бихте могли да вложите целия им капацитет, като включите всички високоприоритетни елементи в списъците на екипите за спринта. Ако нямате такава опция, можете да се опитате да предефинирате тези изисквания, така че те да обхващат по-малко функционалност (например, ако цялото изискване е възможност да се съхраняват и променят лични данни, бихте могли на първо време да ограничите изискването до това те да могат да се запазват, а като втора стъпка – да се променят). Така ще можете да покажете работещ продуктов инкремент и да получите обратна връзка от клиентите в края на итерацията, въпреки че цялостната визия все още не е осъществена.

Ако нито едно от по-горните неща не са възможни, алтернативата е да поговорите с клиентите си и да обсъдите приоритетите отново. Разкажете им какви са плановете и защо не достига капацитета на екипа, покажете им защо функционалностите, които планирате, ще са им полезни.

В: Как PO да изисква високо качество от екипа?

О: В Scrum осигуряването на високо качество на продукта е приоритет на екипа. Въпреки това, PO би могъл да помогне на екипа да постигне добро качество чрез дефинирането на добри функционални тестове (по-горе стана дума за т.нар. acceptance tests). Освен това той/тя трябва да бъде на разположение на екипа за въпроси, демота и обратна връзка по време на целия спринт, за да не се налага преработка впоследствие.

В: Какво да прави PO, ако нещо не се свърши навреме?

О: Понякога това, което все още трябва да се направи, не носи много допълнителна стойност за продукта – например,  да се премести елемент от ляво или от дясно на уеб страничката или да се смени текста на бутон от приложението. По ваша преценка, такъв елемент би могъл да бъде приет за завършен. Когато обаче не са довършени по-критични за продукта неща и особено такива, които са отразени в критериите за завършеност, елементът трябва да бъде върнат в списъка с изисквания, да бъде приоритизиран и планиран за следващия спринт. Всяко забавяне трябва да бъде комуникирано и с клиентите и другите заинтересовани лица, тъй като би могло да има отражение и върху техния график.

В: Как PO може да помогне на екипа?

О: PO трябва да помогне на екипа да разберат в детайли какво се изисква от тях, за да могат да предоставят добро решение. За да постигне това, PO трябва да разполага с достатъчно време за екипа, така че участниците в него да могат да го открият за дискусия или предварително демо.  Освен това, като PO вие бихте могли да отделяте от времето за проверка на вече завършените елементи и да предоствяте бърза обратна връзка на екипа, така че те да могат да го имплементират в рамките на същата итерация.