Product Owner – kim jest i dlaczego ma kluczowy wpływ na powodzenie projektu?

Prace w projektach IT coraz częściej realizowane są zwinnie, dzięki czemu możliwe jest osiąganie celów biznesowych w nawet najbardziej zmiennym otoczeniu. O tym, dlaczego podejście zwinne sprawdza się w naszej współpracy z Klientami, pisałam w tym artykule.  Jednak sama metodyka to za mało, aby projekty kończyły się sukcesem. Kluczowe są osoby, które realizują prace projektowe i w praktyce działają w podejściu zwinnym. 

Choć ról zdefiniowanych w metodyce zwinnej Sente jest kilka/kilkanaście, to jest jedna, bez której projekt będzie obarczony dużym ryzykiem niepowodzenia – Product Owner. Dlaczego jest tak ważny i w jaki sposób powinien pełnić swoją funkcję, aby doprowadzić projekt do szczęśliwego zakończenia? O tym opowiem w poniższym artykule.  

Według definicji, którą przyjmujemy w Sente, Product Owner (Właściciel Produktu) to osoba decyzyjna w projekcie po stronie firmy, dla której realizowane są prace. Musi być umocowany w organizacji i mieć możliwość działania z dużą swobodą. Łączy funkcje właściciela wizji i wymagań oraz jest odpowiedzialny za ostateczną wartość produktu, który ma być efektem projektu. Główne zadania Product Ownera to zarządzanie listą tematów do realizacji (Backlogiem Produktu) i weryfikacja prac zrealizowanych w poszczególnych etapach (Sprintach) przez Zespół Deweloperski. Jego zakres odpowiedzialności jest szeroki i złożony, co sprawia, że często nazywany jest najważniejszą osobą w projekcie.

Product Owner pełni rolę Właściciela Produktu – od początku do końca projektu to po jego stronie leży odpowiedzialność za to, aby realizowane prace przyniosły finalnie wymierną i maksymalnie dużą wartość w jego organizacji. Na co dzień zarządza zakresem i podejmuje decyzję o kształcie i kolejności podejmowanych prac. Dlatego powinien mieć szeroką wiedzę na temat procesów zachodzących w firmie oraz celów, które mają zostać osiągnięte w projekcie i zarządzać działaniami tak, aby były jak najbardziej efektywne. 

W Zespole Projektowym, zarówno po stronie Klienta, jak i dostawcy rozwiązań, funkcjonuje oczywiście wiele innych, istotnych ról, które wspierają na co dzień Product Ownera. Project Managerowie czy Architekci przekazują mu na bieżąco informacje o postępach i najważniejszych z ich perspektywy tematach, są partnerami do dyskusji i towarzyszą w rozwiązywaniu problemów. Ale to Product Owner podejmuje decyzje o przebiegu prac i bierze odpowiedzialność za to, czy i jak przybliżą one projekt do osiągnięcia celu. 

Product Owner pracuje na co dzień z Backlogiem, czyli z listą tematów do realizacji. W podejściu zwinnym z definicji ta lista cały czas żyje, nigdy nie jest skończona, chyba że zbliżamy się do uruchomienia. Wtedy podejmujemy świadomą decyzję, że jesteśmy na takim etapie prac, w którym zamykamy listę i nie dodajemy już do zakresu prac nic więcej, bo skupiamy się na tym, co jest do dowiezienia do uruchomienia. 

Jednak w trakcie trwania projektu Backlog cały czas żyje, a Product Owner powinien z nim cały czas pracować. Musi stale analizować, czy wszystkie tematy założone do realizacji na początkowym etapie projektu są zasadne również w kolejnych jego etapach. Czasem podstawowa wersja rozwiązania zaprezentowana przez Zespół Developerski na odbiorach jako prototyp okazuje się w pełni realizować potrzeby biznesowe Klienta. Wówczas, nawet jeśli w Backlogu przewidziane było bardziej zaawansowane rozwiązanie, Właściciel Produktu może zdecydować, aby ograniczyć się do już powstałego elementu. Dzięki czemu możliwe jest zaoszczędzenie czasu i środków finansowych oraz przeznaczenie ich na bardziej istotne w danym momencie prace. Stosując takie zabiegi, Product Owner może systematycznie zwiększać wartość, jaką projekt przyniesie biznesowi i to powinno stanowić jego główny obszar koncentracji. 

