with 5 komentarzy

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.

 

Spodobało się? Podziel się!

5 Odpowiedzi

  1. Wojtek
    | Odpowiedz

    Hmmm, a czy Proxy PO nie jest rola tradycyjnego analityka biznesowo-systemowego (inżyniera wymagań)? W gruncie rzeczy zakres obowiązków prawie ten sam może z wyjątkiem rozszerzenia w postaci zarządzania backlogiem.

    • Natalia Cholewa
      | Odpowiedz

      To jest dobre pytanie – pewnie w wielu przypadkach tak. Często różnice między PO, proxy-PO, analitykiem biznesowym, analitykiem biznesowo-systemowym i inżynierem wymagań się mocno zacierają, bo wszystko zależy od definicji przyjętej w danej firmie. Albo w projekcie, bo nawet na poziomie firmy mogą być różne 🙂

  2. […] tak naprawdę pełnią rolę Proxy Product Ownera (więcej o tej roli możesz przeczytać we wpisie “Kim jest Proxy Product Owner?”) i nie mają nawet dostępu do wszystkich interesariuszy. Jednak zawsze zajmują się one […]

  3. […] tak naprawdę pełnią funkcję Proxy Product Ownera (więcej o tej roli  przeczytasz we wpisie „Kim jest Proxy Product Owner?”) i nie mają nawet dostępu do wszystkich interesariuszy. Jednak zawsze zajmują się one […]

  4. […] Kim jest Proxy Product Owner? […]

Zostaw Komentarz