Po co nam ten Product Owner? (historia ilustrowana)

Zdarza się czasami, że rozmawiam z kimś, używamy tych samych wyrazów, wydaje się, że rozmawiamy o tym samym – i niespodziewanie w rozmowie pojawia się niezrozumienie lub zdumienie. Często wówczas odkrywamy, że co prawda używamy tych samych słów, ale zupełnie inaczej je rozumiemy…

Kiedy rozmawiam o wytwarzaniu oprogramowania, takie niezrozumienie często pojawia się przy terminie Właściciel Produkt. Zdarza się, że ktoś mówi „tak, mamy oczywiście właścicieli produktów” – a później okazuje się, że opisuje rolę menedżera albo kierownika projektu.

Po co nam Właściciel Produktu i czym ta osoba różni się od Kierownika Projektu? Spróbujmy to sobie narysować!

Załóżmy, że pracujemy w firmie, która wytwarza jakiś produkt informatyczny – system, który daje użytkownikom jakieś możliwości. Zacznijmy nasz rysunek od zespołu, który jest w stanie wytwarzać nasz produkt. Nie będziemy zajmować się organizacją tego zespołu. Załóżmy tylko, że zespół rozwija nasz produkt inkrementalnie – to znaczy, że możemy przestawić zespołowi wymagania zmian w produkcie, a po jakimś czasie zespół dostarczy kolejną wersję produktu – wersję, która będzie zawierała implementację tych wymagań.

Mamy również osoby, które są zainteresowane wprowadzeniem zmian lub nowych funkcjonalności do naszego produktu. Mogą być to zewnętrzni klienci lub też osoby w naszej organizacji, które reprezentują tych klientów i mają pomysły na zmiany w naszym produkcie.

Z reguły w IT mamy do czynienia z dysproporcją popytu i podaży. Chcielibyśmy wprowadzić bardzo dużo zmian, natomiast nasz zespół ma ograniczone możliwości. Stajemy przed problemem: „zbyt dużo do zrobienia, zbyt mało czasu i ludzi”. Jak możemy sobie z nim poradzić?

Z reguły pierwszym pomysłem, na który wpada organizacja, jest potraktowanie naszego zespołu deweloperskiego jako linii produkcyjnej i próba spriorytetyzowania zadań dla tego zespołu – czyli próba odpowiedniego ustawienia elementów na taśmie, która wchodzi do tego zespołu. Potrzebujemy do tego kilku dodatkowych elementów.

Po pierwsze powołujemy osobę lub grupę osób, które są odpowiedzialne za ustalenie priorytetów. Zbierają one dokumenty ze zmianami i ustalają ich kolejność.

Bardzo często chcemy wiedzieć, jak duże są nasze zmiany i ile z nich możemy mieć wdrożonych do końca roku. Dlatego prosimy zespół deweloperski i wykonanie estymat. Niestety, nie jest to bezkosztowe – szacowanie elementów oznacza oderwanie ludzi od ich bieżącej pracy.

Osoby zlecające zmiany zazwyczaj chcą jak najszybszego ich wprowadzenia. Przychodzą i zadają niegrzeczne pytania: „kiedy wreszcie moja zmiana będzie gotowa?!”. Dlatego zwykle przygotowujemy i udostępniamy im jakiś harmonogram prac.

W życiu tak jest, że rzeczy się zmieniają lub odkrywamy nowe fakty. Okazuje się, że pominęliśmy część wymagań. Albo zespół mocno pomylił się w szacowaniu. Albo zmieniły się uwarunkowania rynkowe. Czy możemy wtedy zmienić nasz plan? Jaki będzie to miało wpływ na zaplanowane już prace? Żeby dobrze odpowiedzieć na to pytanie, powołujemy nową grupę ludzi, która będzie analizowała zmiany i zezwalała (bądź nie) na ich wprowadzenie.

Mając te wszystkie elementy, z reguły chcemy je opisać. Powstaje więc dokument nazwany IT Governance albo Development Process, który opisuje, jak nasza maszyneria działa lub powinna działać.

Czasami zdarza się tak, że nasza lista rzeczy do zrobienia jest tak duża, że trudno jest nią zarządzać. Dzielimy więc tę listę na projekty – i do każdego z projektów przydzielamy kierownika, który czuwa nad wykonaniem zadań wchodzących w skład danego projektu. W tym momencie rada „Priority Board” najczęściej decyduje o projektach całych projektów. Planowanie najczęściej odbywa się na dwóch poziomach – planowanie globalne dla całej organizacji (najczęściej na zasadzie przydzielania czasu pracy do każdego z projektów) oraz wewnętrzne planowanie w każdym z projektów.

Tyle metoda klasyczna.

A co zmieni w tym rysunku wprowadzenie osoby Właściciela Produktu? Rysunek wtedy może wyglądać na przykład tak:

