Skip to content

Product Owner czy pełniący obowiązki?

Formując Zespół Scrumowy organizacje często stają przed pytaniem, kto powinien pełnić rolę Właściciela Produktu (Product Owner) w danym projekcie lub produkcie. I nierzadko napotykają problem próbując odpowiedzieć na to pytanie.

Dzieje się tak głównie z dwóch przyczyn:

  1. Problem z identyfikacją osoby odpowiedzialnej za produkt

    O ile zazwyczaj jest wiele osób chcących mieć wpływ na kształt produktu, mających dużo do powiedzenia (a nawet do zarzucenia), o tyle czasem ze świecą szukać osoby chcącej wziąć na siebie pełną odpowiedzialność za produkt.

  2. Błędne rozumienie roli Właściciela Produktu

    Rola Właściciela Produktu jest błędnie kojarzona tylko i wyłącznie z pisaniem historyjek użytkownika, określaniem kryteriów akceptacyjnych i spotkaniami z zespołem, żeby zagrać w planning pokera. Więc nawet jeśli znajdzie się osoba, która przyjmie na siebie pełną odpowiedzialność za produkt (np. menedżer produktu), to unika ona pełnienia tej roli, bo jest zbyt zajęta ważniejszymi sprawami związanymi z rozwojem produktu i uważa, że nie będzie czasu na obowiązki Właściciela Produktu.

W rezultacie rolę Właściciela Produktu powierza się np. analitykowi, który ma zbierać wymagania od tzw. „komitetu sterującego” i spisywać je w postaci historyjek lub też reprezentować rzeczywistego menedżera produktu przed zespołem.

Osobie takiej nie daje się wystarczających uprawnień, żeby efektywnie pełnić rolę Właściciela Produktu, ma ona bardzo ograniczoną decyzyjność i służy w zasadzie jako kurier między zespołem a osobami rzeczywiście odpowiedzialnymi za produkt. Zamiast prawdziwego Właściciela Produktu (PO) mamy więc pełniącego obowiązki — p.o. PO.

Jeden głos czy komitet?

  • Prawdziwy PO w Scrumie jest to jedna osoba, jeden silny głos. To zmotywowana osoba z wizją produktu, która, owszem, słucha innych, ale podejmuje ostateczne decyzje.
  • p.o. PO natomiast często jest tylko głosem „komitetu sterującego”, którego członkowie mają często sprzeczne wizje i interesy. Wypracowywanie za każdym razem kompromisów wymaga dużo czasu, a ostateczne decyzje będące próbą pogodzenia sprzecznych ze sobą interesów nierzadko bywają szkodliwe dla produktu i jego użytkowników.

Menedżer produktu czy proxy?

  • Prawdziwy PO jest menedżerem, który zarządza rozwojem produktu. Posiada on wizję, którą może skutecznie komunikować zespołowi dzięki bliskiemu z nim kontaktowi. Wyznacza cel i motywuje zespół do osiągnięcia tego celu.
  • p.o. PO jest jedynie „proxy” komunikacyjnym między menedżerem produktu a deweloperami, w dodatku często nieumyślnie wypaczającym przekazywane komunikaty (efekt głuchego telefonu).

Samodzielność czy przekazywanie decyzji?

  • Prawdziwy PO jest samodzielny i decyzyjny.
  • p.o. PO każdą ważniejszą decyzję musi konsultować z menedżerem produktu, co wydłuża czas oczekiwania przez zespół na odpowiedź. Nawet jeśli p.o. PO wywalczy sobie większą autonomię i będzie próbował samodzielnie podejmować decyzje np. w mniej krytycznych obszarach, to i tak często te decyzje mogą być później podważane i zmieniane przez menedżera produktu.

    Dodatkowo, jeśli nie ma wyznaczonej jednej odpowiedzialnej osoby za produkt w postaci menedżera produktu, a taki p.o. PO ma do czynienia z „komitetem sterującym”, to czas oczekiwania na decyzje wydłuża się jeszcze bardziej.

Zarządzanie czy utrzymywanie Backlogu Produktu?

  • Prawdziwy PO zarządza Backlogiem Produktu, tj. podejmuje decyzje, które mają swoje odzwierciedlenie w brzmieniu poszczególnych elementów backlogu (np. historyjek użytkownika) oraz w ich kolejności w backlogu.
  • p.o. PO jedynie utrzymuje Backlog Produktu, tj. aktualizuje dokument pod dyktando menedżera produktu.

Współpraca czy zlecanie?

  • Prawdziwy PO zdając sobie sprawę ze wszelkich ograniczeń i czynników ryzyka współpracuje blisko z zespołem i szuka wspólnie optymalnego sposobu na osiągnięcie celu.
  • p.o. PO natomiast będąc jedynie „proxy” i mając nikły wpływ na cokolwiek zazwyczaj tylko zleca i wymaga, bo motywuje go wywiązanie się z zobowiązań danych menedżerowi produktu lub komitetowi, a nie sukces produktu.

