3 Grzechy Product Ownera 

Jaki Product Owner jest, każdy widzi. Czasami PO jednak zapomina o swoim zakresie odpowiedzialności i zmienia się w pośrednika pomiędzy zespołami, a klientem. Brakuje wizji, wartości, a czasami nawet dostępności. Tak nie powinno być, dlatego dziś – 3 Grzechy Product Ownera.

Product Owner bez wizji

Zacznijmy od celu, w zależności od stopnia dookreślenia zwanego czasami misją bądź wizją. Product Owner nie jest tylko kimś, kto przekazuje nam cele klienta. We współpracy z interesariuszami tworzy on cele, misję bądź nawet wizję dla naszych zespołów. Praca, którą wykonujemy musi być ukierunkowana na coś, bo inaczej działamy chaotycznie albo wręcz kręcimy się w kółko.

Dlatego tak ważne jest nie tylko tworzenie Celu Sprintu, ale przede wszystkim posiadanie wizji przez PO. Inaczej będzie on przynosił do nas tylko zadania, a nie wymagania. A to przecież problemy do rozwiązania pozwalają uwolnić naszą kreatywność. Zespoły mogą rozwiązać je w taki sposób, który dostarczy jak największej wartości do naszego klienta. Tego nie uzyskamy po prostu „klepiąc kod”.

Żebyśmy mogli „ukierunkować się na klienta”, musimy wiedzieć do czego on dąży. Ułatwić to nam powinien PO, przynosząc dla nas cele i wizję naszego produktu. Ta z kolei budowana będzie iteracyjnie, przez coraz większe Przyrosty.

„Product Backlog management includes (…) ordering the items in the Product Backlog to best achieve goals and missions” – Scrum Guide

Nie wystarczy ułożenie Product Backlogu w odpowiedniej kolejności. To nie jest wizja! Prace nadal będą toczyły się nad poszczególnymi elementami, a nie nad spójnym rozwiązaniem. Musimy wiedzieć na co to wszystko się składa, co chcemy osiągnąć i jaką wartość dostarczyć.

PO z wartością na bakier

W naszej krótkiej serii na YouTube dyskutowaliśmy o tym, czym dla kogo jest sukces oraz jak zdefiniować wartość. Powiedzieliśmy sobie, że wartość nie oznacza tylko i wyłącznie pieniędzy, a raczej przybliżenie naszego odbiorcy (klienta) do spełnienia postanowionych sobie celów. Brzmi to pokrętnie, więc prostszymi słowami: zadaniem PO jest takie ułożenie backlogu, aby uśmiech na twarzy naszego klienta pojawiał się a) jak najszybciej b) jak najczęściej. Do tego potrzebujemy mieć tę wartość zdefiniowaną i zapisaną, np. jako Value Points.

„The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” – Scrum Guide

W tym momencie warto też przypomnieć o tym, jaki jest cel samej zwinności. A ten, jak dobrze wiemy, to „zadowolenie klienta osiągane dzięki szybkiemu i częstemu wdrażaniu wartościowego oprogramowania”. Znów więc pojawia nam się wartość oraz zorientowanie na klienta. Nie zajmujemy się produkcją wodotrysków, ale czegoś, co faktycznie przez naszego odbiorcę musi być używane.

Dlatego tak bardzo potrzebny jest nam PO, który umie wczuć się w klienta oraz zidentyfikować, co z jego punktu widzenia będzie najbardziej wartościowe. Szczególnie w przypadku, kiedy to klient się myli i możemy zaproponować mu lepsze rozwiązanie. W takiej sytuacji powinien tak potrafić poprowadzić rozmowę z klientem, aby to on wpadł na ten lepszy pomysł.

Wszystko w imię wartości i zadowolenia klienta.

Niedostępny Product Owner

Chyba najczęstszym problemem, jaki Zespoły Deweloperskie mają z Product Ownerem jest jego dostępność. Ponieważ jest on niejako przedstawicielem klienta w naszej organizacji, to trudno oczekiwać, żeby mógł tę rolę pełnić bez częstych spotkań i życia blisko odbiorcy naszych prac. To powoduje, że bardzo często PO brakuje. I to do tego stopnia, że zespoły zaczynają na to narzekać.

Czasami problem ten wynika z poczucia odpowiedzialności PO, który chce wszystko zrobić samodzielnie i w zgodzie ze Scrum. Przecież to on jest odpowiedzialny m.in. za Product Backlog. „Odpowiedzialny” nie znaczy jednak „musi wszystko robić sam”. Przecież spotkania typu Product Backlog Refinement nie służą „odpytywaniu” Product Ownera, ale wspólnej pracy nad backlogiem. To z kolei znaczy, że jesteśmy w stanie sobie wyobrazić, że to profesjonaliści z zespołu np. tworzą User Stories i dodają szczegóły do backlogu.

„The Product Owner is the sole person responsible for managing the Product Backlog. (…) The Product Owner may do the (…) work, or have the Development Team do it. However, the Product Owner remains accountable.” – Scrum Guide

Oczywiście powinno się to dziać za wiedzą i zgodą Product Ownera. To w końcu on jest odpowiedzialny, więc cokolwiek zrobi cudzymi rękami, to i tak będzie na niego (bądź na nią). Nie ma też co przesadzać w drugą stronę, bo pojawi się nam wtedy PO, który w ogóle nie interesuje się tym, za co odpowiada. Jak zwykle trzeba znaleźć złoty środek.

Zdarza się też i tak, że Product Owner jest niedostępny, bo po prostu ma za dużo pracy. Szczególnie dobrze widać to w sytuacjach w których na jednym backlogu pracuje kilka bądź kilkanaście zespołów. Scrum wyraźnie mówi: jeden backlog – jeden PO. Jak jednak ma on być dostępny dla wszystkich zespołów?

Na ten problem mamy sprawdzony przepis i przekażemy Wam go na naszym blogu już za tydzień.

Jak być dobrym Product Ownerem? Jak odnaleźć się w tej roli i „maksymalizować wartość wytwarzanego produktu”? Zapraszamy na nasze szkolenia: Scrum dla Product Ownerów oraz Wymagania w projektach agile.