Product Owner. Zakres obowiązków na stanowisku Właściciela Produktu

Rola jaką pełni Product Owner (w skrócie PO)

Product Owner (PO) – inaczej Właściciel Produktu – jest częscią zespołu Agile, który odpowiada za definiowanie zakresu i ustalanie priorytetów w ramach Backlogu Zespołu. Celem jest usprawnienie procesu realizacji priorytetów przy jednoczesnym zachowaniu integralności koncepcyjnej i technicznej dla całego zespołu.

Product Owner wchodzi w buty kilku ról – min. stratega biznesowego, projektanta produktu, analityka, łącznika z interesariuszami i kierownika projektu. Krótko mówiąc, Product Ownerzy są integralną częścią każdego zespołu scrumowego.

5 głównych obszarów odpowiedzialności Product Ownera

1. Nakreślanie wizji

Product Owner jest głównym ogniwem zespołu produktowego, wykorzystując swoją szeroką wiedzę, perspektywę i zrozumienie kontekstu, tak by móc definiować cele i i nakreślać wizję rozwoju produktu.

Właściciele produktów są odpowiedzialni za sprawne i jasne komunikowanie się z wszystkimi interesariuszami – członkami zarządu, menedżerami biznesowymi i zespołem programistycznym, w sposób ciągły upewniajć się, co do spójności postrzegania celów i wizji zgodnej z celami biznesowymi firmy. Posiadanie właściciela z odpowiednią perspektywą, sprawia że ​​zespół realizuje spójną wizję pomimo elastycznego i często szybkiego charakteru samego procesu rozwoju produktu.

Właściciel produktu może pomóc zespołowi utrwalić tę wizję, tworząc roadmapę. Roadmapa rozwoju produktu to strategiczne, raczej na grubych elementach, przedstawienie kierunku rozwoju produktu w czasie. Jest to zarówno strategiczny przewodnik dla interesariuszy, do którego mogą się w dowolnej chwili odnieść, jak i plan działania dla zespołu.

2. Priorytetyzacja potrzeb poprzez zarządzanie backlogiem zadań

Inną kluczową rolą właściciela produktu jest ustalanie priorytetów potrzeb. Innymi słowy, muszą łączyć zakres – budżet i czynnik czasu, ważąc priorytety zgodnie z potrzebami i celami interesariuszy. Jednym z najważniejszych obowiązków Produuct Ownera jest zarządzanie backlogiem. Jest to lista zadań do realizacji przez zespół deweloperski produktu.

Odpowiedzialnością właściciela produktu jest stworzenie listy zaległych tematów i nadanie im priorytetów w oparciu o ogólną strategię i cele biznesowe. Ponadto Product Owner będzie musiał zmapować wszelkie zależności projektu, aby dostarczać informacji o niezbędnej sekwencji rozwoju. Lista zadań do wykonania nie jest jednak statyczną listą. Jest to dokument który „żyje”, który powinien być stale aktualizowany w oparciu o zmieniające się potrzeby projektu.

Ponieważ rejestr produktu ulega często zmianie, właściciel produktu musi udostępnić listę wszystkim zainteresowanym stronom (w szczególności deweloperom), aby zapewnić optymalną wydajność i wyniki.

3. Nadzorowanie etapów rozwoju

Mając wykrystalizowaną wizję, strategię i priorytety rozwoju produktu, Product Owner powinien poświęcić znaczną ilość czasu na faktyczne nadzorowanie rozwoju produktu. Jest kluczowym ogniwem podczas każdego etapu prac, w tym planowania, udoskonalania, przeglądu i sprintu.

Na etapach planowania Product Owner współpracuje z interesariuszami w celu zidentyfikowania i zorganizowania kroków wymaganych do następnej iteracji. Następnie spotkają się ze swoim zespołem, aby udoskonalić proces, zidentyfikować obszary wymagające poprawy i wesprzeć sprint.

4. Przewidywanie potrzeb interesariuszy

Product Owner, odnoszący sukcesy, będzie ekspertem w zrozumieniu i przewidywaniu potrzeb wszystkich interesariuszy produktu. Jego znajomość rynku i dobre umiejętności komunikacyjne pozwalają przewidywać potencjalne problemy lub potrzeby i na bieżąco reagować na nie.

