Czy zastanawiałe(a)ś się kiedykolwiek jak opowiedzieć osobie niezwiązanej z IT czym właściwie zajmuje się Product Owner? Często spotykam się z pytaniami o mój zakres obowiązków nawet od osób pracujących w firmach technologicznych. Przecież PO nie jest ani programistą, ani UX designerem, ani analitykiem, ani marketingowcem. Co w takim razie robi? Jak wygląda dzień z życia Product Ownera? Wyjaśnię to na własnym przykładzie.
Pracuję jako PO aplikacji mobilnej i współpracuję z dwoma zespołami iOS oraz Android. Każdy składa się z programistów, UX/UI designera oraz QA. W artykule używam również kilku charakterystycznych zwrotów dotyczących Scruma, gorąco zachęcam Cię do przeczytania najpierw krótkiego wprowadzenia, jeżeli jesteś osobą początkującą.
Mój dzień
Jest poniedziałek. Wraz z zespołem iOS jesteśmy w środku sprintu. Przygotowujemy się do wdrożenia aplikacji w wersji 2.0 pod koniec tygodnia.
Zespół Androidowy kończy właśnie sprint, planowanie mamy w środę – tym razem nie będzie wdrożenia nowej wersji aplikacji. Funkcjonalność, nad którą pracujemy, nie jest jeszcze gotowa.
8:00
Dzień zaczynam od kawy i przeglądu maili. Grafik podesłał screeny do App Store. Przeglądam i spisuję uwagi. Przypominam, że potrzebujemy jeszcze grafiki na iPada, bo od tej wersji aplikacja będzie dostępna także na te urządzenia.
W skrzynce jest jeszcze kilka maili wymagających szybkiej reakcji, więc odpisuję od razu. Te wymagające większej atencji zostawiam nieprzeczytane, wrócę do nich później.
Przeglądam kalendarz. Dzisiaj czeka mnie refinement z zespołem Androidowym oraz spotkanie z zespołem marketingowym. Spisuję punkty, które musimy poruszyć na każdym ze spotkań.
9:00
Dziś nie mam do zrobienia niczego naglącego, więc pozwalam sobie na przejrzenie nowinek ze świata technologii. Więcej uwagi poświęcam artykułom dotyczącym tematów mobilnych – jako PO muszę być na bieżąco.
Po ciekawej lekturze przeglądam statystyki produktu. Ilu nowych użytkowników się pojawiło, czy jest poprawa retencji, czy są nowe konwersje… Sprawdzam także czy użytkownicy korzystają z nowej funkcjonalności, którą niedawno wdrożyliśmy. Na pewno managerowie na jutrzejszym spotkaniu statusowym będą o to pytać.
10:00
Wchodzę na stronę naszej wewnętrznej Wikipedii, gdzie znajduje się przygotowana przeze mnie roadmapa aplikacji. Sprawdzam czy wszystko jest aktualne. Mamy małe opóźnienie z dostarczeniem treści od copywritera, więc szybko uaktualniam status i daty.
Wracam do nieprzeczytanych maili. Szefowa działu marketingu prosi mnie o podsumowanie zmian w nowej wersji produktu na iOS. Zabieram się do napisania obszernego maila.
10:30
Stand-up z zespołem androidowym. Każdy opowiada, czym zajmował się wczoraj oraz dzieli się tym, co będzie robił w dniu dzisiejszym. Deweloperzy sygnalizują bloker, gdyż nie wiedzą jak nowa funkcjonalność powinna działać w jednym z przypadków brzegowych. Wspólnie zastanawiamy się jakie są możliwości, następnie podejmuję decyzję dotyczącą rozwiązania i po stand-upie dopisuję komentarz w odpowiednim zadaniu w JIRa.
11:00
Stand-up z zespołem iOS. Przygotowujemy się do wydania, więc poza regularnym stand-upem przechodzimy przez wszystkie punkty, które powinny być zakończone przed upublicznieniem aplikacji. Po mojej stronie zostaje jeszcze zlecenie utworzenia nowych grafik na strony firmowe opisujące i promujące nasz produkt, a następnie zadbanie o ich aktualizację.
11:30
Przeglądam JIRĘ, aby przygotować się do refinementu. Zastanawiam się, które zadania powinniśmy podjąć w kolejnym sprincie. Te najistotniejsze przerzucam na górę backlogu. Dodaję dwa zadania, o których nie pomyślałam wcześniej i opisuję do nich User Stories.
12:00 – 12:30
Obiad – zbieramy ekipę chętnych i głodnych, i wspólnie udajemy się do pobliskiego lunch baru.
12:30
Ostatni rzut oka na schemat działania nowych funkcjonalności do aplikacji androidowej, nad którymi pracowałam w piątek. Sprawdzam czy na pewno niczego nie pominęłam i podpinam linki do diagramów do odpowiednich zadań w JIRA.
13:00
Refinement – omawiamy kilka zadań, które znajdą się w kolejnym sprincie, idąc od góry backlogu. Jak zwykle programiści zadają masę przydatnych pytań oraz wskazują przypadki brzegowe, o których nie pomyślałam. Wspólnie szukamy rozwiązań i odpowiedzi oraz notujemy je w odpowiednich zadaniach w JIRA. Niektóre z zadań rozbijamy na mniejsze, lub dodajemy taski czysto technologiczne, niezbędne do realizacji historyjki.
Część zadań nie ma jeszcze designów. Wraz z UI, który również bierze udział spotkaniu, omawiamy wstępne rozwiązania i umawiamy się, że przed planningiem projekty graficzne będą gotowe.
Gdy czas spotkania się kończy mamy rozłożone na czynniki pierwsze około 7 User Stories. Tyle powinno wystarczyć, aby wypełnić kolejny sprint.
14:00
Spotkanie z zespołem marketingowym – sprawdzamy czy wszystkie punkty niezbędne do releasu na iOS mamy pod kontrolą. Przeglądamy raporty konwersji oraz zastanawiamy się nad strategią optymalizacji opisu aplikacji w App Store i Google Play wraz z przedstawicielem teamu odpowiedzialnego za ASO (App Store Optimization). Ostatecznie decydujemy się na przeprowadzenie kilku testów A/B w Google Play.
15:00
Nasz QA przeprowadzający ostatnie testy regresyjne na RC iOS znajduje dość poważny błąd. Wspólnie z programistami omawiamy jaki wpływ ma na projekt i jak wiele osób może się na niego natknąć. Naprawa błędu nie wydaje się bardzo czasochłonna, więc programiści zabierają się za poprawkę.
15:30
Jeszcze jeden rzut oka na maile oraz jutrzejszy kalendarz. Przygotowuję materiały na jutrzejsze spotkanie statusowe z managerami. Na koniec przeglądam listę „to do” i dopisuję to, czym powinnam się zająć jutro. I tak kończy się mój poniedziałkowy sprint.
Podsumowanie
Dzień Product Ownera skupia się zatem głównie na planowaniu, kreowaniu, usuwaniu blokerów i podejmowaniu decyzji wpływających na produkt, jego wygląd i funkcjonalności. Każdy dzień Product Ownera jest inny, a jego zadania zmieniają się w zależności od potrzeb. Rytm tygodnia nadają spotkania scrumowe i jedno jest pewne: nigdy nie jest nudno.
[sc:newsletter_scrum]
