Jak wygląda dzień pracy Product Ownera?

Jak wygląda „typowy dzień Product Ownera”?- to pytanie było jednym z częstszych na moim Instragramie! Z odpowiedzią mam jednak problem, bo takich „typowych dni” mogłabym wymienić kilka, w zależności od tego, na jakim etapie znajduje się projekt. Często to powtarzam, ale w zawodzie Product Ownerna jest mało czasu na nudę! Wszystko dzieje się w szybkim tempie i dynamicznie się zmienia. Mimo to, w tym artykule przedstawię Ci kilka etapów, które mogą wpływać na pewną (kontrolowaną) rutynę w życiu PO!

Jak wygląda dzień Product Ownera, zanim zacznie się development?

Zanim zacznie się development musimy odkryć potrzebę biznesową i określić sposób jej zaspokojenia. W tym okresie typowy dzień Product Owner polega na spędzaniu czasu na rozmowach z interesariuszami, warsztatach wymagań, researchu itp. Godziny pracy podzielone są mniej więcej pół na pół między rozmowy z interesariuszami a pracą analityczną. Jej celem jest określenie wysokopoziomowych wymagań funkcjonalnych i niefunkcjonalnych.  Należy zaprojektować odpowiednie funkcjonalności przy równoczesnym uwzględnieniu środowiska biznesowego klienta (trzeba np. zaprojektować architekturę, która będzie odpowiednio wydajna). Ta faza trwa raczej tygodnie niż miesiące. 

Jak wygląda dzień Product Ownera, gdy trwa development?

Tutaj spędzamy najwięcej czasu jako zespoły IT – zdecydowanie miesiące, a czasem lata. Bez względu na to, czy pracujemy zwinnie, czy też nie.

Poranek

W tym czasie moje poranki są dosyć stałe, bo zaczynam pracę zazwyczaj wcześniej niż reszta zespołu. I nie startuję od niczego trudnego, a od serii małych zadań na rozgrzewkę. Sprawdzam maile i wiadomości na komunikatorach. Następnie doglądam tego, co zostało dowiezione poprzedniego dnia. Przeglądam też zgłoszone bugi i robię listę zadań na dany dzień. Nie siadam w tym czasie do ważnych zadań, bo najpierw muszę się zorientować, czy nie ma nic pilniejszego, co wymaga mojej uwagi.

Później odbywa się ‘daily’ – codzienne spotkanie całego zespołu, podczas którego jego członkowie przedstawiają to, co zostało zrobione, określają swoje plany na bieżący dzień oraz mówią o swoich problemach. Daily powinno trwać około 15 min, ale ponieważ pracujemy zdalnie „pozwalamy sobie” na dłuższe spotkanie, żeby czasem pożartować, albo pogadać o pierdołach  

MIT – Most Important Task

Po daily zazwyczaj siadam do najważniejszego zadania dnia. Zazwyczaj jest nim tworzenie specyfikacji — mam w backlogu całą kolejkę wymagań, które wymagają analizy, doprecyzowania i napisania kryteriów akceptacji. 

Czasem, jeżeli jestem w miarę na bieżąco z backlogiem (celuję w 2 sprinty do przodu) moim MITem będzie stworzenie lub aktualizacja jakiejś checklisty projektowej (o cheklistach możesz więcej przeczytać w artykule Organizacja dnia pracy Product Ownera). 

Innym MITem może być coś, co przyszło w mailach lub na komunikatorach. Pracuję w duchu inbox zero — moje sprawdzanie poczty nie polega na odpisywaniu na każdego maila, a planowanie tych, które wymagają więcej niż 2 minut mojego zaangażowania (polecam!).

Na koniec sprintu czy miesiąca MITem będzie zamknięcie okresu. Mam na to osobne checklisty, żeby zadbać o jakość backlogu, dokumentacji oraz checklist (tak, mam checklistę o checklistach! ).

Spotkania

W ciągu dnia zazwyczaj wypada co najmniej jedno ze spotkań projektowych. Poza takimi, które potrzebne są ad’hoc do rozwiązania jakiegoś problemu, mamy zaplanowane spotkania:

• refinementowe, na których omawiamy wymagania całym zespołem, rozkładamy je na czynniki pierwsze, szukamy ewentualnych braków, problemów z implementacją wymagań, a w pozytywnym scenariuszu estymujemy implementację
• retro, a więc spotkanie po zakończeniu sprintu, żeby zespołowo obgadać, co poszło dobrze, co poszło źle oraz co i jak można zrobić lepiej
• spotkania ze sponsorem — na obgadanie przyszłych implementacji, na potwierdzenie przygotowanej specyfikacji, na planowanie priorytetów

Jak wygląda typowy dzień Product Ownera, gdy projekt jest w fazie odbioru?

Czas, gdy kończy się development i projekt ma być ostatecznie oddany klientowi, jest jednym z najbardziej stresujących momentów trwania projektu. Bez względu na to ile czasu poświęciliśmy na rozmowy i analizy w czasie pracy, ile “demowaliśmy” w czasie projektu, to właśnie na tym etapie okazuje się, jak bardzo nie dogadaliśmy się w niektórych kwestiach. Jest to spowodowane nieuchronnością zamykania projektu, bo wtedy interesariusze po stronie klienta są zainteresowani tym, żeby wszystko jeszcze 5 razy sprawdzić. 

Dobrze się na to przygotować. W tym czasie najwięcej czasu spędzam na analizie zgłoszeń, jakie przychodzą od klienta. Nie chodzi o to, żeby każde „odbić” i powiedzieć „to nie jest bug, a tego nie było w zakresie”. Zawsze zależy mi na tym, by realnie pomóc klientowi dowieźć wartość biznesową. Często rzetelna analiza i rozmowa mogą uświadomić klientowi, że niektóre zgłoszenia wcale nie są krytyczne. Choć czasem okazuje się, że to my musimy wyjść klientowi naprzeciw, żeby można było zamknąć projekt z sukcesem. Tak czy inaczej, umiejętność zarządzania konfliktem i emocjami u rozmówców (i u siebie) oraz rzetelna sprawna komunikacja, są w tym czasie kluczowymi umiejętnościami. 

Nie ma stałego harmonogramu dnia

To, co opisałam to raczej zestaw wydarzeń, jakie mają miejsce w ciągu dnia i tygodnia, niż ścisły harmonogram dnia. Nie da się takiego opisać, bo jak już pisałam we wstępie praca Product Ownera jest bardzo dynamiczna. 

Nie znam projektu, w którym po daily następuje 6h głębokiej pracy każdego z członków zespołu. Zazwyczaj wielokrotnie przecinamy się z zespołem czy to a’propo bugów, czy doprecyzowanie wymagań itp. 

Podobnie z klientem na etapie odbioru — staram się być cały dzień „pod telefonem” tak, żeby wszelkie wątpliwości rozwiązywać od razu i to najlepiej na spotkaniach.

Cały czas trzeba mieć z tyłu głowy, że to my jesteśmy w pełni odpowiedzialni za komunikację z klientem i zespołem, a więc to od nas w znacznym stopniu zależy sukces projektu. 

Brak wielu „typowych” dni Product Ownera, a co za tym rutyny to dla mnie duża zaleta. Lubię swoją pracę właśnie za tą dynamikę. Nigdy się nie nudzę, bo mam bardzo różnorodne zadania do wykonania, a rozwiązywanie problemów zawsze mnie satysfakcjonowało!