Idealny Product Owner a rzeczywistość

Product Owner powinien posiadać wiele różnych umiejętności, kompetencji i cech często przeciwstawnych. Z jednej strony konieczność kreowania wizji produktu i  widzenia tzw. big picture, a z drugiej umiejętność wejścia w szczegóły i ciągła dostępność dla zespołu.

To wszystko składa się na to, że rolę Product Ownera czasem trudno jest od razu zrozumieć i właściwie zdefiniować przy transformacjach agilowych . Dlatego nierzadko Właściciel Produktu ma bardzo ograniczone właścicielstwo i brakuje mu decyzyjności.

Bywa też nie do końca wiadomo za jaki produkt dany Product Owner odpowiada.

Zetknęłam się z różnorakimi ograniczeniami w pracy Product Ownera, zarówno w software house, jak i w korporacji. Chciałabym opowiedzieć Ci o tym, jak poradziłam sobie w sytuacji niezgodności roli jaką mi wyznaczono w organizacji, w porównaniu z książkową nazwą i opisem stanowiska. 

Być PO w korporacji

Zobaczmy zatem jak poszczególne odpowiedzialności PO wyglądają w korporacji.

Zacznijmy od wizji produktu, kto się nią zajmuje, jeśli produkt jest rozwijany w korporacji, w sytuacji, gdy firma ma jeden złożony produkt i wiele zespołów? W korporacji, w której pracowałam, wizja była trzymana na poziomie zarządu, zaś Product Ownerzy mieli bardzo ograniczony na wpływ na nią.

Trochę lepiej sytuacja wyglądała, jeśli chodzi o roadmapę. Jako Product Owner miałam wpływ na planowanie rozwoju produktu. Zwłaszcza na taktycznym czy operacyjnym poziomie. Znając prędkość zespołu mogłam wspierać planowanie przyszłych przyrostów czy wdrożeń, ale ustalanie strategicznych celów produktu było zwykle robione przez kogoś innego. Jako Product Owner byłam raczej odpowiedzialna za realizację tychże celów.

Inaczej sprawa wyglądała, jeśli chodzi o współpracę z zespołem. To był obszar, gdzie miałam największy wpływ. Współpracowałam ściśle z zespołem i moją odpowiedzialnością było zaopatrzyć zespół we wszelką możliwą wiedzę biznesową, aby rozwijać produkt efektywnie. Moja postawa przekładała się bezpośrednio na poziom motywacji zespołu.

Jako PO miałam kontakt ze wszystkimi, albo przynajmniej większością interesariuszy, choć bardzo często nie było to ode mnie wymagane. Najczęściej tylko najbardziej zaangażowani interesariusze bezpośrednio pracowali z Product Ownerami i z zespołami.

PO w korporacji przy odrobinie dobrej woli może mieć kontakt z użytkownikami końcowymi, ale bardzo często ktoś inny za to odpowiada. Rozbudowane działy UX czy Market Research bywają bardzo daleko od Działu Produktu. Warto zadbać o kontakt z tymi działami i wykorzystać tą współpracę do wspierania swojej wiedzy o użytkownikach. Jednak nie można się do tego ograniczać. Swoje rozeznanie potrzeb użytkowników w pierwszej kolejności trzeba czerpać z kontaktów z użytkownikami.

Budżet był zwykle ustalany przez menedżerów wyższego szczebla i nie miałam na niego wpływu.

Co zatem zrobić, gdy okazuje się, że Twoje stanowisko tylko z nazwy jest związane z właścicielstwem produktu? Można pogodzić się z rolą backlog menedżera, ale można też spróbować krok po kroku zmieniać tę sytuację.

Ja zrobiłam to tak…

Historia Product Owner w korporacji

Moje początki

Słuchając o roli Product Ownera w Scrumie na moim pierwszym szkoleniu z zarządzania produktami, przeszło mi przez głowę: „przecież to jest nie do ogarnięcia dla jednej osoby”

