Product Owner – trudny wybór

Kim jest Product Owner, jakie ma zadania, role, gdzie leży jego odpowiedzialność

Przez ostatnich kilka lat mogliśmy obserwować pewną rewolucję przetaczającą się powoli poprzez świat IT. Z czasem dotknęła niemal wszystkich firm wytwarzających oprogramowanie. Mowa oczywiście o Agile i Lean Software Development – czyli tak zwanych “zwinnych” i “szczupłych” podejściach do wytwarzania oprogramowania, które z każdą chwilą stają się coraz bardziej popularne. Jedną z najczęściej stosowanych współcześnie […]

ProductOwnerTelephone

Przez ostatnich kilka lat mogliśmy obserwować pewną rewolucję przetaczającą się powoli poprzez świat IT. Z czasem dotknęła niemal wszystkich firm wytwarzających oprogramowanie. Mowa oczywiście o Agile i Lean Software Development – czyli tak zwanych “zwinnych” i “szczupłych” podejściach do wytwarzania oprogramowania, które z każdą chwilą stają się coraz bardziej popularne. Jedną z najczęściej stosowanych współcześnie metod wytwarzania oprogramowania stał się Scrum – inkrementalny i iteracyjny zbiór łatwych do zrozumienia i, jak się okazuje, trudnych do w pełni efektywnego zastosowania w praktyce zasad.

Scrum wyróżnia trzy podstawowe role w procesie wytwarzania oprogramowania: Developer – czyli osoba dostarczająca wartość, Scrum Master – ktoś w rodzaju facylitatora i lidera odpowiedzialnego za prawidłową implementację Scrum w zespole i organizacji oraz Product Owner, któremu chciałbym poświęcić w tym artykule więcej miejsca.

Product Owner, jak nazwa wskazuje, to osoba odpowiedzialna za produkt – efekt końcowy pracy zespołu scrumowego. Jest to ktoś, kto wyznacza kierunek i kształtuje wizję wytwarzanego produktu

Jak wiadomo jednym z najbardziej kosztownych zasobów, jakie mamy do dyspozycji jest czas. Wydawać by się mogło, że często osoby wykorzystujące klasyczne – nie-zwinne podejście do zarządzania projektami zapominają o tym. Dodatkowa praca kreatywna (a wytwarzanie oprogramowania z pewnością do tej kategorii możemy zaliczyć) nie jest liniowa, a co za tym idzie – zwiększając ilość osób zaangażowanych w projekt, od pewnego momentu wcale nie skracamy czasu potrzebnego na dostarczenie finalnej wersji produktu. Dlatego też głównym zadaniem Product Ownera jest ustalanie kolejności, w jakiej wymagania będą realizowane. Wymagania te znajdują się na “backlogu produktu” (ang. Product Backlog).

Manager managerowi nie równy…

Pracujac jako niezależny Agile Coach, jestem zatrudniany przez organizacje, które borykają się z różnymi problemami podczas prób transformacji organizacji w kierunku Agile czy też implementacji Scrum w kontekście ich produktów i procesów. Częstym problem, jaki zauważam pojawiając się u klienta jest niekoniecznie najlepszy dobór osób do poszczególnych ról. Przeważnie ktoś, kto wpadł na pomysł takiej organizacji przeczytał, że Scrum Master jest rolą managerską i na tej podstawie na Scrum Masterów nominował dotychczasowych Project Managerów, a skoro Product Owner odpowiedzialny jest za wymagania, to najlepiej do tej roli nadają się analitycy. Tak, Scrum Master to manager, niemniej jednak słowo ‘manager’ ma kilka różnych znaczeń, które różnią się od siebie w zależności od kontekstu kulturowego, w którym są używane. W naszej europejskiej kulturze przyjęło się, że manager to po prostu przełożony – zwierzchnik, mający (iluzoryczną) władzę nad swoimi podopiecznymi. W kulturze zachodniej, będącej kolebką Scrum i Agile, manager to ktoś, kto zarządza, ale niekoniecznie ludźmi. Mamy na przykład managera konfiguracji (ang. Configuration Manager) czy managera wydań (ang. Release Manager) – te role pokazują, że można być managerem, nie zarządzając ludźmi. Scrum Master jest managerem procesu, a nie zespołu – to jedno z najczęstszych nieporozumień, z jakim się spotykam w swojej pracy1.

Product Owner to “właściciel” produktu

