O korzyściach płynących z wykorzystania w naszych projektach metodyk zwinnych, pisała wcześniej Emilia w artykule „Scrum a jakość produktów w VSoft”. Natomiast w tym artykule chciałabym się skoncentrować na jednej z trzech ról wchodzących w skład zespołu Scrumowego. Product Owner, bo o nim będzie mowa, wraz ze Scrum Masterem i Developerami odpowiada za wytwarzanie produktu. No właśnie, skoro zespół Scrumowy zajmuje się wytwarzaniem produktu, to dlaczego ta metodyka pojawia się również w odniesieniu do realizacji projektów informatycznych?

Produkt vs projekt

Rozpoczynając rozważania na ten temat, warto zacząć od zrozumienia, czym jest projekt i produkt. Według definicji Project Managment Institute (PMI), projekt jest to przedsięwzięcie mające określony czas trwania – jest tymczasowe, a jego celem jest wytworzenie unikalnej usługi lub produktu.

Z przytoczonych definicji wynika, że pojęcia te nie są przeciwstawne – produkt jest wynikiem projektu. W przypadku projektów informatycznych produktem zwykle jest wytworzone w trakcie jego trwania oprogramowanie. Kiedy zatem możemy uznać, że działamy projektowo, a kiedy produktowo? Różnica polega na określeniu miary sukcesu. W ujęciu projektowym za sukces uważane jest zwykle dostarczenie produktu o określonym zakresie, w określonym czasie i w zaplanowanym budżecie. Problem pojawia się w momencie, gdy pomijana jest wartość biznesowa produktu, czyli sytuacja, w której zrealizowany zakres nie odpowiada oczekiwaniom klienta. W podejściu produktowym najważniejszym celem jest jednak stworzenie produktu, który realizuje określone potrzeby klienta lub użytkownika.

No dobrze, ale gdzie w tym wszystkim Product Owner?

Rola Product Ownera w projekcie

Czasem spotykam się ze stwierdzeniem, że Product Owner w Scrumie to taki Project Manager tylko inaczej nazwany. W zależności od projektu te dwie role mogą mieć bardziej lub mniej zbliżone zakresy odpowiedzialności i obowiązków. Co do zasady Project Manager dba o sukces projektu (kontroluje harmonogram prac, wykorzystanie budżetu itp.), natomiast Product Owner odpowiada za sukces produktu, więc troszczy się o to, żeby zrealizowany w projekcie zakres dostarczał nabywcy możliwie najwyższą wartość. W odpowiednich warunkach te dwie role mogą z powodzeniem współpracować w obszarze jednego projektu.

Warto zauważyć, że nie wszystkie osoby związane realizacją projektu są częścią zespołu Scrumowego, który jest bezpośrednio zaangażowany w wytwarzanie konkretnego produktu. Tworzenie oprogramowania jest częścią całego projektu, który obejmuje również inne działania, np. sprzedaż, marketing, wdrożenia czy analizę.

Skupiając się na temacie wytwarzania produktu – niestety samo „techniczne” wdrożenie Scruma, praca w iteracjach czy codzienne spotkanie zespołu nie gwarantują, że produkt będzie bardziej wartościowy. Poza określeniem jak pracować potrzebna jest wiedza co robić i które elementy systemu są najbardziej wartościowe z punktu widzenia biznesu. Za ten obszar odpowiada w Scrumie właśnie Product Owner.

Odpowiedzialność Product Ownera

W Scrumie rolę Product Ownera pełni zawsze jedna osoba. Warto wspomnieć, że może, ale nie musi to być dedykowane stanowisko w strukturze organizacji – istotny jest zakres zadań i odpowiedzialności danego pracownika. Może on delegować zadania, jednak zawsze ponosi za nie pełną odpowiedzialność.

Główną odpowiedzialnością Product Ownera jest określenie co i dlaczego robimy. Natomiast do Developerów należy decyzja, w jaki sposób określony zakres zostanie zrealizowany.

Następujące zadania są kluczowe w pracy Product Ownera:

1. 1. Określanie celów i wizji rozwoju produktu. Product Owner musi mieć wiedzę na temat samego produktu, ale również znać biznes, klientów i rynek, na którym działa. W zależności od projektu może mieć mniejszą bądź większą swobodę w kreowaniu produktu.
   2. Zarządzanie backlogiem produktu, czyli listą zadań do wykonania przez zespół. Każde zadanie realizuje określony zakres biznesowy i zawiera opis zachowania systemu. Product Owner dba o to, żeby lista zadań była stale aktualna, uwzględniając zmieniające się potrzeby klienta. Backlog produktu jest swego rodzaju planem projektu. Istotne jest, że Product Owner nie wprowadza opisu technicznego realizacji – to zadanie i odpowiedzialność Developerów.
   3. Ustalanie priorytetów Dysponując określonym czasem i budżetem, Product Owner musi tak ułożyć zadania, aby zespół zrealizował najbardziej wartościowy, z punktu widzenia klienta, zakres. Wyznaczone priorytety są konsultowane z zespołem, natomiast to Product Owner podejmuje ostateczne decyzje i ponosi za nie odpowiedzialność.
   4. Nadzorowanie i ocena faktycznego postępu realizacji produktu. Product Owner weryfikuje, czy zrealizowane zadania faktycznie realizują określoną potrzebę biznesową. Nie kontroluje i nie ocenia ilości zrealizowanych zadań. Nie jest kierownikiem zespołu i nie sprawuje nad nim formalnego nadzoru.
   5. Komunikowanie się z interesariuszami – w zależności od rodzaju projektu mogą to być klienci, menedżerowie biznesowi, inwestorzy. Product Owner jest również w stałym kontakcie z Developerami, by upewniać się, że realizowane funkcjonalności i zadania są jasne, zrozumiałe i zgodne z celami biznesowymi. Wszelkie pojawiające się wątpliwości muszą być wyjaśniane na bieżąco.

Potrzebny czy nie?

Zarządzanie produktem nie jest niczym nowym i występującym wyłącznie w Scrumie. Na wybór metodyki prowadzenia projektów wpływa wiele czynników, które powodują, że rola i zakres odpowiedzialności kierownika/opiekuna/właściciela produktu może się nieco różnić.

Jednak niezależnie od wybranej metody, nasz produkt będzie atrakcyjny tylko wtedy, gdy skoncentrujemy się na jego użyteczności i dostarczanej wartości biznesowej. Potrzebna jest więc osoba, która odpowiednio pokieruje rozwojem tworzonego oprogramowania tak, aby dostarczyć produkt, który najlepiej zaspokaja potrzebny klienta lub użytkownika. W Scrumie taką funkcję pełni Product Owner.