Jak wszyscy wiemy, życie Product Ownera nie zawsze jest usłane różami. Realizacja Backlogu Produktu zgodnie z założeniami to utopia, Właściciel Produktu często napotyka na swojej drodze wyzwania. Jak wyglądają najczęstsze problemy PO?
Brak wizji produktu
Największe z najczęstszych „przewinień” PO to brak wizji produktu. Pracując w metodykach zwinnych zakładamy, że nasz produkt będzie rozwijany bezterminowo. A skoro tak, to musimy to robić w jakimś określonym kierunku. Nie możemy przecież uznać, że hasłowe elementy z backlogu zebrane np. podczas Sprint Review będą wizją produktu.
Wizja produktu winna być rozumiana jako obraz naszego produktu tak, jak będzie on wyglądał w przyszłości. Wizja nadaje klarowny kierunek rozwoju tego, nad czym obecnie pracujemy.
Wizja produktu to jasna informacja dla zespołu deweloperskiego co do zakresu potencjalnych zmian w systemie. Jest to również informacja o tym, w jaki sposób realizować dzisiejsze funkcjonalności w zgodzie z potencjalnymi, przyszłymi wymaganiami. To Właściciel Produktu jest odpowiedzialny za przekazanie zespołowi tych informacji.
Sama lista wymagań nigdy nie jest kompletna, ale musi być na tyle spójna, żeby widoczny był kierunek zmian. Właściciel Produktu powinien dodać do tego wizję, aby możliwa było odpowiedź na pytanie „co będzie robione w przyszłości?”. Warto ją przedstawić w sposób graficzny, na przykład za pomocą Roadmapy czy narzędzia pozwalającego na wizualizację.
Zaniedbywanie backlogu
Zarządzanie Backlogiem Produktu to ogromny kawałek odpowiedzialności PO, którego nie można pominąć. Do backlogu cały czas trafiają nowe rzeczy i bardzo łatwo jest skupić się tylko i wyłącznie na próbach zapanowania nad nawałem wymagań, sugestii, błędów i zgłoszeń. To jednak nie wszystko, czym zajmuje się Właściciel Produktu.
„Doskonalenie (ang. refinement) Backlogu Produktu jest działaniem polegającym na dodawaniu szczegółów, oszacowań i porządkowaniu elementów Backlogu Produktu. Jest to ciągły proces, podczas którego Właściciel Produktu wraz z Zespołem Deweloperskim opracowują szczegóły elementów Backlogu Produktu. Podczas doskonalenia Backlogu Produktu jego elementy są przeglądane i korygowane.” – Scrum Guide
Tak jak już wspominaliśmy, zarządzanie backlogiem to o wiele więcej niż tylko Product Backlog Refinement. Obejmuje ono priorytetyzację, opisywanie i szacowanie zarówno nowych wymagań, jak i tych, którymi już kiedyś się zajęliśmy. Wszystko się zmienia, a nasze dawne priorytety, rozwiązania i opisy bardzo szybko się dezaktualizują.
Zaniedbany backlog nie tylko przeszkadza całemu Zespołowi Scrumowemu, ale i działa na szkodę projektu.
Brak umocowania w organizacji
Brak umocowania w organizacji to z kolei jedno z najgorszych przewinień, jakie zarządzający naszą firmą mogą wyrządzić Właścicielowi Produktu. Zgodnie z zapisami ze Scrum Guide:
„Aby Właściciel Produktu mógł odnieść sukces, cała organizacja musi respektować jego decyzje.” – Scrum Guide
W praktyce oznacza to, że nikt nie powinien podważać decyzji PO odnośnie priorytetów wymagań w Product Backlogu. Tylko jedna osoba, Właściciel Produktu, może decydować o tym, co na chwilę obecną jest najważniejsze.
Analogicznie, nikt nie powinien ingerować w opis wymagania, bo to przecież Właściciel Produktu jest przedstawicielem klienta i ma najlepszą wiedzę w zakresie tego co klient chciał uzyskać poprzez jego realizację. Co więcej, to PO często ma alternatywne pomysły na realizację potrzeb biznesowych klienta, bo wie, co może być dla niego przydatne.
Ingerencja innych osób w czynności zarezerwowane stricte dla Właściciela Produktu zawsze pachnie nam tak bardzo nielubianym mikromanagementem. Jest to temat trapiący nas na tyle, że na pewno niedługo doczeka się wpisu na naszym blogu lub filmu na YouTube.
Łączenie roli Product Ownera i innych ról projektowych
Efekt synergii mówi nam o tym, że dwa plus dwa to czasami więcej niż cztery. Sprawdza się to przy budowaniu zespołów, ale niekoniecznie przy łączeniu wielu ról przez jedną osobę.
Nie ma co się rozpisywać o łączeniu roli Właściciela Produktu i Scrum Mastera. Chociaż teoretycznie jest to dozwolone przez metodykę, to w praktyce raczej nie występuje. I dobrze, bo pomimo dążenia do osiągnięcia wspólnego celu, role te bywają przeciwstawne.
Często spotykaną praktyką jest natomiast łączenie roli Właściciela Produktu z rolą Project Managera. Również i w tym przypadku to połączenie utrudnia osiągnięcie efektów, dla których te role zostały stworzone. Bywa to spowodowane innym ich rozumieniem przez członków zespołu deweloperskiego. PM zwykle odbierany jest jako przełożony zespołu, w dodatku zorientowany na terminy i „dokręcający śrubę”. Podobnie rzecz ma się w przypadku Team Leadera czy innych ról przekładając się na bycie zwierzchnikiem dla ludzi pracujących w zespole deweloperskim.
Zastanawiając się nad połączeniem roli PO z inną zawsze musimy rozważyć czy podstawowe obowiązki tego pierwszego nie zostaną „rozmyte”.
Zapracowany Właściciel Produktu
Dostępność! Od organizacji pracy samego PO, wielkości organizacji, wielkości projektu i ilości zadań z którymi musi się on zmierzyć w danej chwili zależy stopień dostępności Właściciela Produktu dla interesariuszy i zespołu.
Rzecz, którą na pewno możemy zrobić to możemy na bieżąco monitorować ilość zadań, którą zajmuje się Właściciel Produktu i wspierać go w jego pracy. Zarówno Scrum Master jak i Zespół Deweloperski mogą (i powinni) brać czynny udział chociażby w zarządzaniu Backlogiem Produktu, a także wspierać PO tam, gdzie przyniesie to korzyść całemu Zespołowi Scrumowemu.
Do dobrych praktyk skalowania Scrum należy odciążanie PO przez wprowadzenie takich ról jak Junior PO (proxy-PO) lub Senior PO (Tribe Leader).
Nie ulega wątpliwości, że zapracowany bądź niedostępny Właściciel Produktu może spowodować, że elementy Backlogu Produktu i wizja nie będą do końca jasne dla zespołu deweloperskiego i interesariuszy. A to powoduje, że trudno jest utrzymać jeden kierunek rozwoju.
Czy jesteśmy więc skazani na porażkę?
Nie będziemy skazani na porażkę, o ile nie będziemy wypaczać roli Product Ownera i okażemy mu pełne wsparcie w realizacji jego zadań. Tylko w ten sposób zapewnimy sobie właściwą opiekę nad wymaganiami i wizją naszego produktu.
Z punktu widzenia organizacji, powinniśmy zapewnić osobie będącej na tym stanowisku komfort pracy. Z drugiej strony jednak, powinniśmy zadbać o to aby ta rola była dobrze określona (zgodnie z zapisami Scrum Guide) tak, aby była prawidłowo rozumiana przez członków Scrum Team.
