.st0{fill:#FFFFFF;}

Trzy cechy naprawdę dobrego PO 

 14 lipca, 2020

Łukasz Bręk

Większość z nas ma skłonności do skupiania się na negatywach i szukaniu problemów. Dziś jednak będzie optymistycznie. Przyszedł czas na 3 najważniejsze cechy naprawdę dobrego PO.

 

Kim jest dobry PO?

Półtora roku temu Tomek popełnił tekst o 3 grzechach Product Ownera. Czas mija naprawdę szybko. Zgodnie z zapowiedzią dziś zastanowimy się, co czyni z Product Ownera naprawdę wartościowego pracownika.

Product Owner to umocowana w organizacji osoba. Właśnie ta, która ma możliwość decydowania o priorytetach elementów listy wymagań. Nie dziwi więc fakt, że każdy chciałby mieć w organizacji jak najlepszą osobę na tym stanowisku, choć jej zatrudnienie nie jest wcale takie proste. PO to osoba, która powinna świetnie znać firmę, biznes, produkt, mieć wizję… Sporo tego.

I to między innymi decyduje o tym, że znaleźć właściwą osobę na „wolnym rynku” rynku jest bardzo trudno. Firmy często ryzykują, zatrudniają nowe osoby ale wiadomo, że będzie się to wiązało z koniecznością ich wdrożenia się w organizację i zdobycia przez nich odpowiedniej pozycji. A to chwilę potrwa.

Skoro więc sytuacja sytuacja wygląda jak opisana powyżej, zastanówmy się nad promocją „umocowanego” z organizacji. Postanowiliśmy troszkę Wam pomóc wskazując na 3 podstawowe cechy naprawdę dobrego PO. Sprawdźcie też nasz film „Gdzie jest Product Owner i jak go znaleźć?

 

Wszechobecny

Wszechobecność to ta cecha dobrego PO, która będzie najtrudniejsza do zapewnienia. Istnieje tyle spotkań, wydarzeń i potrzeb, że jeden Product Owner absolutnie sobie z nimi wszystkimi nie poradzi. A ma być dokładnie JEDEN! PO to nie komitet!

Natomiast pisząc „o tych wszystkich spotkaniach” mam także na myśli Product Backlog Refinement, na którym powinien wspierać zespół w doskonaleniu naszego backlogu. Poza tym mamy tradycyjnie – Planowanie Sprintu, na którym powinien powinien wesprzeć zespół, gdy ten będzie potrzebować wyjaśnień, Sprint Review, gdzie powinien omówić wyniki zakończonej własne iteracji oraz oczywiście Sprint Retrospective, gdzie występuje jako członek Scrum Team.

A to przecież tylko wydarzeniach, które składają się na jedną metodykę. Co w przypadku gdy wykorzystujemy w naszej pracy jakieś rozwiązania skalowane? Gdzie miejsce na System Demo albo na PI Planning z pewnego dobrze znanego podejścia? A gdzie pozostałe spotkania, te zwyczajowo odbywające się w naszej organizacji?

Konieczność uczestnictwa w tych i wielu więcej wydarzeniach powoduje, że wszechobecność staje się kluczowa. Product Owner jest w centrum wydarzeń. Jest to jeden z powodów, dla których nie powinniśmy przesadnie oddzielać Zespołu Deweloperskiego od biznesu. Jeśli dopuścimy do tego, a PO będzie zajęty na spotkaniu, nie będziemy mieli możliwości dowiedzieć się czegokolwiek.

 

Zorientowany na produkt

Skoro Product Owner uczestniczy już w tych wszystkich wydarzeniach robi to po coś. Przyczyną najczęściej jest silne zorientowanie na produkt, który rozwija. Nie ma w tym nic niezwykłego, w końcu jest odpowiedzialny za wyznaczenie kierunku prac dla zespołu odpowiedzialnego za pracę, za dostarczanie produktu wg wizji, którą przedstawia.

Zorientowanie na produkt to ciągła praca z interesariuszami, to ciągłe poszukiwanie nowych, innowacyjnych rozwiązań, które będą w stanie przyciągnąć do produktu klientów. To decydowanie o komercjalizacji rozwiązania czy jego pilotażu po to, aby uzyskać informację zwrotną i dopasować produkt do oczekiwań klientów.

Jednym z najważniejszych zadań Product Ownera związanych z orientacją na produkt jest priorytetyzacja elementów backlogu. W końcu to od kolejności zależy co w pierwszej kolejności zostanie wytworzone i jak budowane będzie rozwiązanie.

 

Proaktywność

PO nie może być sekretarką ani odtwórcą woli umocowanych klientów naszej organizacji. Ma być proaktywnym uczestnikiem procesu tworzenia produktu. Brak proaktywności to jasny sygnał dla członków zespołu, że nie możemy być pewni stabilności budowanego produktu. Nie chodzi tutaj o „bądźcie gotowi na zmiany” z 12 zasad zwinnego tworzenia oprogramowania. Sprawa jest znacznie bardziej poważna.

W czym ta proaktywność ma się objawiać? Przede wszystkim w proponowaniu nowych, innowacyjnych rozwiązań czy dopasowania rozwiązania do aktualnych warunków. Zmienił się budżet? Okazało się, że produkt ma być gotowy 3 miesiące wcześniej niż zakładaliśmy? Rolą aktywnego PO jest dopasowanie produktu do aktualnej sytuacji. Tego nie zrobi człowiek, który nie jest gotowy do podejmowania decyzji.

Osobną kategorią spraw, którymi będzie zajmował się Product Owner będzie dbanie o to, aby produkt spełniał pragmatyczną definicję MVP. Myślicie, że bez proaktywnej postawy uda się to zrobić?

 

Product Owner jako must have

Nie chodzi mi o „must have” znany z MoSCoW. Chodzi mi o fakt, że Product Owner, dobry Product Owner to absolutna podstawa zwinnego podejścia. Przeczytałem kiedyś mądre słowa:

“There is only one boss. The customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else.”

Skoro klient jest tym jedynym szefem, to czy możemy pozwolić sobie na to, aby dostarczać produkty niedopasowane do jego oczekiwań? Czy możemy pozwolić sobie, aby produkty tworzone były bez udziału PO? Czy możemy pozwolić sobie na człowieka, który nie jest zorientowany na nasz produkt, a stanowisko PO jest kolejnym szczeblem jego kariery?

Każdy z nas zna odpowiedź na powyższe pytania. Nie, nie, nie. Dlatego zastanówmy się i sprawdźmy, czy nasi PO spełniają powyższe cechy. Jeśli nie – drogi Scrum Masterze, czas działać.

Łukasz Bręk


Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

    1. Niestety, na tak ogólne pytanie możemy odpowiedzieć jedynie „to zależy”. Z naszego doświadczenia, Product Owner przeważnie jest albo na spotkaniach (z interesariuszami, z klientem, z zespołem), wydarzeniach (scrumowych) albo pracuje nad Product Backlogiem (samodzielnie bądź z zespołem na refinementach). Proporcje tych aspektów mocno zależą od wielkości organizacji, liczby zespołów, stopnia zaawansowania projektu itd. Na pewno PO powinien być dostępny dla zespołu i nie powodować opóźnień zarówno w pracy bieżącej, jak i w refinementach.

      Dlaczego pytasz? Być może będziemy w stanie lepiej odpowiedzieć, jak poznamy cel zapytania…

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}