Przede wszystkim zniknęły nam z rysunku wszystkie komitety sterujące! To wcale nie znaczy, że muszą one zostać rozwiązane – może być tak, że one cały czas są i wspierają Właściciela Produktu. Kluczowe jest tu słowo „wspierają”, ponieważ najważniejsze decyzje podejmuje sam Właściciel. Wszystkie osoby, które chcą wprowadzenie istotnych zmian w produkcie, muszą się z nim skontaktować. To Właściciel Produktu jest jedyną osobą, która decyduje o wzięciu elementu do realizacji oraz o kolejności prac nad produktem. Żeby to zrobić, Właściciel umieszcza wszystkie zmiany na liście – a jeżeli pracujemy w Scrumie, to nazywamy tę listę Backlogiem Produktu.

Osoby pracujące w zespole deweloperskim nadal mogą szacować swoją pracę – ale teraz głównym narzędziem do szacowania oraz planowania pracy jest Backlog.

Skąd Właściciel Produktu ma wiedzieć, co i w jakiej kolejności powinno być wykonane? Służy mu do tego wizja oraz roadmapa rozwoju produktu.

Przy rozwoju dużego produktu, istnieje duże ryzyko, że właściciel zostanie zatopiony w ilości spraw do ogarnięcia oraz decyzji do podjęcia. Dlatego można podzielić Backlog Produktu na obszary i wprowadza się właścicieli tych obszarów – ale nadal pozostaje jedna osoba odpowiedzialna za całość.

W momencie rozdzielenia rozwoju systemu na obszary funkcjonalne, rekomendowane jest rozdzielenie również zespołu deweloperskiego, tak aby obszary były rozwijane przez niezależnie zespoły wytwórcze.

Nasze dwa rysunki zaczynają wyglądać dość podobnie… Spróbujmy zatem zauważyć różnice między nimi!

W lewym modelu organizacji decyzje o kierunku rozwoju produktu są rozproszone między rady nadzorcze oraz kierowników projektów. Musimy zapewnić sprawną komunikację pomiędzy nimi – bo inaczej istnieje duże ryzyko rozwoju systemu w różnych kierunkach i wprowadzania lokalnych optymalizacji.

W prawym modelu decyzje o kierunku rozwoju produktu są podejmowane przez jedną osobę. Co więcej, ta osoba jest w pełni odpowiedzialna za strategię tego rozwoju. Właściciel Produktu dąży zatem do tego, aby prace zespołu deweloperskiego były skoncentrowane na najważniejszych funkcjonalnościach. Scrum Guide opisuje to zdaniem: „Właściciel Produktu jest odpowiedzialny za maksymalizację wartości produktu i pracy Zespołu Deweloperskiego”.

Używając pewnej analogii – lewy rysunek zakłada kolektywne zarządzanie rozwojem produktu. Prawy rysunek wprowadza dyktaturę. Nawet jeżeli Właściciel Produktu deleguje część swoich uprawnień na właścicieli obszarów biznesowych, to i tak pozostaje odpowiedzialny za kierunek rozwoju produktu.

Który model rozwoju produktu jest lepszy? Tutaj wkraczamy na grząski grunt oceny poprzez pryzmat osobistych doświadczeń… Moje osobiste doświadczenie jest następujące: kiedy mamy jednego, konkretnego Właściciela Produktu, zachodzą następujące zjawiska:

• decyzje podejmowane są szybciej – jedna osoba reaguje szybciej niż komitet;
• upraszcza się ścieżka decyzyjna i zmniejsza się biurokracja;
• łatwiej jest określić granice produktu;
• łatwiej jest o zmianę kierunku prac w momencie zaistnienia nieprzewidzianych okoliczności.

Jeżeli zaczniemy czytać raporty na temat przyczyn porażek różnych projektów IT, to możemy zauważyć, że jak mantra powtarzają się tam dwa zdania: brak zaangażowania klienta oraz zmieniające się wymagania. Ustanowienie Właściciela Produktu jest bezpośrednią odpowiedzią na te problemy.

I może zmienić się jeszcze coś innego – motywacja zespołu. Jeżeli zespół pracuje nad projektem zarządzonym przez Komitet Sterujący, z reguły ludzie w zespole mają do tego komitetu stosunek mocno obojętny. Inaczej jest, kiedy zespół pracuje nad produktem, którego właścicielem jest konkretna osoba. Tym bardziej, jeżeli ta osoba przyjdzie do zespołu, usiądzie razem z nimi i powie: „słuchajcie, chciałbym wejść na rynek niemiecki, mamy już partnera i kontrakt, potrzebuję do tego funkcjonalności A, B i C”. Tym bardziej, jeżeli właściciel produktu potrafi przekazać zespołowi swój entuzjazm i wiarę w rozwój produktu. Kiedy coś budujemy, potrzebujemy kogoś, kto bardzo mocno wierzy w to, co robimy…

A jak są podejmowane najważniejsze decyzje o rozwoju Twojego produktu? Przez kolektyw czy przez dyktatora?