Product Owner – osoba, której nadrzędnym celem jest dostarczenie jak największej wartości w jak najkrótszym czasie. Wspierany przez zespół deweloperski ponosi jednoosobową odpowiedzialność za sukces bądź porażkę swojego projektu. W prowadzeniu projektu wykorzystuje narzędzia, które pomagają mu kontrolować czas, budżet, zasoby oraz cele projektu i potrzeby biznesowe.

Zarządzanie rejestrem produktu (Product Backlog)

Rejestr produktu to główne narzędzie pracy właściciela produktu. Ponosi za niego pełną odpowiedzialność, której nie może delegować. Product Owner musi zadbać o szeroki i płynny przepływ informacji oraz ich przejrzystość. To pomoże zrozumieć głównym interesariuszom, na co przeznaczane są ich pieniądze, dlaczego zespół zajmuje się określonymi zadaniami  oraz w jakiej kolejności będą one realizowane. Krótko mówiąc – uczestnicy projektu, przede wszystkim biznes i zespół deweloperów, muszą mieć wiedzę na temat bieżącego stanu prac. Na właścicielu produktu spoczywa obowiązek zadbania o komunikację i pilnowania, aby rejestr produktu był uporządkowany i aktualny.

 

Priorytety

Priorytetyzacja to sporządzenie  hierarchii poszczególnych wymagań  w ramach rejestru. To ważne zadanie, ponieważ ma wpływ na kolejność prac oraz pozwala zrozumieć, w jakim kierunku zmierza produkt. Jasno określone priorytety odzwierciedlają obraną przez właściciela produktu strategię, którą podąża w celu osiągnięcia jak największej wartości. Priorytety dostarczają również kontekst zespołowi deweloperskiemu: dzięki temu dokładnie wie, czego może spodziewać się w nadchodzących sprintach. Pozwala to na podejmowanie lepszych decyzji w zakresie architektury, co skutkuje wyższą jakością ostatecznego produktu. Widać tu wyraźnie jeden z filarów Scruma, czyli Przejrzystość.

Priorytet w rejestrze produktów często przybiera bardzo prozaiczną formę: historyjka znajdująca się na szczycie rejestru  jest w danym momencie najważniejsza, ta będąca na końcu ma najniższy priorytet.

Warto pamiętać, że ważność wymagań i strategia produktu nie są wykute w skale. Jak wszystko w projektach prowadzonych w  Scrumie, należy je analizować, konfrontować z rzeczywistością i aktualizować (filary Scruma: Inspekcja i Adaptacja). Product Owner stale uczy się i zbiera informacje na temat projektu, dlatego musi cyklicznie weryfikować  rejestr produktu i na podstawie aktualnej wiedzy oceniać zasadność przyjętych priorytetów. W ten sposób nie tylko porządkuje rejestr, dba również o efektywne wykorzystanie czasu i budżetu. Dla przykładu: jeśli określone zadanie z top 10 spada na setną pozycję, prawdopodobnie nie ma potrzeby, aby je analizować i estymować. Ten czas można przeznaczyć na historyjki o wyższym priorytecie.

 

Dobre zdefiniowanie historyjek

W projektach możemy wydzielić trzy podstawowe jednostki:

  • Zadanie (ang. Task) – element “techniczny”, zdefiniowany bezpośrednio przez zespół deweloperów. Tworzone i utrzymywane w ramach rejestru sprintu.
  • Historyjka (ang. User story) – opis wymagania, przygotowany przez właściciela produktu, na podstawie perspektywy użytkownika. To element wnoszący wartość do systemu, może zostać wdrożony w ramach jednego sprintu. Nie zawsze jest to nowa funkcjonalność.
  • Epik (ang. Epic) – przypomina historyjkę, jednak jego skala i wpływ są dużo większe. To rozległa historia (również utrzymana w konwencji  perspektywy użytkownika), obejmująca duży obszar systemu. Nie jest możliwe wdrożenie epika w obrębie pojedynczego sprintu, dlatego też nie podlega estymacji dokładniejszej niż tzw. T-shirt sizing. Aby podjąć pracę nad epikiem, należy go najpierw rozbić na mniejsze historyjki, które będą uwzględniane w ramach procesu estymacji, priorytetyzacji i planowania.

Przy tworzeniu historyjek oraz ich priorytetyzacji warto także  zwrócić uwagę na kompetencje zespołu deweloperskiego. Zespół scrumowy jest co do zasady zespołem z wymiennymi kompetencjami, zatem określone  zadanie może być wykonane przez kilku jego członków. Zasada ta jednak nie jest uniwersalna. Dobry Product Owner zna możliwości swojego zespołu i bierze pod uwagę moce przerobowe w konkretnych obszarach. Tworzy więc zadania tak, aby zrównoważyć rozłożenie prac w zespole. Wymaga to elastyczności, bowiem nawet w podejściu iteracyjnym niektóre zadania muszą być wykonywane sekwencyjnie. W takich sytuacjach można podjąć ryzyko i np. poprosić deweloperów front-end, aby pracowali na atrapie danych – zamiast czekać, aż back-end zakończy pracę. Oczywiście, istnieje możliwość, że na etapie integracji ujawnią się różnice, które będą wymagały korekt – niemniej, jest to znacznie lepsze wyjście niż bezczynne oczekiwanie, które kreuje zbędny koszt i rosnącą frustrację w zespole.

 