– i nie chodzi tutaj o kogoś, kto faktycznie wydaje swoje pieniądze na wytworzenie danego produktu (chociaż tak zapewne byłoby idealnie), ponieważ takie osoby przeważnie nie mają czasu zajmować się zarządzaniem produkcją. Właściciel produktu powinien czuć się odpowiedzialny za produkt, powinien czuć się odpowiedzialny za sukces całego przedsięwzięcia. Kto, jeśli właśnie nie Project Manager, jest w klasycznych metodach wytwarzania oprogramowania odpowiedzialny za sukces projektu? Dlatego też podczas transformacji organizacji w kierunku Agile zalecam rozważenie poszukiwań odpowiednich Product Ownerów wśród dotychczasowych managerów.

Do pełnienia tej roli potrzebne jest duże doświadczenie w zakresie zarządzania oraz wiedza na temat produktów

Przeglądając oferty pracy w IT, coraz częściej pojawiają się ogłoszenia dotyczące zatrudnienia Scrum Masterów (niestety nadal jest to często “Scrum Master/Project Manager”, co oczywiście świadczy tylko o tym, że ogłaszająca organizacja naprawdę potrzebuje dobrych Scrum Masterów, więc poszukiwania nie są bezzasadne, a zatrudniona osoba nie będzie się nudzić). Natomiast dużo rzadziej pojawiają się ogłoszenia dotyczące poszukiwań Product Ownerów. Wynika to zapewne właśnie z tego, że Product Owner musi mieć głęboką wiedzę na temat danego produktu i rynku, na którym ten produkt ma być docelowo sprzedawany. Jeśli jednak jedyną osobą kształtującą wizję rozwoju produktu w organizacji i mającą w tej kwestii moc decyzyjną jest prezes (czy też dyrektor), nie oznacza to, że to właśnie ta osoba powinna być Product Ownerem. Jak wspomniałem powyżej, osoby zajmujące takie stanowiska przeważnie nie mają czasu, by współpracować codziennie z zespołem. Należy pamiętać, że Product Owner to praca na pełen etat, która w żadnym wypadku nie może ograniczać się jedynie do dwóch spotkań (Sprint Planning i Spritn Review) w czasie iteracji.

Co zatem zrobić w sytuacji, gdy jedyne osoby posiadające moc decyzyjną co do rozwoju produktu de facto nie mają czasu, by pełnić rolę Product Ownera?

W klasycznych metodach wytwarzania oprogramowania mieliśmy Project Managera, na którego delegowana była odpowiedzialność za dowiezienie projektu na czas. Tutaj podobną rolę pełni Product Owner, który zamiast skupiać się na deadlineach skupia się na maksymalizacji wartości funkcjonalności dostarczanych w kolejnych iteracjach.

Pozostaje zatem pytanie: co w takim razie z decyzyjnością i osobami decyzyjnymi, których przecież może być wiecej niż jedna? Takie osoby to interesariusze (ang. Stakeholders). Interesariusze są w ciągłym kontakcie z Product Ownerem i to oni podejmują decyzje o tym, co ma być zrobione. Product Owner decyduje lub pomaga decydować w kwestii tego, kiedy dana funkcjonalność zostanie dostarczona, bo przecież przeważnie wszystko ma być na wczoraj2. Interesurisze to nie tylko osoby decyzyjne w organizacji. Specyficznymi interesariuszami są też na przykład przepisy i normy prawne czy też wymogi bezpieczeństwa. A także oczywiście interesariuszami są też użytkownicy naszego systemu jako ogół.

Podsumowując, Product Owner to osoba odpowiedzialna za zbieranie wymagań interesariuszy (sam może być jednym z nich) i porządkowanie ich w takiej kolejności, by maksymalizować dostarczaną przez zespół scrumowy wartość biznesową. Dlatego tak istotne jest powierzenie tej roli odpowiedniej osobie, posiadającej wystarczającą wiedzę i przynajmniej minimalną moc decyzyjną.

1 Szerzej opisałem ten temat w swojej książce “Mity i Problemy w Agile”: http://leanpub.com/problemywagile/

2 Więcej na ten temat pisałem w książce “Agile Transformacje”, gdzie szczegółowo opisałem przykład, w którym zmieniając Project Managera w Product Ownera udało się nam bardzo wiele osiągnąć. https://leanpub.com/agile-transformacje/

Autor artykułu prowadzi ekspercki blog.testowka.pl, na którym pisze o swoim subiektywnym spojrzeniu na jakość oprogramowania oraz jest współzałożycielem pragmaticcoders.com, gdzie testuje to, o czym napisze;)