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.