Gdy jakiś czas po tym szkoleniu okazało się, że mam zostać Product Ownerem miałam mieszane uczucia, poczułam najpierw wewnętrzny niepokój, nie wiedziałam czy poradzę sobie w tej roli. Bardzo szybko niepokój przekształcił się w radość z nowego wyzwania zawodowego. A po jakimś czasie… poczułam, że coś jest nie tak. Okazało się, że co innego było na szkoleniu, a inaczej rola ta została wdrożona w organizacji, w której pracowałam.

W momencie, w którym w pełni zdałam sobie z tego sprawę, od ponad dwóch lat, pracowałam w największej firmie zajmującej się płatnościami w internecie w Europie Środkowo- Wschodniej. Lubiłam swoją firmę, moich współpracowników i domenę płatności, w której działaliśmy. Product Ownerem zostałam mianowana rok wcześniej, kiedy transformacja adżajlowa się zaczęła i tyle czasu w pełni wystarczyło, żeby zdać sobie sprawę z ograniczeń mojej roli.

Firma miała jeden produkt i około piętnastu zespołów i tyleż osób tytułowanych Product Ownerami. Mój ówczesny projekt dobiegał końcowi, a ja wciąż zastanawiałam się, czy mogę mieć mój “własny” produkt w tej organizacji, taki, za który odpowiadałabym jak modelowy Product Owner. Od początku mojej pracy z produktem pracowałam z wspaniałym produktowcem – moim bezpośrednim szefem oraz cenionymi Agile coachami, więc czułam, że jestem gotowa na to wyzwanie i mam odpowiednie wsparcie. Zaczęłam zatem szukać dla siebie produktu.

No i znalazłam, tyle że… proces. Częścią projektu, który właśnie miałam skończyć, był przegląd wszystkich procesów w organizacji. W ten sposób odkryłam, że jeden z najistotniejszych procesów w firmie jest daleki od ideału. Nasi klienci musieli czekać nawet kilka tygodni, żeby zostać naszymi klientami, a proces nawiązywania współpracy wspierały cztery zespoły z bardzo rozproszoną odpowiedzialnością.

Zaczęłam od postawienia sobie pytania, czy proces może być produktem. Po przemyśleniu tematu i konsultacji z moimi coachami, postanowiłam spróbować.

Poszukiwania wsparcia

W dużych organizacjach są duże możliwości, wielkie budżety i inspirujący klienci, ale najpierw trzeba mieć odwagę i determinację, żeby wziąć odpowiedzialność za produkt, który można i chce się rozwijać. Bardzo często trzeba budować koalicję wokół pomysłu, czy idei. Trzeba szukać wsparcia interesariuszy, aby uzyskać zielone światło na drodze do celu. Tak też było w moim przypadku. Zaczęłam od tego, żeby zidentyfikować osoby wystarczająco wpływowe, żeby mnie wesprzeć, no i jednocześnie są zainteresowane zmianami, które chciałam wdrożyć.

Jeden z moich interesariuszy miał biuro w innym mieście i nie miałam zbyt wielu okazji, żeby go spotkać, więc wykorzystałam tę, która się nadarzyła. Zdarzyło się, że byłam w tamtym biurze, więc gdy zauważyłam, że jest on w swoim pokoju, po prostu zapukałam i weszłam. Wyglądał na nieco zdziwionego, ale był wystarczająco miły, żeby pozwolić mi powiedzieć z czym przychodzę. Wykorzystałam ten czas dobrze i po kilku minutach, wiedziałam, że mam wsparcie.

Innego dyrektora „zwerbowałam” podczas Christmas Party.

Myślę, że obok dobrego przygotowania do tych rozmów bardzo pomogła mi prosta miara, którą byłam w stanie zobrazować swoją wizję. Mówiłam o skróceniu czasu nawiązywania współpracy z kilku tygodni do kilkunastu minut, czy jednego dnia licząc wszystkie formalności.

