Czytaj

arrow pointing down

Product owner – kim jest i jakie ma zadania w projekcie?

Product owner jest integralną częścią każdego zespołu scrumowego, który dba o równowagę między biznesem a technologią. Przeczytaj więcej o tym zawodzie!

Product owner jest integralną częścią każdego zespołu scrumowego. Spoczywa na nim odpowiedzialność za maksymalizację jakości tworzonych w jego obrębie produktów. Odpowiada za cały proces ich rozwoju – od strategii biznesowej po projektowanie produktu. Jego rolą jest znalezienia równowagi między biznesem a technologią.

Kluczowe kompetencje:

  • wiedza na temat produktu (merytoryczna i techniczna);
  • znajomość biznesu, klientów i rynku (trendów i konkurencji);
  • doskonałe zdolności komunikacyjne;
  • umiejętność podejmowania samodzielnych decyzji i ponoszenia za nie odpowiedzialności.

Product owner to ktoś, kto:

  • jest ekspertem w zrozumieniu i przewidywaniu potrzeb klienta w celu skutecznego zarządzania procesem rozwoju produktu; 
  • ma wiele ról: stratega biznesowego, projektanta produktu, analityka rynku, łącznika z klientem i kierownika projektu;
  • ustala wizję, strategię i priorytety produktu; 
  • jest odpowiedzialny za każdy etap procesu rozwoju i produkt końcowy;
  • jest osobą kluczową dla każdego wydarzenia: planowania, przeglądu czy iteracji; 
  • stanowi gwarancję, że zespół zachowuje spójną wizję produktu, mimo elastycznego i szybkiego charakteru jego rozwoju;
  • ma poparcie interesariuszy we wszystkich głównych decyzjach i strategii działania, a także jasne instrukcje dla programistów.

Zadania product ownera:

  1. Pełna odpowiedzialność za „dlaczego” i „co” (podczas gdy zespół programistów dba o to „w jaki sposób”).
  2. Określanie celów i wizji rozwoju produktu – jego głęboka znajomość rynku i umiejętności komunikacyjne pozwalają przewidywać problemy lub potrzeby i reagować na nie.
  3. Zarządzanie backlogiem produktu, czyli listą zadań do wykonania projektu przez zespół. To on tworzy listę pozycji i nadaje im priorytety na bazie ogólnej strategii i celów biznesowych; musi ją stale aktualizować (w oparciu o zmieniające się potrzeby projektu w trakcie rozwoju) i udostępniać wszystkim zainteresowanym stronom (głównie programistom), by zapewnić optymalną wydajność i wyniki projektu.
  4. Ustalanie priorytetów potrzeb. Jego ramami są zakres, budżet i czas (np. jeśli produkt ma być uruchomiony w ciągu sześciu miesięcy, ogranicza to zakres projektu). 
  5. Nadzorowanie i ocena faktycznego postępu produktu w każdej iteracji. Dokonuje oceny wyników, decydując, czy zespół musi wrócić do poprzedniego etapu, czy też może przejść do kolejnych. 
  6. Komunikowanie się z interesariuszami (klientami, menedżerami biznesowymi i zespołem programistycznym), by upewniać się, że cele są jasne, a wizja zgodna z celami biznesowymi.
  7. Tworzenie wizualizacji: 
  • customer journey map, czyli tzw. mapy podróży klienta (product owner jest zawsze przed nim);
  • product roadmap, czyli tzw. mapy drogowej produktu (strategiczny przewodnik dla interesariuszy, jak i plan wykonania dla zespołu).

Mapy stanowią wsparcie dla zespołu na każdym etapie procesu rozwoju. Ułatwiają przejście od nakreślenia podróży klienta i tworzenia makiet projektów produktów do mapowania zależności produktów. Pomagają w motywowaniu i angażowaniu zespołu oraz przekonaniu go do wizji produktu.

Komunikacja i interakcje

Praca product ownera to nieustanne relacje interpersonalne z osobami o różnych interesach. Ponieważ ludzie mają różne perspektywy, konflikty stają się nieuniknione. Jego ponadprzeciętne umiejętności komunikacyjne oraz otwarte i odważne wyrażanie opinii i potrzeb stają się wówczas kluczowe.

