Kim NIE JEST Product Owner

Otoczenie – nic nie dzieje się w próżni

Firmy funkcjonują w świecie ogólnie przyjętych nazw i schematów działania. Programiści, projektanci, analitycy, testerzy – bez tych ról organizacje nie wyobrażają sobie funkcjonowania. Nad nimi władzę dzierży kierownik, który dba o „dowiezienie” projektu na czas, który z kolei swoją pracę raportuje do wyższego stopniem managera. Wszystko to pod ciepłą pierzynką bierności, która stawia projekt pomiędzy być, a nie być.

Sam Scrum nie jest skomplikowany. To bardzo skondensowana technika, zbiór narzędzi, które są możliwe do wdrożenia w wielu dziedzinach biznesu i różnych branżach. Prawdziwym wyzwaniem jest zrozumienie idei, która za nim stoi, zmiana nawyków i podejścia do poszczególnych elementów w organizacji. Największą trudnością podczas wdrożeń jest przekonanie managerów i zarządu do całkowitej reorganizacji firmy oraz zmiany podejścia do projektów, kultury pracy i sposobu stawiania celów.

Zespół Scrumowy

Przyjrzyjmy się roli Właściciela Produktu (ang. Product Owner), która jest źle interpretowana niemal w każdym aspekcie. Zarówno przez zespół deweloperski, jak i przez przełożonych. Obie strony pokładają w nim inne, często sprzeczne, nadzieje. Brak wspólnej wizji i zrozumienia to najlepszy przepis do osiągnięcia sromotnej klęski w projekcie, a tego przecież nie chcemy.

Zacznę od opisu świata, w którym się znajdujemy. Zespół scrumowy składa się z trzech ról:

• Scrum Master – zwany czasem mistrzem ceremonii. Odpowiada za to, aby cały proces scrumowy był prawidłowo implementowany zarówno w zespole jak i w całej organizacji.
• Product Owner – właściciel produktu. Jest odpowiedzialny za biznesowy aspekt projektu i/lub produktu. Na jego roli skupię się w tym artykule.
• Development Team – zespół deweloperski odpowiada za dostarczanie przyrostu w każdym sprincie. Są to osoby o różnych kwalifikacjach i umiejętnościach, dzięki czemu realizują projekty od początku do końca.

Nadrzędnym celem Scruma jest umożliwienie szybkiego i płynnego dostarczania wartości. Wartość nie musi być finansowa czy możliwa do bezpośredniej monetyzacji. Może być rozumiana jako nowa funkcjonalność, spłata długu technicznego, weryfikacja prototypu, zwiększenie satysfakcji klienta itp. Chodzi o to, aby jak najszybciej wprowadzać nowe elementy małymi krokami i analizować ich skutek, w celu jak najlepszego i najszybszego dostosowania strategii do dalszych działań. U podstaw Scruma leży ciągła inspekcja i adaptacja każdego elementu projektu. Od procesu, przez codzienne działania, na strategii  kończąc. Inspekcja i adaptacja to dwa z trzech filarów Scruma. Ostatnim filarem jest przejrzystość, która ma bezpośredni wpływ na to, w jaki sposób rola właściciela produktu, scrum mastera i zespołu deweloperskiego zostały zdefiniowane.

Rola Product Ownera

Rola Product Ownera jest pełniona tylko i wyłącznie przez jedną osobę. Wspiera to przejrzystość (trzeci filar Scruma) w obrębie projektu i organizacji. Dzięki temu nie zastanawiamy się z kim należy rozmawiać o danym zagadnieniu, jak ma to miejsce w przypadku tradycyjnych zespołów, oraz ułatwia przepływ informacji. Nie musimy też szukać osoby odpowiedzialnej, ponieważ zawsze będzie to właściciel produktu.

Product Owner w obrębie zespołu scrumowego jest najczęściej sprowadzany lub porównywany do kierownika projektu (ang. Project Manager), którego znamy z klasycznych metod zarządzania projektami. Wynika to z potrzeby dopasowania nienaturalnej dla niektórych firm struktury narzucanej przez Scrum, do realiów jakie są im znane. Ciężko jest z dnia na dzień przejść z liniowej organizacji zespołu na interdyscyplinarną, złożoną z niezależnych podmiotów, bez wyraźnego przywództwa. Budzi to często pewien sprzeciw wynikający z oporu przed zmianą, wyjściem ze swojej strefy komfortu i utrwalonego schematu działania. Jest to jednak błędne uproszczenie. W zależności od obszaru typowy Project Manager może posiadać większe lub mniejsze kompetencje niż Product Owner. Charakterystyka obu stanowisk, cele które są przed nimi postawione oraz filozofia działania są odmienne. Najlepiej całkowicie rozdzielić te dwie role. Tak jak wspomniałem, Scrum przewiduje istnienie trzech ról i kierownik projektu nie jest jedną z nich.

Sprint goal

Zacznijmy od zrozumienia kim jest Product Owner i jakie są jego obowiązki względem biznesu i zespołu scrumowego.

W obrębie każdego sprintu zespół scrumowy wraz z właścicielem produktu określają cel, czyli krótki opis tego na czym zespół skupi się w nadchodzących tygodniach. Jest to wartość biznesowa, którą mają dostarczyć niezależnie od stadium, w którym znajduje się produkt.

Co jest kluczowe, aby prawidłowo określić cel?

• Wiedza na temat długofalowych celów jakie firma/produkt mają osiągnąć.
• Zrozumienie potrzeb klienta, biznesu, głównych interesariuszy.
• Dostęp do odbiorców.
• Strategia produktu zgodna ze strategią firmy i jej długofalowymi celami.
• Płynne i skuteczne określanie priorytetów.