W pracy Product Ownera ważna jest jej systematyczność i regularność – nie są to zadania, do których można usiąść raz na kilka tygodni i nadrobić zaległości. Projekt toczy się dzień po dniu, Zespół Developerski cały czas pracuje nad rozwiązaniami, ma pytania doprecyzowujące do poszczególnych tematów. Wsparcie ze strony Właściciela Produktu jest potrzebne w procesie weryfikacji postępów prac, ustalania priorytetów i zbierania wymagań biznesowych. 

Jeśli osoba pełniąca tę rolę nie pracuje “w trybie ciągłym”, to wpływa to negatywnie na tempo prac, a czasami nawet je blokuje. Prace nie powinny iść do przodu, jeśli Product Owner jest nieobecny – Zespół Developerski nie powinien realizować tematów, o których na poziomie biznesowym nie wie Właściciel Produktu. Jeśli proces biznesowy został omówiony i jego przebieg jest ustalony, to elementy technologiczne rozwiązania Zespół Developerski może wykonywać na bieżąco.

Operacyjnie, rola Product Ownera polega na pracy z Zespołem Developerskim w systemie zarządzania zgłoszeniami (w przypadku projektów Sente jest to system Jira). To on decyduje o priorytetach i kolejności realizowania zleceń.

Aby praca Product Ownera była efektywna, powinien on charakteryzować się kilkoma kluczowymi cechami. Dzięki nim pełnienie tej roli przychodzi bardziej naturalnie, a prace w projekcie przebiegają płynnie.

Product Owner musi być osobą decyzyjną i jego zdanie powinno mieć umocowanie w firmie. W średnich i mniejszych projektach taką rolę może pełnić właściciel – wtedy o decyzyjność nietrudno, ale problem może stanowić możliwość wygospodarowania odpowiedniej ilości czasu na pełnienie tej roli. Idealnie, kiedy pełni ją osoba decyzyjna, która jednak w swoim grafiku ma zarezerwowane średnio 0,5-2h dziennie na pracę nad projektem (w zależności od jego skali). Taka osoba powinna mieć zmniejszony zakres obowiązków operacyjnych – to nie jest dodatek do bieżącej pracy, a projekt, który wymaga dyspozycji na część etatu pracy. 

Product Ownerem powinna być osoba, której decyzje są, oprócz skrajnych przypadków, niepodważalne. Nie oznacza, że osoba pełniąca tę rolę jest osamotniona czy obarczona zbyt dużą odpowiedzialnością. Powinien on, konsultować różne tematy, np. strategiczne z właścicielami, którzy w projekcie pełnią rolę Sponsora projektu. Jednocześnie osoby zarządzające firmą powinni mieć zaufanie do Product Ownera i mieć przekonanie, że w ustalonym budżecie projektu zadba on o dostarczenie jak największej wartości dla ich firmy.

Jest takie powiedzenie: “Jakiego słowa powinien najczęściej używać Product Owner? Nie” 🙂 To oczywiście hiperbola, ale faktycznie dużą część pracy Product Ownera stanowi odmawianie. Na tym polega ta rola – mamy dookoła interesariuszy, którym zależy na zrealizowaniu swoich potrzeb, ale jest ich zawsze więcej niż mocy przerobowych w zespole. Product Owner musi wybrać najważniejsze tematy i decydować, co i w jakiej kolejności będzie realizowane – w ustalonym czasie i budżecie nie da się zrobić wszystkiego. 

Jest to trudna rola, bo nie zawsze mamy w firmie świadomych i zaangażowanych kluczowych interesariuszy, którzy przyjdą i powiedzą, czego rzeczywiście potrzebują i oczekują od projektu. Często rola Product Ownera polega też na szukaniu i dociekiwaniu, co jest do zrobienia – musi on czasem wchodzić “tylnymi drzwiami” i wyłapywać, co jest najważniejsze. W takich sytuacjach potrzebna jest pewnego rodzaju relacyjność i komunikatywność.

Praca z Backlogiem i wymaganiami to ciągłe zarządzanie zmianą. Dlatego tak ważne jest, aby Product Owner był tego świadomy i wszelkie modyfikacje, nowe tematy czy nieprzewidziane sytuacje, pojawiające się w czasie realizacji prac, traktował jako nieodłączną część pracy w projekcie. Takie nastawienie pozwala dobrze odnajdywać się w dynamice pracy zwinnej oraz skutecznie reagować na stale pojawiające się wyzwania.