Tym samym przy poparciu również mojego szefa dostałam zielone światło i mogła skupić się na zwykłej produktowej pracy.

Współpraca z użytkownikami

Z perspektywy czasu mogę powiedzieć, że w mojej pracy nad usprawnieniem procesu najwięcej wniosła współpraca z użytkownikami końcowymi. Dzięki tej współpracy zaoszczędziliśmy sporo czasu, wysiłku i co za tym idzie pieniędzy. Podam przykład – wśród osób wspierających proces wewnątrz organizacji panowało przekonanie, że bardzo uciążliwe jest dla użytkownika wprowadzanie wielu danych, o które go prosiliśmy.

Zredukowaliśmy więc tę listę do minimum, ale ze względu na wymagania prawne wiele musiało zostać. Wraz z ekspertem UX wymyśliliśmy rozwiązanie, że system utworzy użytkownikowi konto już po wprowadzeniu podstawowych danych a pozostałe dane użytkownik będzie mógł uzupełnić później. Przygotowaliśmy klikalne makiety i ruszyliśmy na spotkania z użytkownikami. Jakież było nasze zdziwienie, gdy okazało się, że większość z nich nie dostrzega większego problemu w konieczności podawania danych, a rozwiązanie, które zaproponowaliśmy w ogóle nie wzbudza entuzjazmu. Dzięki temu zaoszczędziliśmy kilka sprintów pracy i mogliśmy się skupić w pierwszej kolejności na usunięciu większych niedogodności użytkowników.

Moja rola

Po rozpoczęciu pracy nad własnym produktem (procesem) zakres mojej odpowiedzialności znacząco się zmienił. To ja kształtowałam przy udziale moich interesariuszy wizję produktu i roadmapę, wiedziałam, co chcę osiągnąć i z każdym sprintem przybliżałam się do celu. Również w organizacji zostałam rozpoznana jako osoba , która odpowiada za ten konkretny proces i metryki z nim związane. Konsekwentnie pracowałam z interesariuszami, użytkownikami końcowymi, oraz z moim zespołem. Miałam to szczęście, że pracowałam z bardzo dobrym i zaangażowanym zespołem, ale dzięki temu, że zakres naszej odpowiedzialności zaczął obejmować coś więcej niż dowiezienie sprintu, mogę powiedzieć, że zespół był prawdziwie zaangażowany w rozwój produktu, a nie tylko dostarczanie i rozwój oprogramowania.

Wyniki

Poza zmianami w pracy mojej i mojego zespołu, zaszły również realne zmiany w procesie, którym się zajmowaliśmy – odnieśliśmy sukces także patrząc z perspektywy firmy. Czas procesu spadł z kilku tygodniu do nawet 10 minut dla najbardziej krytycznej części procesu, co znalazło też przełożenie na pieniądze. Firma zaczęła zarabiać wcześniej. Proces się uprościł i mógł być obsługiwany przez jeden zespół, zamiast dotychczasowych czterech. Pozostałe osoby mogły skupić się na innych obowiązkach. No i najważniejsze proces stał się łatwiejszy i bardziej przyjazny dla użytkowników końcowych. Ponadto firma zyskała bardzo zaangażowany zespół scrumowy.

Podsumowanie

Jeżeli dasz sobie nieco czasu, masz odpowiednio dużo motywacji i energii (no i trochę szczęścia), również w korporacji możesz się rozwijać w pożądanym kierunku.

Oczywiście każde okoliczności są inne i trzeba odnaleźć własną drogę, ale warto poszukać i nie zniechęcać się po pierwszym niepowodzeniu. Właściciel Produktu to nie nazwa stanowiska, to raczej postawa, którą należy pielęgnować.
W kolejnym artykule  Marta Kossowska opowie o byciu Product Ownerem w software house i pokusi się o wyciągnięcie wniosków na temat tego, jaka postawa pomaga być dobrym Product Ownerem niezależnie od organizacji. Stay tuned.