Powyższa wiedza jest najczęściej rozproszona. W zależności od charakteru produktu może być rozrzucona w organizacji, wśród interesariuszy, u klientów czy w różnych zbiorach danych. Potrzebny jest ktoś, kto zbierze te informacje, zrozumie, uporządkuje i zbuduje na ich podstawie strategię. A co najważniejsze – weźmie za to odpowiedzialność.

Pamiętajmy, że produkt czy projekt nigdy nie powstają w próżni. Pomijając typowe ograniczenia – czas i budżet, należy uwzględnić inne czynniki przy realizacji projektu: interesariuszy, konkurencję czy regulacje prawne. Listę można wydłużać bądź skracać w zależności od organizacji, czasu i charakterystyki projektu. Potrzebna jest zatem osoba, która zrozumie wszystkie te elementy i je powiąże, nada odpowiedni kierunek oraz określi wartość z prowadzonych prac. Tą osoba jest właściciel produktu. Jego nadrzędnym celem jest dostarczenie jak największej wartości w jak najkrótszym czasie. Testowanie, eksperymentowanie i sprawdzanie różnych ścieżek do zwiększenia stopy zwrotu z inwestycji (ROI).

Autonomia działania

Z moich obserwacji wynika, że Scrum najskuteczniej działa tam, gdzie idea jego wdrożenia wypływa od zarządu, kluczowych interesariuszy lub jest to oddolna inicjatywa, ale realizowana przy pełnym wsparciu osób decyzyjnych. Brak tego poparcia sprawia, że wdrożenie Scruma jest nieskuteczne, bądź jego wpływ na sposób pracy organizacji jest marginalny.

Dlaczego tak się dzieje? Przede wszystkim ze względu na zaufanie lub jego brak oraz liniową, skostniałą strukturę firmy. Scrum zakłada, że cały zespół deweloperski jest kompetentny (dysponuje umiejętnościami niezbędnymi do realizacji projektu) i samoorganizujący się. Posiada dzięki temu pełną autonomię. Samodzielnie podejmuje decyzje o sposobie realizacji poszczególnych zagadnień (przy współpracy z Product Ownerem) oraz bierze pełnię odpowiedzialności za swoje decyzje. Z kolei właściciel produktu posiada niezbędną wiedzę i umiejętności do prawidłowego oszacowania ryzyka, określenia strategii rozwoju czy możliwości budowania wartości. Dostaje pełną kontrolę do podejmowania niezależnych decyzji dotyczących swojego produktu, ale w zamian dźwiga jednoosobową odpowiedzialność za jego sukces lub porażkę.

Odpowiedzialność

Sprint review, ceremonia scrumowa dotykająca najszersze grono osób, stanowi swoisty test weryfikujący poziom implementacji zasad Scruma. Gdy Product Owner traci możliwość decydowania o dalszym kierunku rozwoju produktu (np. przełożony narzuca mu swoją wizję), powinna zapalić mu się w głowie lampka ostrzegawcza. Wszyscy, dosłownie cała organizacja, muszą respektować decyzje właściciela produktu. Projekt może zostać przedterminowo zamknięty, jeśli nie rokuje sukcesu, jednak dopóki nie dojdziemy do tego punktu krytycznego, należy zostawić stery w rękach Product Ownera.

W tym momencie dochodzimy do jednego z fundamentów, a zarazem największych wyzwań z jakimi musimy się zmierzyć, kiedy wdrażamy Scrum w organizacji. Jest nim możliwość podejmowania niezależnych decyzji przez mistrza ceremonii. Właściciel produktu jest obdarzony bardzo dużą swobodą działania, lecz niesie to za sobą konsekwencje w postaci ogromnej presji. Właściciel produktu ponosi pełną odpowiedzialność za sukces lub porażkę projektu.

Taka struktura odwraca naturalny bieg zdarzeń np. liniowy, z góry na dół. Firma posiada jasno określoną strategię i cele, jednak nie implikują one konkretnych działań. Są kompasem wskazującym kierunek. Product Owner jest kapitanem , którego zadaniem jest dotarcie z załogą do określonego punktu docelowego. Musi zrobić to w jak najlepszy, najefektywniejszy i najszybszy sposób. Gdy organizacja zaczyna działać w ten sposób, możemy mówić o zdrowym wykorzystaniu Scruma w organizacji.

Kim Product Owner nie jest?

Podobno człowieka można najlepiej poznać nie po tym co akceptuje, a po tym co odrzuca ze swojego życia. Zastosujemy to i w tym wypadku. Właściciel produktu to bardzo szeroko i luźno rozumiana rola. Nie ma w tym nic złego, ponieważ jej charakter jest często uzależniony od specyfiki produktu, branży, otoczenia, konkurencji i wielu innych czynników zewnętrznych.

Na koniec podsumujmy więc, kim Product Owner nie jest.

• Product Owner to nie komitet, grupa czy zespół. To nawet nie trio czy para. To zawsze jedna osoba ponosząca pełną odpowiedzialność. Ma prawo delegować swoje zadania, ale zawsze ponosi za nie odpowiedzialność.
• Product Owner to nie kierownik projektu. Nie ma formalnego nadzoru nad zespołem deweloperów. Jego zadania mocno wykraczają poza zrealizowanie zdefiniowanych celów, ponieważ to on odpowiada za określenie i nadanie kierunku w obrębie prowadzonego produktu.
• Product Owner to nie lider zespołu. Swoje cele może osiągać poprzez komunikację i współpracę z całym zespołem scrumowym. Nie sprawuje nad nim formalnego zwierzchnictwa.
• Product Owner to nie Scrum Master. Mimo iż Scrum pozwala na łączenie pewnych ról, te akurat powinny być rozdzielone, ze względu na sprzeczne interesy.
• Product Owner to nie realizator czyjejś woli, a twórca strategii i produktu.