Nasze doświadczenie pokazuje, że dla zdecydowanej większości Klientów współpraca z nami to pierwsza styczność z metodyką zwinną. W związku z tym, zwykle na początku projektu prowadzimy osobę pełniącą rolę Product Ownera “za rękę”, tłumacząc jak wygląda schemat metodyki naszej pracy i jak funkcjonuje ona w praktyce. Na początku projektu skala informacji jest tak duża, że może być przytłaczająca, ale z każdym kolejnym tygodniem jej zrozumienie rośnie. Product Owner doświadcza tego, jak wygląda planowanie prac, odbiory, spotkania i komunikacja w projekcie – w praktyce uczy się, jak wygląda praca w tej metodyce. Dlatego, nawet dla niedoświadczonego Product Ownera, próg wejścia do działania w projektach zwinnych jest relatywnie niski, a najważniejsza okazuje się otwartość na naukę.

Bardzo ważne jest to, aby Product Owner przed rozpoczęciem prac dokładnie przemyślał, czego oczekuje się od niego w tej roli, jakie są cele jego działania, dlaczego jest potrzebny i tak ważny w projekcie. Na początku są to wyobrażenia, ale ważne, aby powstały. Product Owner może też skonsultować je i omówić z Zespołem Projektowym, Dzięki temu zaczynając działanie w projekcie jest dużo bardziej świadomy i nawet jeśli jego wiedza o metodyce zwinnej nie jest jeszcze duża, to już ma podstawy, aby skutecznie pełnić swoją rolę. Jeśli przygotowujesz się do pełnienia roli Product Ownera, to czytając ten artykuł jesteś na bardzo dobrej drodze, aby zwiększyć swoją wiedzę w tym zakresie i odpowiednio wejść w nowe obowiązki.

Jakie zachowania Product Ownera mogą działać na szkodę projektu? Do jakich sytuacji nie powinien on dopuszczać?

Bardzo niekorzystna dla projektu jest sytuacja, kiedy Product Owner jest nieobecny na etapie weryfikacji efektu prac, nie ma go przez dłuższy czas na spotkaniach, na planowaniu prac. Wtedy traci kontakt z zespołem, nie wie co jest realizowane, nie jest na bieżąco z postępem realizacji prac w Backlogu. W takim trybie nie da się skutecznie prowadzić projektu i panować nad tym, aby postępujące prace szły w odpowiednim kierunku. Takie zachowanie rozmywa decyzyjność i sprawia, że nie ma w projekcie osoby, która nadzoruje kształt finalnego rozwiązania. Taką osobą zawsze powinien być Product Owner. 

Product Owner nie powinien również pozwalać na realizowanie wszystkich tematów, które zgłaszane są przez interesariuszy. Kiedy nie potrafi on wybierać najważniejszych tematów i nagminnie zgadza się na realizację kolejnych prac dodatkowych, to w konsekwencji działania w projekcie idą do przodu, ale lista elementów wymaganych do realizacji przed uruchomieniem nie spada. Koniec projektu się zbliża lub oddala, budżet jest przekroczony, a zakres prac niezrealizowany. To niedopuszczalna sytuacja, ale niestety zdarza się w momencie, kiedy osoba pełniąca rolę Właściciela Produktu nie panuje nad zakresem. Nie monitoruje na bieżąco takich elementów, jak pozostała do realizacji liczba tematów, czas i budżet. 

Oczywiście podejście zwinne pozwala na realizację dodatkowych tematów. Jednak zawsze przed decyzją o ich podjęciu, Product Ownerowi powinna zapalić się lampka czy są to prace, które przybliżą nas do osiągnięcia celu projektu czy po prostu są to ciekawe tematy, który warto byłoby zrobić, ale nie mają one wpływu na realizację celów projektu. Takie decyzje to zakres jego odpowiedzialności i rezygnacja z różnych pomysłów, to duża część jego pracy. Godząc się na realizację wszystkiego, przekreśla on szansę na zrealizowanie celów projektu w założonym czasie i zakresie.

Jeśli przygotowujesz się do pełnienia roli Product Ownera lub szukasz informacji na ten temat, to w moim artykule znajdziesz najważniejsze kwestie, na które powinieneś zwrócić uwagę. Jednocześnie każdą z nich warto pogłębić w kontekście specyfiki Twojej firmy, projektu czy celów, które chcesz osiągnąć. To pozwoli Ci jeszcze lepiej poznać istotę tej roli i dobrze przygotować się do startu projektu… a później dbać o to, aby przyniósł on Twojej firmie zamierzone efekty, czego serdecznie Ci życzę.