Kim jest Proxy Product Owner?

Rola Product Owner’a związana jest bezpośrednio ze Scrumem. Jak sama nazwa wskazuje, jest on “właścicielem produktu”. Jednak często w firmach typu Software House rola ta występuje, a “książkowo” nie ma sensu! Bo Product Owner jest właścicielem produktu (jak sama nazwa wskazuje), a pracując u podwykonawcy wpływu na produkt nie mamy. Jesteśmy wtedy proxy Product Ownerami. 

Ale może jednak od początku.

Kim więc jest Product Owner?

• jest jedyną osobą uprawnioną i odpowiedzialną za zarządzanie backlogiem produktu,
• jest odpowiedzialny za tworzenie wizji produktu,
• priorytetyzuje prace nad produktem,
• jest właścicielem budżetu.

Jak mówi Scrum Guide, Product Owner może przekazać część swoich obowiązków i odpowiedzialności innym osobom. Nadal jednak pozostanie odpowiedzialny za ostateczne wyniki. 

W klasycznym software house wewnętrznie rola Product Ownera nie będzie występowała. PO będzie zawsze po stronie klienta (nawet jeżeli nie zdaje sobie z tego sprawy). Przecież budżetem zawsze będzie zarządzał klient. Priorytetami często też. 

Taką rolę, w książkowym ujęciu, pełnić możesz w firmie produktowej (czyli takiej, która posiada i rozwija swój własny produkt) lub, jak już wspomniałam, po stronie klienta. 

Kim więc jest osoba, której oddelegowana zostaje znaczna część zadań i odpowiedzialności Product Ownera?

Często taka rola nazywana jest Proxy-Product Owner, a więc “pośrednik”.  

Może on brać na siebie:

• zarządzanie backlogiem,
• przekazywanie i realizowanie wizji produktu,
• asystowanie w priorytetyzacji, bazując na doświadczeniu swoim i zespołu, metrykach zaimplementowanych w produkcie, itp. ,
• zarządzanie komunikacją między PO, a zespołem .

Tak więc, w praktyce, będzie odpowiedzialny za: 

• zbieranie wymagań, opisywanie ich w narzędziu, jakiego używa zespół i potwierdzanie ich z biznesem,
• komunikację, refinement i estymację zadań z zespołem,
• facylitację komunikacji w przypadku niejasności i pytań,
• analizę możliwych rozwiązań pojawiających się problemów. 

Na czym warto się skupić, jeżeli pracujesz jako proxy Product Owner? 

Tworzenie standardów – np. dla opisu user stories i bugów (jeżeli nie masz na tyle doświadczonego testera w zespole). Zadbanie o uwspólnienie standardów dla wszystkich może być wyzwaniem, ale w długim okresie owocuje niezwykłymi rezultatami.

Tworzenie procesów – brzmi niesamowicie nudno i “korpo”, ale warto się nad tym również pochylić. Rezultaty są podobne jak przy tworzeniu standardów, ale na szerszą skalę i zazwyczaj potrzebują jeszcze więcej czasu. Zmiana / wprowadzanie nowych procesów wymaga zmiany sposobu działania wielu osób, nie może być więc to łatwe do zrobienia 😉 

Checklisty – pomogą Ci we wprowadzaniu jednego i drugiego. Pozwolą Ci również pamiętać o wszystkich Twoich drobnych zadaniach, które na siebie bierzesz. 

Zadbaj o obie strony. Zespół ma mieć niezbędne informacje potrzebne mu do pracy, a klient ma być na bieżąco informowany o postępie prac.

Zadbaj o komunikację w obie strony – zarówno do klienta, jak i do zespołu. Szczególnie tę niewygodną – problemy zawsze wyjdą na jaw, prędzej czy później.Dobrze, żebyś w takich okolicznościach zachowywał się odpowiedzialnie. 

Nie bądź generatorem problemów – bądź generatorem rozwiązań – gdy pojawia się problem, od razu siądź do opracowywania możliwych sposobów rozwiązania wraz z rekomendacją dla jednego z nich. Pamiętaj, że nie musisz robić tego samodzielnie! Praca zespołowa przy rozwiązywaniu problemów jest konieczna.

Rola proxy-PO nie jest łatwa, ale występująca często, zwłaszcza w software house. Odpowiedzialność jest duża, a władzy jest niewiele 🙂  Przy dobrej relacji z klientem pozwala jednak rozwinąć skrzydła. Pokazując klientowi uporządkowany system, zorganizowanie i procesy decyzyjne oparte na danych, możesz zyskać jego zaufanie i dużo swobody. 

Na koniec chciałam Ci polecić dodatkową lekturę 🙂 Wpis Hani Wesołowskiej z AnalizaIT.pl “Nie proś więcej o podwyżkę”. Nawet jeżeli bezpośrednio się jeszcze do Ciebie nie odnosi, da Ci pogląd na to, jak myśli Twój pracodawca.