Komunikatywność ułatwia efektywną pracę z zespołem i interesariuszami w każdej chwili i wobec różnych osób – wewnątrz i na zewnątrz organizacji. Dużym wyzwaniem jest zrozumienie, jak przekazać właściwy komunikat do określonych odbiorców w odpowiednim momencie i we właściwym formacie. Ważna jest przy tym asertywność. W tym przypadku polega ona na ochronie zespołu przed zmiennymi wymaganiami płynącymi bezpośrednio z otoczenia do zespołu scrumowego.

Przykłady interakcji product ownera:

  • Sponsor – powinien mieć krystalicznie jasne powiązanie ze sponsorem w kwestii celów i budżetu. W przeciwnym razie dojdzie do krytycznych nieporozumień.
  • Klient – ustalenie, jakie ma życzenia i oczekiwania, i w jaki sposób można mu pomóc, by docelowo czerpał z produktu przyjemność.
  • Scrum master – razem z nim jest sługą zespołu. Współpracują, aby mieć pewność, że odniesie się korzyści ze Scruma.
  • UX i UI – zrozumienie klientów i ich problemów wymaga głębokiej z nimi współpracy. W przeciwnym razie powstanie nie dość dobry produkt. Jednak czy produkt jest dobry czy wystarczająco dobry, UX, UI czy Dev Team mogą mieć różne opinie. Kluczowe jest spojrzenie z punktu widzenia wszystkich i podjęcie decyzji najlepszej dla produktu.
  • Zespół scrumowy – z nim musi zdefiniować cel sprintu, który następnie zgadza się na zobowiązanie do sprintu.
  • Zarządzający (c-level) – w rozmowach z najwyższymi szczeblami firmy nie ma miejsca na wątpliwości. Jego rolą jest znalezienia równowagi między biznesem a technologią.

Techniki działania product ownera:

  • Spotkania. Odbywają się prawdopodobnie codziennie. Product owner musi mieć jasny priorytet, w których wziąć udział. Organizując je, musi się upewnić, że są tam właściwe osoby, które nie marnują sobie nawzajem czasu.
  • Polemika. Na przykład liderzy techniczni domagają się preferencji tematów technicznych. Musi umieć ocenić, co jest to w danej chwili ważne, i co się wydarzy, jeśli daną kwestię uzna za priorytet.
  • Burza mózgów. Warto ją stosować, by uzyskać od innych jak najwięcej pomysłów i korzystać z nich. Ludzie często mają różne i często wykluczające się perspektywy, ale bez nich nie można odkryć ukrytych możliwości.
  • Stawianie pytań. Stanowią doskonałą okazję dla product ownera, by więcej słuchać, niż mówić. Zwłaszcza zadając trudne pytania, można dojść do sedna sprawy.
  • Negocjacje. Nie oznaczają, że jego pogląd musi wygrać, bo celem jest zawsze najlepszy produkt. Z pewnością nie raz musi negocjować zarówno z zespołem deweloperskim, jak i interesariuszami.

Czy nadajesz się na product ownera?

  • Lubisz codziennie rozmawiać z wieloma osobami w różnych kontekstach?
  • Jesteś gotowy/a na częste konflikty?
  • Lubisz prowadzić spotkania?
  • Więcej słuchasz niż mówisz?
  • Jesteś dobry/a w negocjacjach?
  • Jesteś gotowy/a do podejmowania decyzji w dowolnym momencie?

Podsumowanie

O roli product ownera można zdecydowanie powiedzieć, że nie jest łatwa, bo na każdym kroku wymaga wielu decyzji do podjęcia. Zespół deweloperski, a także firma, oczekują od niego, że zdefiniuje cały proces wydania produktu. To on musi ustalić priorytety, wskaźniki efektywności i zbierać wymagania.

W procesie rozwoju wyniknie niezliczona ilość pytań i alternatyw; programiści znajdą wiele opcji dla danej funkcji albo poinformują, że jest ona gotowa do użycia. To on decyduje, co jest optymalne dla produktu i kiedy będzie możliwy do wydania; bo całym zespołem ma kierować tak, aby zmaksymalizować wartość firmy.

Powiązane artykuły

Metody zarządzania projektami IT – tradycyjne, czyli kaskadowe

Metody zarządzania projektami IT dzielimy na kaskadowe i zwinne. Przeczytaj o tych tradycyjnych (kaskadowych), jak Waterfall czy PRINCE2.

Web Content Accessibility Guidelines – produkty cyfrowe zgodne z WCAG

Co to jest dostępność sieci oraz WCAG? Jak ułatwić korzystanie z internetu osobom niepełnosprawnym? Przeczytasz w tym artykule.