Czy to produkcja oprogramowania, projektowanie samochodów czy zegarków…
Czy to budowanie produktów w podejściu Agile, Waterfall czy w jakikolwiek inny sposób…
Czy to Agile, Scrum, Kanban, DSDM, RUP czy XP…
Bez względu na to, jak go nazwiemy…
… Product Owner jest kluczową rolą w rozwoju produktu.
Skoro rola Product Ownera (PO) jest tak ważna, wręcz kluczowa, dlaczego tak trudno znaleźć organizacje, w których nie jest ona w żaden sposób zniekształcona?
Ale aby mówić o zniekształceniu, muszę najpierw określić, jak poprawnie rozumieć rolę PO.
Patrząc na powyższe, aby wykonywać swoje obowiązki,
Na samym początku napisałem, że rola PO jest przypisana do jednej osoby. Dlaczego nie do kilku osób, które dzielą zadania i kompetencje? Jest wiele powodów, ale najważniejsza jest spójność wizji produktu i możliwość skutecznego reagowania na zmiany w otoczeniu produktu. Decyzje muszą być podejmowane szybko, bez zbędnych dyskusji i impasu. Trzecim powodem jest jednoosobowa odpowiedzialność za wartość i sukces produktu. Jednoosobowa rola PO nie pozwala na rozmycie odpowiedzialności za brak decyzji, a jednocześnie pozwala organizacji szybciej się uczyć w przypadku obrania złego kierunku.
Ale wróćmy do problemów z utworzeniem takiego Product Ownera. Jest ich kilka, ale główna przyczyna jest jedna: strach po stronie biznesowej.
- „Product Owner to inna nazwa dla analityka w Agile” – strach przed prawdziwą zmianą.
Takie traktowanie PO przez długi czas obniża jego pozycję w organizacji i odcina go od biznesowego kontekstu rozwoju produktu. Dodatkowo nakłada na niego obowiązki PO dotyczące rozwoju aplikacji, nie dając mu prawa do decydowania o jej wizji, ścieżce rozwoju czy komponentach. Strach przed taką zmianą jest nieuzasadniony – menedżerowie stają się interesariuszami takiego produktu i nadal mogą zgłaszać swoje potrzeby i pomysły na rozwój, a PO wybiera te, które jego zdaniem zapewnią największą wartość biznesową. Oczywiście, partykularne interesy niektórych osób w organizacji mogą nie zostać spełnione, ale zadaniem PO jest wybór najlepszej możliwej ścieżki dla produktu, a nie poprawa samopoczucia menedżerów.
- „Product Ownerzy są tak ważni dla naszej organizacji, że mamy ich czterdziestu dwóch” – strach przed odpowiedzialnością.
Tak, 42 to odpowiedź na wszystkie zagadki wszechświata, jednak produkt wymaga scentralizowanej władzy PO. Rozproszone podejmowanie decyzji z czasem powoduje rozproszenie odpowiedzialności, a podejmowane decyzje nie obejmują wszystkich aspektów działania produktu. Produkt musi być rozpatrywany w kontekście systemu jako produkt całej organizacji i potrzebne jest globalne spojrzenie na jego działanie. Produkt współdziała z wieloma elementami organizacji. Co więcej, jeśli jakiś element organizacji nie jest związany z produktem, oznacza to, że powinien być z nim związany w przyszłości. Jeśli nie ma sensu dla produktu – prawdopodobnie jest zbędny.
- „Decyduję o produkcie, ale nie będę Product Ownerem, bo to taka niska pozycja, że nawet rozmawia z programistami” – strach przed utratą pozycji.
Nic bardziej mylnego. Może się wydawać, że praca bliżej programistów wygląda jak niższa pozycja, ale odpowiedzialność i samodzielne podejmowanie decyzji o produkcie pozwala Product Ownerowi przypisać sobie sukces produktu. Oczywiście, jest to sukces całego zespołu, ale PO ma największą moc decyzyjną. PO nie rozmawia z programistami – PO rozmawia ze wszystkimi w organizacji. Jest praktycznie najważniejszą osobą w organizacji, ponieważ tworzy i odpowiada za produkt, a to produkty przynoszą wartość organizacji. Od jego decyzji zależy sukces lub porażka produktu, a tym samym jego pozycja w organizacji jest kluczowa.
- „Product Owner to bardzo techniczna rola, jestem menedżerem” – strach przed niekompetencją.
Product Owner musi posiadać umiejętności wykraczające poza zestaw menedżera, ale nie jest to trudne ani wysoce techniczne. Teoretyczną część umiejętności można dość szybko nabyć poprzez szkolenia. Praktyczną część umiejętności można nabyć podczas pracy nad produktem, a początkowe braki nie powodują załamania produktu, jeśli są szybko uzupełniane. Lista umiejętności, które Product Owner musi z czasem nabyć, nie jest krótka, ale osiągalna:
- podejmowanie decyzji oparte na dowodach (prowadzenie testów, prowadzenie eksperymentów)
- analiza danych o wydajności produktu (analiza zachowań użytkowników, analiza zachowań oprogramowania)
- analiza rynku (analiza konkurencji, analiza udziału w rynku, analiza globalnych zmian)
- badania użytkowników (badania ilościowe, badania jakościowe, prowadzenie grup kontrolnych, zbieranie opinii)
- myślenie w kontekście użytkownika (user story, projektowanie skoncentrowane na użytkowniku, szacowanie wartości biznesowej)
- planowanie wydań i dużych zmian (zarządzanie wydaniami, cel wydania, mapowanie historii użytkownika)
- tworzenie wizji produktu (lean canvas, elevator pitch, persony)
- umiejętność współpracy, zbierania opinii i prezentowania produktu interesariuszom
- umiejętność współpracy z zespołami rozwojowymi (zarządzanie backlogiem, dług techniczny).
Organizacje, które promują podejście produktowe i wzmacniają profesjonalnych i poprawnie ustanowionych Product Ownerów, mają szansę szybko rozwijać swoje produkty w kierunku oczekiwanym przez ich klientów. Dodatkowo, poprawnie wprowadzona zwinność w organizacji pozwala na szybkie reagowanie na nieoczekiwane zmiany rynkowe.
Dlatego apeluję:
Menedżerowie – spróbujcie być Product Ownerami, bo warto.