Tak więc taki p.o. PO problem rozwiązuje tylko z pozoru. Owszem, jest jedynym punktem kontaktu dla deweloperów, ale taki punkt kontaktu nie jest ani decyzyjny, ani samodzielny, nie komunikuje skutecznie wizji, nie wyznacza celów, nie zarządza rozwojem produktu, wydłuża ścieżkę komunikacyjną zamiast ją skracać, a postawiony między młotem (klient/menedżer produktu) a kowadłem (deweloperzy) chroni przede wszystkim siebie zamiast dbać o sukces produktu.

Cierpią na tym wszyscy: zespół, menedżer produktu czy klient, produkt, końcowi użytkownicy i w rezultacie cała organizacja. I oczywiście analityk, któremu powierzono tę niewdzięczną rolę.

Kto jest Właścicielem Produktu? Ale serio?

Rola Właściciela Produktu (Product Owner) w Scrumie nieprzypadkowo nazywa się tak, a nie inaczej. Pytanie nie powinno brzmieć: kto powinien pełnić rolę PO? lecz: kto jest prawdziwym PO, rzeczywistym właścicielem biznesowym produktu? Bo taka osoba na pewno w organizacji gdzieś jest, trzeba ją tylko poprawnie zidentyfikować, a następnie zadać sobie kolejne pytanie: co należy zrobić, żeby dana osoba mogła efektywnie uczestniczyć w Zespole Scrumowym?

Przeszkody, jakie najczęściej stoją na drodze, by rzeczywisty właściciel biznesowy mógł być PO w Zespole Scrumowym, to brak przygotowania i brak czasu.

Brak przygotowania

Menedżer produktu nigdy nie będzie gotowy do bycia PO, jeżeli nie zacznie działać w ten sposób. Udział w szkoleniu czy warsztatach ze Scruma może być dobrym początkiem, ale przede wszystkim liczy się nabywanie umiejętności w praktyce. Jest to także odpowiedzialność Scrum Mastera, żeby rzeczywistego PO poprawnie zidentyfikować, a następnie przygotować do pełnienia tej roli, wspierać go w pracy codziennej i nieustannie uczyć efektywnego wykorzystywania Scruma do zwinnego zarządzania rozwojem swojego produktu.

Brak czasu

„Ja nie mam czasu na pisanie historyjek, analizę wszystkich wymagań i określanie dokładnych kryteriów akceptacyjnych” — słyszę często od menedżerów produktów.

Może wcale nie muszą robić tego wszystkiego sami?

Przewodnik po Scrumie:

Właściciel Produktu jest jedyną osobą zarządzającą Rejestrem Produktu (Product Backlog). Pojęcie zarządzania Rejestrem Produktu mieści w sobie:

  • Jasne artykułowanie elementów Rejestru Produktu, [...]

Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny.

I dalej:

Jak Scrum Master wspiera Właściciela Produktu?

  • W uczeniu Zespołu Deweloperskiego sposobów konstruowania jasnych i zwięzłych zapisów elementów Rejestru Produktu, [...]

Tak więc sporą część pracy nad Backlogiem Produktu, takiej jak: formułowanie historyjek użytkownika, ich dekompozycja, określanie kryteriów akceptacyjnych itd., może przejąć na siebie z powodzeniem Zespół Deweloperski. Oczywiście w zgodzie z kierunkiem wytyczonym przez PO. Ważne, aby ten kierunek był skutecznie komunikowany przez Właściciela Produktu.

Na analityka w takim ujęciu należy spojrzeć nie jak na „proxy” między menedżerem produktu a deweloperami, a jak na jednego z deweloperów, pełnoprawnego członka Zespołu Deweloperskiego. Dołączając analityka do zespołu uzupełniamy kompetencje zespołu o analizę i skracamy ścieżkę komunikacyjną o jedno ogniwo ułatwiając kontakt zespołu z rzeczywistym Właścicielem Produktu.

Jak jest u Was? Czy w Waszym zespole macie do czynienia z prawdziwym PO czy z p.o. PO? Kto pełni tę rolę w Waszej organizacji?

Categories: Product Owner.

Comment Feed