5. Ocena postepu w każdej iteracji

Właściciel produktu jest odpowiedzialny za każdy etap procesu rozwoju i za produkt końcowy. Odgrywa główną rolę w kontroli i ocenie postępu rozwoju produktu w każdej iteracji. Product Owner dokonuje oceny wyników, decydując, czy zespół musi wrócić do dalszych usprawnień, czy też może przejść do kolejnych kroków.

4 etapy rozwoju produktu

Możemy rozróżnić 4 różne etapy pracy Product Ownera w zależności od dojrzałości produktu i etapu na którym się obecnie znajduje.

1. Feature Work – tworzenie i ciągłę walidowanie produktu poprzez rozbudowywanie go o nowe ficzery, funkcjonalności, które powinny się przełożyć na incrementalne wzrosty
2. Growth Work – tworzenie wartości poprzez znaczącenie zwiększenie używalności produktu wśród klientów na istniejącym już rynku
3. Scaling Work – Skupienie na zidentyfikowaniu wszystkich tzw boootleneck’ach czyli miejsach które blokują skalowanie produktu oraz zapewnienie tak pracy zespołu aby mógł rozwijać produkt na ficzerach, wzroście oraz ekspansji
4. Product-Market Fit Expanstion – zwiększanie istotnie zasięgu produktu, poprzez espansje na nowy market, lub zmianę sposobu używania produktu lub dwie rzeczy na raz.

Zobacz także: 20+ pytań rekrutacyjnych na stanowisko Product Owner

Dobre i złe praktyki sprintów

Bardzo istotnym elementem tworzeniu produktów są sprinty. Sprinty ułatwiają zarządzanie projektami, pozwalają zespołom dostarczać wysokiej jakości prace szybciej i częściej, a także dają im większą elastyczność w dostosowywaniu się do zmian.

Dobre praktyki

• Upewnij się, że zespół ustala i rozumie cel sprintu. Ustala sposób pomiaru sukcesu. To jest klucz do utrzymania wszystkich w zaangażowaniu i spójności w dążeniu do solidarnego celu
• Upewnij się, że zadbałeś o backlog (zaległości), uporządkowany według priorytetów i zależności. Może to być duże wyzwanie, które może zakłócić cały proces, jeśli nie jest to odpowiednio zarządzane
• Upewnij się, że dobrze rozumiesz czynnik czasu, że powinien uwzględniać takie rzeczy, jak urlopy i spotkania zespołowe
• Skorzystaj ze spotkania poświęconego planowaniu sprintu, aby doprecyzować najmniejsze mankamenty i szczegóły prac, które należy wykonać
• Wreszcie, po podjęciu decyzji co do rozwoju, upewnij się, że ktoś podejmie rękawice i zorganizuje administrację tych zmian w odpowiednim systemie ticketowania prac np. Jira

Złe praktyki

• Nie rysuj zbyt szerokiego kontekstu, nie przeceniaj możliwosci zespołu programistycznego, ani nie wciągaj na listę zadań, których nie można ukończyć w danym sprincie. Nie pozwól narażać członków zespołu na dostąpienie „zaszczytu” porażki
• Nie zapomnij o długu technologicznym. Upewnij się, że przeznaczysz czas na kontrolę jakości i prace niezwiązane z funkcjami, takie jak błędy i stan techniczny
• Nie pozwól zespołowi mieć rozmytego obrazu tego, co jest w trakcie sprintu. Dopilnuj tego. Szybkość i zwinność ale nie ponad jakością
• Nie podejmuj się też dużej ilości nieznanych lub ryzykownych tematów. Dziel zakres, tak by realizować choćby częsciowo dany obszar potrzebnych zmian
• Nie ignoruj sygnałów płynących z zespołu, że np. termin realizacji lub zakres w całości jest zagrożony ze względu na jedno czy drugie. Słucha, rozmawiaj. Rozwiąż ten problem i ponownie skalibruj prace na miarę waszych możliwości