Adaptacja

Opisywanie elementów przez Product Ownera nie powinno odbywać się na wyrost i z przesadną precyzją. Ważne jest, aby przedstawić zagadnienie oraz dostarczyć  kluczowych informacji. Po raz kolejny na pierwszy plan wysuwają się filary Scruma, czyli Inspekcja i Adaptacja. Każdego dnia zyskujemy wiedzę, która pozwala na lepsze zrozumienie realizowanego projektu. Wiedza ta może diametralnie zmienić nasz punkt widzenia, co  spowoduje, że bardzo precyzyjnie opisane historyjki stracą aktualność, a czas na nie poświęcony pójdzie na marne.

Rolą właściciela produktu jest stałe zarządzanie rejestrem i dostarczanie na czas niezbędnej wiedzy. Nie wcześniej, nie później, w czym bardzo  pomagają priorytety. Odpowiednio uporządkowany rejestr już na pierwszy rzut oka pokazuje, co powinno być opracowane i zdefiniowane w pierwszej kolejności, a co może zostać na poziomie  krótkiej zajawki.

Miarą dobrego Product Ownera jest między innymi  umiejętność pracy z zakresem projektu, rozpoczynając od jego definicji, poprzez nadawanie priorytetów aż po umiejętne rozłożenie nacisku na  poszczególne obszary kompetencji. Przyswojenie podstawowych zasad zarządzania backlogiem lub tworzenia wymagań jest zaledwie pierwszym krokiem w kierunku poszerzania wiedzy i umiejętności, wymaganych od Product Ownera.

 

Optymalizacja wartości płynącej z pracy developerów

Product Owner na bieżąco  współpracuje z zespołem deweloperskim. Nie  sprawuje nad nim jednak żadnej formalnej kontroli (w przeciwieństwie do kierownika projektu). Jego zadaniem jest dostarczenie odpowiedzi na kluczowe pytania i wyjaśnienie  wszystkich wątpliwości, które pojawiają się w trakcie realizacji projektu. Właściciel Produktu może przydzielić to zadanie innej osobie, jednak ponosi odpowiedzialność za wszystkie błędy, które wyniknęły z powodu tej delegacji. To potwierdza  faktyczną rolę Product Ownera w projekcie i jego jednoosobową odpowiedzialność. Jest to zgodne z kolejnym filarem Scruma, czyli Przejrzystością – każdy członek zespołu wie, do kogo można skierować dane pytanie i gdzie szukać wsparcia w zakresie historyjek i rejestru produktu.

Dobra i ścisła współpraca między Product Ownerem a zespołem deweloperskim staje się niezwykle istotna, gdy zachodzi ryzyko zagrożenia celu sprintu. Wówczas zespół wraz z Właścicielem Produktu muszą wypracować zmiany w zakresie sprintu, aby jego cel został zrealizowany w jak największym stopniu. Można to osiągnąć poprzez eliminację zadań o niskim priorytecie lub podział niektórych elementów i rozłożenie ich na kolejne sprinty. Zespół zapewnia wsparcie techniczne i merytoryczne od strony produkcyjnej, a właściciel produktu kontroluje potrzeby ze strony biznesu.

Zawsze jednak należy pamiętać, że Product Owner nie powinien przydzielać pracy konkretnym członkom zespołu, lecz jedynie mieć na uwadze ich kompetencje i umożliwić im kreowanie wartości przez cały czas trwania projektu.

 

Podsumowanie

Jak widać, każde, z pozoru proste, zagadnienie zawiera wiele niuansów. Zetknięcie się z realnym (czasem brutalnym) światem podczas realizacji  projektu również stwarza dodatkowe przeszkody. Niezależnie od presji czasu, interesariuszy czy zespołu, trzeba pamiętać o podstawowych zasadach, dotyczących rejestru produktu: musi być zawsze zdefiniowany, mieć formę zrozumiałych wymagań oraz przypisane określone priorytety. Takie podejście zapewni solidną podstawę do doskonalenia procesu wewnątrz zespołu projektowego w oparciu o informacje zwrotne od zespołu i interesariuszy.

Autor

  • Piotr Majak
  • Lider Zespołu Project Managementu w Craftware
  • Od 7 lat zajmuje się zwinnym zarządzaniem. Swoje doświadczenie zdobywał w dużych korporacjach, startupach i organizacjach pozarządowych (NGOs).

Podobał Ci się mój artykuł?

Jeśli tak, zapraszam Cię do grona najlepiej poinformowanych czytelników bloga. Dołącz do naszego newslettera, a nie ominą Cię żadne nowości.