8 Responses

  1. Wydaje mi się, że p.o. P.O. oprócz analityka, zdarza się być także Srum Masterowi czy Project Managerowi. Zastanawiam się gdzie najlepiej szukać PO? Albo inaczej – gdzie się go najczęśćiej znajduje? ;) W organizacjach chyba trudno doszukiwać się go w strukturze ogranizacyjnej? Kim więc on jest? Osobą, która wykonywała podobne projekty/produkty? Specjalistą od marketingu? Specjalistą od usability? Czy jest jakaś różnica między projektami wewnętrznymi i zewnętrznymi? Jak ta rola zmienia się w przypadku zewnętrznych, kiedy mamy klienta z wizją rozwiązania?

  2. Bogdan Baraszkiewicz18 czerwca 2012 @ 08:54

    Najlepiej, kiedy Product Ownerem jest klient, osoba odpowiedzialna za stronę biznesową produktu. W przypadku, kiedy rozwijamy w firmie swój własny produkt, zazwyczaj już istnieje w strukturze stanowisko menedżera produktu albo podobne i najlepiej, kiedy to właśnie ta osoba będzie pełniła rolę Product Ownera. Jeżeli takiej osoby nie ma, to jest to pierwszy problem organizacyjny do rozwiązania, jaki pokaże Scrum.W przypadku projektów realizowanych dla zewnętrznego klienta najlepiej, kiedy Product Ownerem będzie przedstawiciel firmy-klienta, odpowiednio umocowany w swojej organizacji, żeby móc samodzielnie podejmować decyzje.

  3. Zastanawiam się czy PO i generalnie całe towarzystwo "niedeveloperskie" powinno schodzić na niższy poziom abstrakcji niż sama wizja produktu. Zauważyłem, że często kończy się to sugestią nie do końca poprawnych rozwiązań dla biznesowych problemów. PS. zlikwiduj sobie KAPCZĘ przy dodawaniu komentarzy

  4. Bogdan Baraszkiewicz25 czerwca 2012 @ 10:14

    Paweł, dzięki za komentarz. Zgadzam się, że zbyt głębokie wnikanie w szczegóły przez PO często prowadzi do narzucania niekoniecznie najlepszych rozwiązań. Jednak sama wizja może czasem nie wystarczyć.Na kapczę niestety nic nie poradzę :( Posterous ją generuje nawet jak jestem zalogowany i komentuję na swoim własnym blogu. Może trzeba będzie zmigrować do WordPressa.

  5. Poza projektami zewnętrznymi, gdzie ważniejsze jest zapewnienie wsparcia procesów organizacji klienta przez przez IT (gdzie w rolę PO naturalnie wchodzi klient), mamy jeszcze wewnętrzne czy takie, gdzie ważniejszy jest sam produkt (jego projekt czy wizerunek). Wydaje mi się, że tam się świetnie sprawdza specjalista od użyteczności, który projektuje prototyp rozwiązania (nie wszędzie można znaleźć product managera).Są takie sytuacje, że mamy projekt zewnętrzny dla klienta i on jest w stanie przekazać pewne wymagania, oczekiwania, ale nadal wydaje mi się, że to może być za mało, by stworzyć dobry system. Narzucone są pewne ograniczenia, ale wciąż pozostaje mnóstwo możliwości realizacji. Klient i analityk mogą wymyślać rozwiązania, ale z jakim efektem? Świetnie byłoby mieć kogoś jeszcze. Jeśli nie ma managera produktu, to moim zdaniem świetnie dopełnia całość (znów) specjalista od użyteczności.

  6. Bogdan Baraszkiewicz16 lipca 2012 @ 08:50

    Hania, dziękuję za komentarz.1. Nie musi to być product manager. Może być specjalista od użyteczności, może być tester, programista, specjalista od marketingu czy prezes — ktokolwiek, byle była to osoba rzeczywiście odpowiedzialna za produkt, mająca takie umocowanie w organizacji, żeby móc pracować z interesariuszami i samodzielnie podejmować decyzje dotyczące produktu.2. Oczywiście, że jedna osoba (klient), a nawet dwie (z pomocą analityka) nie wymyślą takiego rozwiązania, jakie wymyśliłby zespół składający się ze specjalistów z różnych dziedzin. Od tego Product Owner ma do dyspozycji interdyscyplinarny Zespół Deweloperski, w którym ci wszyscy specjaliści wymyślają rozwiązania. Jeżeli przy produkcie jest potrzebna praca analityka czy specjalisty od użyteczności, to jak najbardziej powinny się znaleźć w tym zespole osoby mające takie kompetencje.

  7. OK, czyli mamy cały zespół składający się z wielu osób: klienta, analityka, UXa, innych, a Product Owner (kimkolwiek by nie był) jest odpowiedzialny po prostu za wybór najlepszego rozwiązania (jeśli nie ma lepszych to będzie to jego własne). I tak samo przy zmianach? Z propozycjami może wychodzić PO lub ktokolwiek, choć pewnie większość w proj. zewn. będzie pochodziła od klienta. Są one analizowane i PO podejmuje decyzję – wprowadzamy lub nie w taki lub inny sposób. Klient powie, że jest taka potrzeba, analityk przeanalizuje jak i z jakim wpływem na inne części, a PO powie czy warto i czy to robimy?

  8. Bogdan Baraszkiewicz16 lipca 2012 @ 09:47

    Mamy produkt. Mamy właściciela tego produktu (Product Owner), osobę odpowiedzialną za jego rozwój i mającą ostatnie słowo w kwestii co, czy i jak będzie robione. Mamy zespół deweloperski — grupę specjalistów z różnych dziedzin umiejących problem zanalizować, wymyślić rozwiązanie i je wdrożyć. Oraz interesariuszy (stakeholders) — osoby lub grupy osób mających różne oczekiwania wobec produktu (np. końcowi użytkownicy, działy marketingu, sprzedaży, biuro obsługi klienta, zarząd). Interesariusze wpływają na Product Ownera, Product Owner wspierając się zespołem deweloperskim podejmuje ostateczne decyzje, zespół wspierając się Product Ownerem tworzy rozwiązania.



Some HTML is OK

or, reply to this post via trackback.