Typy Product Ownerów 

Miałem na dzisiejszy wpis dwa dobre pomysły. Nie mogąc się zdecydować rzuciłem monetą i wgrał ten opisujący „typy” Product Ownerów. Dlaczego napisałem o typach? Sprawa z punktu widzenia frameworku Scrum jest prosta, sprawa z punktu widzenia praktyki nieco się komplikuje. Można powiedzieć, że komplikujemy ją sobie sami.

Ilu właściwie jest tych Product Ownerów?

Z punktu widzenia metodyki Scrum powinien być dokładnie jeden Product Owner zarządzający jednym Produktem, który „opakowany” został jednym Product Backlogiem. Dlaczego więc, skoro z punktu widzenia Scrum sprawa jest oczywista, w wielu miejscach funkcjonuje to inaczej? Do najważniejszych przyczyn należą na pewno potrzeba komplikowania życia oraz potrzeba zapewnienia odpowiednio wysokiego stanowiska dla wszystkich zainteresowanych.

Kontrowersyjnie? Nie do końca – w wielu miejscach tak właśnie jest. Dopóki Product Owner jest Właścicielem Produktu, nie ma z tym problemu. Ten rozpoczyna się, kiedy mówimy o PO wyłącznie z nazwy. Wtedy mamy pewność, że dzieje się coś niedobrego i powinniśmy zainterweniować. Dlaczego dochodzi w ogóle do sytuacji, w której mamy PO wyłącznie na papierku? Czy zasadne jest, aby jednym Backlogiem zarządzała więcej niż jedna osoba?

Typy Product Ownerów

Na początku warto wspomnieć, że co organizacja to obyczaj. W jednych będzie to Business Product Owner w innych Technical Product Owner, a jeszcze gdzie indziej Area Product Owner albo Proxy Product Owner. Nie ma znaczenia jak rola ta się nazywa, ważne, że występuje obok Product Ownera i… no właśnie, uzupełnia go, wspiera, czasem przeszkadza lub uniemożliwia mu pracę. Duża rozpiętość? Dlatego napisałem powyżej o potrzebie komplikowania życia!

Nie da się pominąć faktu, że istnienie tych ról związane jest z jakąś „potrzebą„. O tych kontrowersyjnych było powyżej, zastanówmy się więc nad merytorycznym sensem istnienia ról innych niż Product Owner na tym samym (lub podobnym poziomie). Jak potrzeba stała za ich utworzeniem? Czy są one na tyle ważne, aby zmieniać zasadę mówiącą o tym, że jeden Backlog może być zarządzany tylko przez jednego PO?

Jestem Business Product Ownerem bo…

Powodów na istnienie Business Product Ownera, jak to zwykle bywa, jest więcej niż 10. Najczęściej występujący to rozległy, duży czy skomplikowany Produkt i wynikające z tego wyzwania. Powołujemy w takim przypadku dodatkowe role, bo nie jesteśmy w stanie w pełni kontrolować budowanego Produktu. Szczególnie, gdy na Produkt ten pracuje 10 zespołów, w którym każdy z nich ma przecież Sprint Planning, Refinement i Sprint Review. Product Owner powinien być na każdym z tych wydarzeń (nie, nie zapomniałem o Sprint Retrospective) i wykonywać tam swoją pracę.

Innym powodem, który jest często wskazywany jako ten „najważniejszy” do wydzielenia tej roli to brak wiedzy merytorycznej, a co za tym często idzie decyzyjności, Product Ownera. Często używamy zwrotu „ekspert domendowy”. Tak, Product Owner powinien być ekspertem w dziedzinie, w której zarządza Backlogiem. Inaczej jest on tylko i wyłącznie osobą, która obsługuje rejestr wymagań na polecenie… np. Business Product Ownera. Ciekawe prawda? Swoją drogą, ciekawa to konstrukcja, w której jedna osoba decyduje a druga (ta na pierwszej linii rozwoju Produktu) firmuje wszystko swoją twarzą, imieniem i nazwiskiem. Odpowiedzialność bez decyzyjności? Kiepski pomysł.

Trzecim, na który zawsze zwrócę uwagę, to konieczność kontrolowania wszystkiego co się dzieje. Kiedy mówimy o więcej niż 1-2 zespołach kontrola ta jest najzwyczajniej niemożliwa, potrzebujemy (albo wydaje nam się, że potrzebujemy) kogoś, kto „tylko” nam w tym pomoże, ale nie będzie się „mieszał” w kompetencje prawdziwego Product Ownera.

Symbioza

Pytacie często, czy fakt istnienia dwóch ról jest problematyczny? Czy może zachodzić między nimi symbioza? Odpowiedź muszę podzielić na dwie części. Jedna dotyczyć będzie zgodności z metodyką, druga natomiast praktycznego podejścia do tworzenia Produktu.

Z punktu widzenia metodyki (tu powołam się na Scrum) istnieje tylko jedna rola określana mianem Product Ownera. Nie ma dwóch PO, nie ma BPO i PO. Nie ma, bo być nie może, bo musi istnieć jedna osoba, która zarządza całością. Ta jedna osoba a decydować, ona w końcu ma też ponosić ich konsekwencje (pozytywne i negatywne). Tyle o teorii.

Praktyka pokazuje, że są ekosystemy, w których połączenie to może być efektywne, może działać. Jednak niezbędne do tego są jasne wyznaczenie granic odpowiedzialności i przestrzeganie ich obowiązywania. Nie ma jednego, najlepszego sposobu na ich wyznaczenie, jednak musi się to zadziać przy udziale wszystkich zainteresowanych stron. Można do tego wykorzystać chociażby macierz RACI (Responsible, Accountable, Consulted, Informed), która w doskonały sposób pozwoli na zaadresowanie często zbieżnych odpowiedzialności.

Czy widzieliśmy tak działające Organizacje? Tak. Czy było to efektywne? Często nie, ale jak zwykle wierzymy, że w Waszym przypadku jest / będzie inaczej. Maciej jakieś doświadczenia (pozytywne / negatywne) w tej materii? Podzielcie się nimi w komentarzu (pod tekstem lub w naszych social mediach).