Szukając oszczędności, sponsorzy projektów chętnie rezygnują z tzw. ról miękkich, jak Project Manager, Scrum Master czy Proxy Product Owner. Czasem próbują też łączyć ich funkcje (ostatnio poraził mnie pomysł wprowadzenia do zespołu „gatekeepera”, który miał tańczyć, śpiewać i pisać User Stories). To okropne pomysły, które w żadnym wypadku nie przyniosą oszczędności. Wręcz przeciwnie. Zwłaszcza pominięcie w zespole roli Proxy Product Ownera może być pierwszym krokiem do zamordowania Twojego projektu.
Product Owner i jego ograniczenia
Product Owner (Właściciel Produktu) to jedna z ról występujących w Scrumie. Scrum Guide definiuje go jako osobę ponoszącą odpowiedzialność za maksymalizowanie wartości produktu będącego efektem pracy Scrum Teamu. Ustala cel produktu, zarządza Product Backlogiem, nadając pracy zespołu kształt, kierunek i znaczenie. Z definicji Product Owner musi więc być przedstawicielem biznesu, co więcej – odpowiednio umocowanym w organizacji, uprawnionym do podejmowania wszelkich decyzji związanych z budowanym produktem.
Aby praca Product Ownera mogła przynosić pożądane efekty, jego decyzje muszą być respektowane
Scrum Guide
przez całą organizację.
A więc, przekładając to „na nasze”, właściwy Product Owner powinien:
- dobrze znać się na domenie danego produktu
- zajmować wysokie stanowisko w firmie
- znać się na Scrumie
- dobrze rozumieć specyfikę wytwarzania oprogramowania
- tworzyć zrozumiałe specyfikacje produktu i roadmapy
- dogadywać się z osobami „technicznymi”
- umieć budować produkty informatyczne
- być w pełni dyspozycyjny
- …i przystojny.
OK, przystojny czy piękna pewnie być nie musi. Nie zmienia to faktu, że trudno wyobrazić sobie osobę, która w praktyce będzie w stanie (czy to technicznie czy organizacyjnie) spełnić te wszystkie wymagania.
Kim jest Proxy Product Owner?
Z pomocą przychodzi tu Proxy Product Owner. Rola wprowadzona nie tyle przez twórców Scruma (próżno szukać jej w Przewodniku po Scrumie), co jego praktyków. Proxy Product Owner to posiadający odpowiednie umiejętności pośrednik pomiędzy faktycznym, umocowanym biznesowo Product Ownerem, a zespołem developerskim. Jest zawsze „pod ręką” – na co dzień pracuje ze Scrum Teamem, opracowując wymagania, przekazując developerom niezbędne informacje i podejmując bieżące decyzje w ramach strategii uzgodnionej z Product Ownerem.
Rola zgodna ze Scrumem
Do wszystkich tych, którzy myślą teraz: „Wolnego! Proxy Product Owner nie wynika ze Scruma, Product Owner musi być jeden!”. Cóż, to prawda, albo raczej półprawda. Scrum Guide mówi bowiem:
Product Owner może wykonywać powyższe zadania samodzielnie lub zlecać je innym osobom. Niemniej to Product Owner pozostaje za nie odpowiedzialny.
Scrum Guide
Według Scruma nic nie stoi więc na przeszkodzie aby Product Owner wspierał się rolami pomocniczymi. Mogą to być wszelkiej maści analitycy, eksperci domenowi, inżynierowie wymagań czy też właśnie Proxy Product Owner. Ważne jednak, aby to Product Owner pozostawał jednostką decyzyjną i ponoszącą całkowitą odpowiedzialność za kierunek rozwoju produktu.
Jak Proxy Product Owner pomoże mojemu projektowi?
Zaangażowanie w projekt | Product Ownerzy, będąc „ludźmi biznesu” i zajmując wysokie stanowiska w swoich organizacjach, mimo dobrych chęci, mają bardzo ograniczone możliwości czasowe pełnego zaangażowania się w projekt, stanowiąc jego wąskie gardło. Zespół developerski bardzo często wymaga natychmiastowej konsultacji bądź podjęcia decyzji blokującej toczące się prace. Czuwający przy zespole i skupiony wyłącznie na projekcie Proxy Product Owner wypełnia tę lukę. |
Zarządzanie backlogiem | Utrzymywanie Product Backlogu w odpowiednim, zrozumiałym dla wszystkich, kształcie wymaga odpowiedniej wiedzy i doświadczenia. Nie każdy wyznaczony przez organizację Product Owner potrafi poprowadzić dobry backlog refinement, obsłużyć JIRĘ, stworzyć kompletne Epiki i User Stories zgodne z zasadą INVEST i przyjętą Definition of Ready czy spriorytetyzować je metodą MOSCOW. Wszystkie te umiejętności posiada natomiast Proxy Product Owner, gdyż (w przeciwieństwie do Product Ownera) jest to po prostu jego zawód. |
Analiza wymagań | Mimo że w analizę wymagań w zespole scrumowym zaangażowani są wszyscy, jej lwia część w sposób naturalny ląduje na biurku Product Ownera. Jeśli nie jest w stanie jej sprostać, wówczas obciąża nią zespół (odciągając go od zadań developerskich). Proxy Product Owner bardzo często z wykształcenia jest analitykiem biznesowym, a więc inżynieria wymagań to jego chleb powszedni. |
Zarządzanie interesariuszami | Prawdziwą zmorą produktu (a zarazem zespołu developerskiego) są interesariusze – osoby (np. z różnych działów organizacji) generujące przeróżne wymagania bądź zainteresowane postępami prac. Ich obsługa zajmuje czas i odciąga członków projektu od ich właściwych zadań. Komunikację z interesariuszami Proxy Product Owner może w dużym stopniu wziąć na siebie, znacząco odciążając Właściciela Produktu oraz zespół developerski. |
Podejmowanie decyzji | Każdy, kto kiedykolwiek pracował w Scrumie, wie, że w czasie prac nad produktem zespół niemal codziennie dokonuje wyborów wpływających na jego końcowy kształt. Wiele z nich wymaga decyzji Właściciela Produktu – niestety często niedostępnego od ręki. Product Ownerowi może też brakować wiedzy do podejmowania świadomych decyzji np. w zakresie doboru technologii (czego mogą oczekiwać developerzy). Osadzony w zespole i wywodzący się ze świata IT Proxy Product Owner decyzyjność w tym zakresie może wziąć na siebie. |
Oszczędność czasu i pieniędzy
Według mojego doświadczenia, obecność Proxy Product Ownera w zespole znacznie poprawia jego efektywność. Skraca przestoje w pracy i przyspiesza ją, pozwalając Właścicielowi Produktu i developerom skupić się na ich najważniejszych zadaniach.
Osobiście dbam, aby w każdym zespole mojego portfolio był obecny Proxy Product Owner. Jestem bowiem przekonany, że jego obecność się opłaca. Nie oszczędzajmy na nim – to naprawdę niedobry kierunek. Pięciu developerów nie zrobi bowiem tego, co czterech, ale wspomaganych przez kompetentnego Proxy Product Ownera.
1 thought on “Proxy Product Owner w projekcie – fanaberia czy konieczność?”