Podstawowe narzędzia pracy Product Ownera

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 zwinnych, 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.

Przeczytaj także: Kim NIE JEST Product Owner.

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.