Poznań Agile User Group - Darek Knopiński
Poznań Agile User Group - Darek Knopiński

Grudniowy PAUG – Business value & rozwój Product Ownerów okiem praktyka, Dariusz Knopiński

W poniedziałek odbyło się kolejne spotkanie poznańskiej społeczności agile, PAUG. Na spotkaniu, chyba po raz pierwszy, mieliśmy okazję gościć praktyka biznesowego. Darek Knopiński, bo o nim mowa, pokazał nam dwa interesujące zagadnienia – business value oraz mechanizm do oceny Product Ownerów. Zapraszam do przeczytania relacji.

Darek zaczął spotkanie od tematu business value (wartość biznesowa). Product Ownerzy bardzo często zajmują się wieloma innymi, „ważniejszymi” tematami, zanim zaczną priorytetyzować backlog zgodnie z wartością biznesową. A jak już zaczną, zazwyczaj słyszą rady, aby jako business value potraktować przypadkowe liczby, które pokażą istotność danego zadania.

A jakby zastosować w praktyce przykład, o którym Darek nam dość dokładnie opowiedział? Chodzi tak naprawdę o zastosowanie wartości biznesowej wg danych rzeczywistych. Przykład dotyczył ograniczenia porzuceń rejestracji kont typu firma na Allegro. Innymi słowy, chcąc się zarejestrować jako firma, musiałem przejść ok 10 kroków – podanie danych, wysłanie formularza z danymi rejestracyjnymi, przelew środków z mojego konta celem potwierdzenia tożsamości itd. W przytoczonym przykładzie proces rejestracji był tak skomplikowany, że jego współczynnik konwersji (mówiący o ilości firm rozpoczynających proces do ilości firm faktycznie aktywujących konto na końcu procesu) wynosił około 40%. Celem zespołu było podniesienie tego współczynnika do uzgodnionych 80%. I jest to dobry przykład zastosowania wartości biznesowej- nie bazujący na priorytetyzacji backlogu wg danych wymyślonych, tylko analizy procesu i eliminacji lub poprawy miejsc, gdzie użytkownicy go najczęściej porzucają.

Zespól rozpoczął pracę od analizy poszczególnych kroków procesu, identyfikacji miejsc, gdzie użytkownicy mieli najwięcej problemów. Sam proces pisania nowych funkcjonalności skupiał się na poprawie problemów, czyli najwyższą wartość w ich backlogu miały zadania związane z tymi miejscami procesu, które w analizie wypadły najsłabiej (najwięcej użytkowników porzucało w tych miejscach proces). W konsekwencji wartość współczynnika osiągnęła ok 74%, a na podstawie efektów pracy zespołu i analizy zachowań użytkowników wspólnie uznali, że to jest realny “sufit” dla tego procesu i dalsza optymalizacja kosztowałaby zbyt wiele do spodziewanych rezultatów.

Reklama


W przykładzie dobrze było widać, że wartość biznesowa może, a wręcz powinna być oparta o jakiś konkretny wskaźnik biznesowy. I cel, który otrzymuje PO, powinien być wyrażony poprzez wzrost lub spadek tego wskaźnika, a nie na przykład poprzez wskazanie konkretnych funkcjonalności do wdrożenia.

Drugim omówionym przez Darka zagadnieniem była ocena pracy Product Ownera. Myślę, ze wiele razy przechodziliście osobiście proces oceny. To, co nam pokazał prowadzący, to część oceny PO jako osoby odpowiedzialnej za produkt, relacje z zespołem, interesariuszami. W praktyce wyglądało to tak, że została rozesłana do zespołu i interesariuszy ankieta. W ankiecie były pytania o zarządzanie przez PO backlogiem (np. czy jest spiorytetyzowany, wyceniony), czy PO jest dostępny dla zespołu, czy ma z nim dobre relacje, itp.

Ocena w skali czterostopniowej pozwalała na końcu na pokazanie indeksu, który świadczył o pracy właściciela produktu. Jak odpowiedział prowadzący na jedno z pytań z sali – “czy tylko ten indeks służył do oceny PO?”, indeks jest tylko wskaźnikiem stanowiącym około 25% oceny. Pozostała część oceny to inne kwestie, takie jak na przykład realizacja uzgodnionych celów.

Przyjemnie się słuchało osoby, która faktycznie ma doświadczenie w biznesie. Nie były to teoretyczne rozważania, tylko konkretne zastosowania praktyk i pokazanie prób wykorzystania wskaźnika biznesowego jako wartości biznesowej priorytetyzującej backlog oraz modelu służącego do oceny Product Ownerów.

 

Jeżeli chcesz poznać więcej wskazówek (hintów), dotyczących danego tematu oraz całego Agile’a (począwszy od kontraktowania po techniki deweloperskie), sięgnij do książki AgileHints.

Jeden z rozdziałów jest również Darka 🙂

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X