checklista

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.

checklista

Kim jest Proxy Product Owner?

Jak pracować w trudnym projekcie?