Kim jest Product Owner w Scrumie?

Product Owner, czyli Właściciel Produktu, jest jedną z ról w Scrumie. Pełniąca ją osoba jest, obok Developerów i Scrum Mastera, członkiem nie-hierarchicznego Zespołu Scrumowego. Zgodnie z „Przewodnikiem Scruma” [1] Właściciel Produktu jest jedną osobą odpowiedzialną za maksymalizowanie wartości produktu tworzonego przez zespół Scrumowy.

Czym zajmuje się Właściciel Produktu?

Jednym z głównych zadań Product Ownera jest zarządzanie Backlogiem. [1] Jest to m.in. utworzenie Celu Produktu, przygotowanie i priorytetyzacja elementów Product Backlogu oraz zapewnienie jego przejrzystości i dostępności dla wszystkich.

[2] Product Owner ma wizję produktu, która powinna być zgodna ze strategią biznesową firmy. Jest kompasem – wskazuje kierunek rozwoju poprzez decyzje (zgodne z wizją produktu) o tym co, i w jakiej kolejności będzie realizowane przez Developerów. Decyzje te powinny być przejrzyście odwzorowane w postaci kolejności elementów Product Backlogu.

[2] Dzięki swoim decyzjom gwarantuje dostarczanie największej wartości firmie. Aby podejmować słuszne decyzje, powinien kierować się zasadami empiryzmu – mierzyć wartość dostarczanych funkcjonalności oraz zbierać i korzystać z informacji zwrotnych. PO powinien z otwartym umysłem słuchać Interesariuszy oraz starać się rozumieć potrzeby użytkowników końcowych.

Więcej o tym jak PO może realizować założenia empiryzmu znajdziecie w tym artykule.

Jak wygląda współpraca Product Ownera z Interesariuszami?

Zacznijmy od tego kim są Interesariusze… Są to wszystkie osoby, które „mają interes” (ang. Stakeholder, „stake-holder”) związany z wynikiem pracy Zespołu Scrumowego, czyli Przyrostem. [3] Mogą coś zyskać, lub stracić. W praktyce są to głównie osoby korzystające z produktu lub płacące za jego rozwój. To oni pomagają Właścicielowi Produktu zrozumieć co jest naprawdę wartościowe. Do tej grupy możemy dodać także inne podmioty, które mogą ułatwić kontekst pracy Zespołu Scrumowego – np. zespół sprzedażowy, regulatory, ekspert domenowy itd.

Product Owner powinien zidentyfikować wszystkich Interesariuszy, by nikogo nie pomijać w komunikacji. O metodach analizy Interesariuszy i dobierania strategii komunikacji opowiem w kolejnych wpisach.

Product Owner jest odpowiedzialny za to, by głos Interesariuszy był brany pod uwagę podczas pracy nad Produktem. [3] Jest to najlepszy sposób by minimalizować ryzyko strat związane z budowaniem złego produktu, lub rozwiązywaniem nieistniejących problemów.

Częścią współpracy z Interesariuszami jest rozmowa o ich potrzebach. Aby dostarczać wartość, produkt musi odpowiadać na realne potrzeby zarówno użytkowników końcowych, jak i „Biznesu” (np. zespołu sprzedażowego, prawniczego etc.). Niezwykle ważne jest by Product Owner dokładnie rozumiał te potrzeby, by następnie móc z Zespołem wypracować najlepsze rozwiązanie (Interesariusze często mówią o tym jakiej funkcjonalności chcą, zamiast skupiać się potrzebie / problemie, który chcą rozwiązać.).

*Mam niezwykle pozytywne doświadczenia ze współpracy z Interesariuszami jako cały Zespół Scrumowy. Developerzy mogą z powodzeniem uczestniczyć w spotkaniach roboczych z Interesariuszami, na których dyskutowane są potencjalne rozwiązania. Od razu dodają do rozmowy techniczną perspektywę (co jest możliwe, jakim kosztem etc.), lepiej – bo z pierwszej ręki – poznają potrzeby, mogą od razu zadawać pytania. Budują relację! Skraca się czas projektowania rozwiązania, bo PO nie musi grać w ping ponga z każdym pytaniem od Developerów.*

Relacja, którą Product Owner buduje z Interesariuszami, powinna bazować na zaufaniu. Komunikacja powinna być otwarta i przejrzysta. To pomaga prowadzić szczere rozmowy o Przyrostach, tak by Zespół mógł uzyskiwać konstruktywne opinie, które pomagają budować lepszy produkt.

Jak wygląda współpraca Product Ownera z Developerami?

Product Owner blisko współpracuje z Developerami. Jest pomostem, dzięki któremu kontekst biznesowy trafia do Zespołu (nie wyklucza to bezpośredniego kontaktu Developerzy – Interesariusze!). Zaraża wizją produktu. Decydując co będzie realizowane, powinien jasno mówić o tym jaka potrzeba będzie zaspokajana i gdzie jest wartość. Skupiając się na potrzebach użytkowników jako zespół – Product Owner i Developerzy – razem wypracowują rozwiązanie do zaimplementowania.

[4] Odpowiedzialność za Product Backlog (PB) nie oznacza, że PO musi robić wszystko sam. Bynajmniej! Często spotykany mit głosi, że to PO musi tworzyć i uzupełniać wszystkie elementy PB i jest jedynym źródłem wymagań, które podaje Developerom na tacy. Dużo korzystniejszy efekt uzyskuje się, jeżeli elementy PB są efektem wspólnej pracy całego Zespołu.

Praca nad PB dzieje się na ogół na tzw. Refinementach. Rozmowy o potrzebach użytkowników, proaktywne szukanie rozwiązań, sugestie kolejności elementów PB – to kwestie, w które powinni być żywo zaangażowani Developerzy, aby jako zespół móc wypracować największą wartość. W końcu co dwie głowy to nie jedna! Takie działania powodują, że jako Zespół mamy wspólne rozumienie założeń poszczególnych elementów Backlogu. Miłym skutkiem ubocznym jest szybsze i łatwiejsze planowanie 🙂 Często rośnie również poczucie odpowiedzialności Developerów za produkt – nie tylko piszą kod, ale realnie mają wpływ na jego projekt.

Aby współpraca z Developerami przebiegała płynnie, PO musi być dostępny. Relacja ta nie jest hierarchiczna (Product Owner nie zarządza Developerami) [4] i powinna bazować na zaufaniu. Jako Zespół, wszyscy jego członkowie są odpowiedzialni za tworzenie wartościowego Przyrostu (ang. Increment).

Moc decyzyjności

Product Owner MUSI być umocowany do podejmowania decyzji o produkcie. [1] W Scrum Guide jest wprost napisane: „Aby praca Product Ownera mogła przynosić pożądane efekty, jego decyzje muszą być respektowane przez całą organizację”. I jest to kluczowe, aby opisane powyżej kwestie działały prawidłowo i praca mogła iść do przodu prawdziwie zwinnie.

Podsumowanie

Właściciel Produktu to rola, która jest gwarantem maksymalizowania dostarczanej wartości. PO powinien słuchać i mieć otwartą głowę na pomysły, sugestie, czy opinie, które do niego spływają od członków Zespołu, Interesariuszy i użytkowników. Razem z Zespołem wypracowuje najlepsze rozwiązania, mając na uwadze potrzeby użytkowników. Podejmuje decyzje, których odzwierciedleniem jest przejrzysty, posortowany i dostępny dla wszystkich zainteresowanych Product Backlog. Sam PB jest przez to jedynie narzędziem, a nie sensem pracy Product Ownera.