Czym powinien się kierować Product Owner?

Najprostsza odpowiedź byłaby – oczywiście Wartością! Ale jak do niej dojść?

Wielu Product Ownerów zaczyna pracę od tworzenia wymagań. W niektórych sytuacjach zakresy są im narzucane. Główna ich praca to opisywanie tychże wymagań, czyli występowanie w roli skryby.

Na jakiej podstawie są te zadania poukładane w Product Backlogu?

Niestety, często na podstawie „wydaje mi się”, „tak mi powiedziano”, „tego chcą moi stakeholderzy” i inne podobne odpowiedzi.

Jak zatem tworzyć wartościowe wymagania?

Start with a vision. Each Product Owner should be driven by vision and be able to inspire an organization and teams that developing a product. A product vision should be short, understandable, inspiring, and describing necessary information about the product.

Who, benefits

Wizja produktu powinna być krótka, zrozumiała, inspirująca i obrazować podstawowe informacje co to za produkt, dla kogo, jaką potrzebę klienta spełnia i jaką ma przynieść wartość.

Customer needs

Jest wiele rodzajów pomocnych szablonów wizji. Ja lubię „elevator pitch”. Jest krótki (30 sec do 2 min), prosty i wystarczający, żeby przekazać wizję. Zachęcam też do eksperymentów z innymi szablonami.

Competitors
Elevator Pitch

Focus on a business strategy. 

Skup się na strategii biznesowej. Przy tworzeniu strategii biznesowej produktu warto zaprosić stakeholderów, zespoły i każdego, kto może wesprzeć. Tutaj również możesz podeprzeć się istniejącymi szablonami, jak Business Model Canvas, Value Proposition Canvas lub kilka innych do wyboru. Z pewnością trzeba pamiętać, żeby zawrzeć persony (do kogo kierujemy nasz produkt), zdefiniować wartość, dostępnych ludzi i zasoby, strukturę kosztów, możliwe źródła przychodów, co robi konkurencja (jeśli jest) oraz inne ważne informacje.

Business strategy

Dzięki temu będzie łatwiej podejmować decyzje biznesowe. Zachęcam, aby tworzenie strategii przeprowadzać w formie warsztatów. Nawet, jeśli produkt jest wewnętrzny (dla organizacji), również należy mieć świadomość, kto jest odbiorcą, jaki mamy budżet, jaka płynie wartość z niego.

Business goals. 

Cele biznesowe. Co chcemy osiągnąć? Jaki to ma wpływ na organizację? Jaki ma to wpływ na naszych klientów (persony)? Co się zmieni w ich zachowaniu? Czego potrzebujemy, żeby to osiągnąć? I dopiero tutaj w tym momencie możemy zacząć myśleć o wymaganiach (epics, features, stories, ogólnie możemy je nazwać „items”). Wymagania są wtórne w stosunku do celów i wartości. Wynikają z nich. Pomocny tutaj może być Impact Mapping lub inna technika.

Business goal

Product Backlog. 

Product Backlog. Powinien być ułożony w kolejności uwzględniającej:

  • Wartość
  • Ryzyko
  • Zależności
  • Kiedy wchodzimy na rynek z funkcjonalnością (można też zwizualizować w formie roadmapy)
  • Możliwe inne czynniki, ważne z punktu widzenia produktu i organizacji

Wymagania powinny zawierać:

  • Spójność z celem (celami) biznesowym
  • Spójność ze Strategią biznesową
  • Spójność z Wizją produktu

Często w organizacjach Product Backlogi są poukładane zgodnie ze zakresem przedstawionym jakiś czas temu. Albo pod wpływem nacisków stakeholderów. Nieczęsto są aktualizowane pod względem wartości. Ba, rzadko kiedy używane jest pojęcie wartości. Najczęściej wyznawany jest kult dostarczania (więcej, prędzej), pytanie czy to, co zespoły dostarczają przynosi użytkownikom i organizacji wartość?

What’s next? 

Co dalej? Trzeba mierzyć wartość produktu – tę aktualną i możliwy do osiągnięcia potencjał. Podejmować na tej podstawie decyzje. W organizacjach często decyzje nie są podejmowane na bazie faktów. Oczekuje się predykcji, dokładnych planów, jednocześnie nie bierze się pod uwagę aktualnego stanu produktu. Brakuje przestrzeni i akceptacji na adaptację. Innymi słowy brakuje empirycznego podejścia.

So, what should be the Focus for the Product Owner? 

Jeszcze raz – na wartości, tej, która wypływa z wizji, potrzeb klienta i organizacji, zadowoleniu klienta/użytkownika, strategii biznesowej, zmierzonej wartości i potencjału. Poukładaniu Product Backloga zgodnie z powyższymi. Zastosowaniu empiryzmu.

Product Owner focus
Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Comment

Twój adres email nie zostanie opublikowany.

More To Explore

agile transformation

Dlaczego transformacje Agile czasami się nie udają?

Bazując na moim doświadczeniu w środowiskach Agile od 2010 roku, postanowiłam dokonać rewizji i pewnych obserwacji w tym temacie. Niezależnie od domeny biznesowej czy produktowej, zaobserwowałam pewne powszechne reguły, które mogą zniszczyć Wasze wysiłki na drodze do wprowadzenia zwinności. Bądźcie uważni!

Read More »
jak wybrać szkolenie

Jak wybrać odpowiednie szkolenie dla siebie?

Rynek szkoleń związanych ze Scrum i Agile rozwija się dynamicznie. To jest naprawdę świetna wiadomość, ponieważ zwinność wychodzi już dawno poza branżę IT i oznacza to, że coraz więcej organizacji zmierza w kierunku bycia zwinnymi.

Read More »
Przewiń do góry