Artykuł jest rozwinięciem mojego poprzedniego, już dość starego wpisu „Jak robić porządkowanie Product Backlogu„. Poruszyłem w nim kwestie porządkowania (priorytetyzacji) backlogu. Tutaj chciałbym poszerzyć ten temat, pokazując Wam, jak priorytetyzację zrobić, jakie są metody jej określenia i co znaczy business value.
Priorytetyzacja wymaga od nas stwierdzenia, jak istotne jest dane wymaganie. Jeśli wszystkie wymagania są określone jako ważne, wtedy wszystko jest równie istotne. Oznacza to w tym przypadku, że tak naprawdę żadne wymaganie nie ma określonego priorytetu i istnieje niewielka szansa, że dostarczymy klientowi to, co naprawdę zaspokaja jego potrzeby. A jak to zmienić?
Priorytetyzacja jest częścią uszczegółowienia zadań (refinement) z rejestru produktu (PBL). Wskazuje ona zespołowi najbardziej istotne wymagania. Priorytetyzacja jest w większości robiona na podstawie określonej wcześniej wartości biznesowej (business value). Pozostałe przypadki to tzw. sekwencyjność (ang. dependencies) wymagań, kiedy jedno wymaganie może być zrealizowane dopiero po drugim.
Poniżej znajdziecie moją, a więc dość subiektywną, listę zebranych technik określania wartości biznesowej.
HiPPO (The Highest Paid Persons Opinion)
Wg jednej z wielu definicji HiPPO to liderzy, którzy są tak pewni siebie, że nie potrzebują ani innych pomysłów, ani danych, aby potwierdzić poprawność swoich instynktownych przekonań. Opierając się na swoich doświadczeniach i sprycie, nie zgadzają się z odmiennymi zdaniami i lekceważą wkład podwładnych / współpracowników.
Jest to bardzo częsta sytuacja w korporacjach, kiedy realizujemy wymagania kogoś, kto jest “istotny”, kto wyraża swoją opinię nie bazując na danych, lecz przeświadczeniu. Oczywiście wpływa to na kolejność zadań w PBL.
Ten punkt potraktujcie jako coś niepożądanego, antywzorzec. Powinniśmy “omijać” takie sytuacje aby nikt nie wpływał na kolejność w PBL bo ma takie widzimisię.
CD3 (Cost of Delay Divided by Duration)
Cost of Delay Divided by Duration (pol. koszty utraconych korzyści w danym czasie) jest metodą porządkowania zbioru wymagań, która maksymalizuje wartość dla użytkownika, w zadanym czasie, kiedy są ograniczone “moce przerobowe”. Jest specyficzną formą metod kolejkowania pracy – WSJF – Weighted Shortest Job First.
Jedną w wielu zalet tej metody jest szacowanie zadań wg. wartości, którą mogą przynieść (a jeżeli ich nie wdrożymy, to kosztu utraconej wartości). Porównujemy zadania między sobą i porównujemy możliwości, które te zadania mogą nam “przynieść” w danym okresie czasu. CD3 optymalizuje ROI (return on investment, pol. zwrot na inwestycji) poprzez minimalizację kosztu i dając nam na wyjściu zestaw uszeregowanych funkcjonalności (oczywiście aby się to stało, musimy dla każdej funkcjonalności określić jej czas trwania oraz potencjalnie, jakie są jej przychody i koszty w poszczególnych tygodniach).
Na końcu, po zastosowaniu metody otrzymujemy CD3 Score, który im wyższy, tym istotniejszy (wdrażamy najpierw te funkcjonalności, gdzie faza developmentu trwa krótko, a generują one dużą wartość).
Tłumacząc CD3 w najprostszy sposób, możemy sobie zadać pytanie – co się stanie, jeżeli opóźnimy realizację danego zadania np. o jeden miesiąc?
W literaturze pojawia się również Cost of Delay (pol. utracone korzyści), opisane w wywiadzie udzielonym przez Dona Reinstena, autora m.in. “The Principles of Product Development Flow”. Don zwraca w wywiadzie uwagę na stronę kosztową danego przedsięwzięcia. Nie chodzi tylko o przyszłe korzyści (które mogą wpłynąć na przychód przedsiębiorstwa), ale również koszty rozwoju oprogramowania, koszt jego utrzymania, itd.
Szczegółowe użycie metody wraz z przykładem znajdziecie tu.
Kano Model
Głównym celem Kano Model jest pomoc w priorytetyzacji zadowolenia użytkownika.
Kano Model jest narzędziem pozwalającym zrozumieć i skategoryzować 5 typów wymagań (uświadomionych lub nie) dla nowych produktów lub usług.
Noriaki Kano zdefiniował metodykę, która pozwala dostarczyć użytkownikowi coś, co wykracza poza jego oczekiwania. Aby móc to zrobić, Kano Model:
- definiuje pięć kategorii wymagań użytkowników (klientów), których spełnienie zapewnia naszemu produktowi konkurencyjność,
- pokazuje, jak wcześniej zdefiniowane kategorie mogą wpłynąć na satysfakcję lub niezadowolenie użytkownika,
- pokazuje, które kategorie zwiększają, zmniejszają i tworzą nową wartość dla użytkowników,
- pomaga organizacjom zrozumieć potrzeby klientów lepiej, niż rozumieją je oni sami (np. Apple, który stworzył nowy rynek smartfonów, czyli odkrył potrzebę i ją uzmysłowił klientom),
Innymi słowy Kano Model dostarcza organizacjom pomoc w zrozumieniu i klasyfikacji wymagań klientów. Na jego podstawie firmy mogą priorytetyzować zadania będące w fazie developmentu i skupiać się na tych rzeczach, które dostarczają użytkownikom największą satysfakcję.
Metoda ta jest dość szeroko opisana. Książki, blogi i artykuły pozwolą Wam znaleźć konkretne przykłady jej użycia.
Relative weighting
Relative weighting (pol. szacowanie relatywne) jest techniką, która uwzględnia wartość oraz przyszłe koszty zrobienia funkcjonalności. Cytując Mike Cohn’a, technika ta jest lepsza do szacowania większych zadań (np. celów na kwartał), niż do szacowania zadań na sprint.
Cała instrukcja korzystania z przygotowanego narzędzia znajduje się na stronie.
Inną metodą szacowania relatywnego jest opisywany już na naszych łamach difficulty matrix. Metoda ta, w przeciwieństwie do sposobu opisanego przez Mike’a Cohn, tworzy matrycę, gdzie z jednej strony możecie wpisać złożoność techniczną, z drugiej spodziewaną wartość dla użytkownika końcowego. Jest to podejście, które wykorzystuje wizualizację, angażuje zespół i interesariuszy, dlatego też jest przeze mnie preferowane. Na zdjęciu powyżej widzicie faktyczną difficulty matrix i zgadzam się z Mike’iem, że niezależnie od wybranego sposobu przedstawienia, technika bardziej się nadaje do szacowania dużych zadań.
Kiedyś z Izą zaproponowaliśmy difficulty matrix do ułożenia backlogu czynności innych niż rozwój produktu, tak więc metodę tę polecam Wam nie tylko z punktu widzenia zmian w produkcie.
Theme scoring
Podobne jak w punkcie powyżej, Mike Cohn stworzył również do tej techniki dedykowane narzędzie. Theme scoring (pol. “Scoring” tematów) jest narzędziem do priorytetyzowania grupy tematów (np. user stories).
Technika polega na sumowaniu iloczynu wag i wartości (ang. rating) nadanych poszczególnym inicjatywom. Jak zobaczycie na grafice poniżej, w wierszach mamy kryteria, w kolumnach poszczególne inicjatywy.
Jedną z zalet tego narzędzia jest fakt, że przy jego instrukcji Mike wyraźnie napisał, aby wyznaczyć sobie inicjatywę środkową, z wartością 3. Wtedy ona stanie się dla nas niejako odnośnikiem i reszta inicjatyw może się do niej odwoływać. Podobnie rzecz wygląda, kiedy używamy szacowania relatywnego, opisanego w kolejnym punkcie.
Planning poker
Podobnie jak w zespołach developerskich, technikę Planning poker możemy wykorzystać do szacowania wartości biznesowej. W jednym z poprzednich wpisów na temat szacowania względnego zamieściłem link do filmu, który przedstawia jej użycie. Zainteresowanych procesem użycia planning pokera odsyłam do artykułu. Kluczową sprawą jest użycie tej metody, podobnie jak przy szacowaniu trudności, jak techniki opierającej się na szacowaniu relatywnym. Czyli wracamy do akapitu zamykającego poprzedni punkt – musimy wyznaczyć sobie jakieś zadanie, które będzie dla nas wzorcowe. Najlepiej, aby było ono proste i zrozumiałe. Łatwiej będzie nam się do niego odwołać i powiedzieć, że zadanie, które właśnie szacujemy, dostarcza użytkownikowi większą wartość (albo jest bardziej złożone, jeżeli szacujemy jego złożoność).
Docelowo możemy przy takim podejściu pokazywać również burndown chart, czyli ile w danym czasie dostarczyliśmy wartości (w sprincie, ale też per np. wdrożenie).
Idealną sytuacją jest stwierdzenie przez Product Ownera, że na podstawie informacji zwrotnej otrzymanej od klientów oraz na podstawie dotychczasowych prac, zespół osiągnął np. 80% spodziewanej wartości biznesowej i dalsze prace już nie mają uzasadnienia, ponieważ zajęłyby nam one np. kolejne dwa miesiące, a i tak w niewielkim stopniu wygenerują one wartość dla użytkownika. Oczywiście wiele tutaj zależy od produktu, zmian, które na nim wykonujemy.
Na wykresie obok widać business value oraz velocity zespołu. To co napisałem wyżej, w tym przypadku oznacza, że zespół dostarczył około 50 jednostek business value i PO mógłby podjąć decyzję, że dalsza praca nad funkcjonalnością (projektem) nie wniesie już wiele i powinna ona zostać zatrzymana.
Podejście Scrum INC.
Ostatnią techniką szacowania wartości biznesowej jest prezentacja, pokazana w 2014 roku przez Alexa Browna.
Zgodnie z nią, wartość biznesowa wynika z trzech elementów:
- Co możesz z powodzeniem wdrożyć?
- Czego klienci chcą i będą kupować (nawet jeśli jeszcze o tym nie wiedzą)?
- Coś, co sprawia zespołowi “radość tworzenia”.
Jak zobaczycie obok, to co prezentuje Scrum INC. jest zgodne z tym, co Wam opisywałem w poprzednim punkcie. Znów może nie warto inwestować czasu i środków w tworzenie funkcjonalności, które nie przyniosą zwrotu.
Alex w swojej prezentacji skupia się przede wszystkim na Net Present Value (NPV, pol. wartość bieżąca netto), jako metodzie najbardziej czasochłonnej, ale też najbardziej dokładnej.
Moje doświadczenie mi mówi, że sama metoda jest faktycznie bardzo dokładna, jednakże przyjęte założenia co do kosztów i przychodów inicjatywy zawsze można podważyć. W związku z czym i sama metoda może pokazywać wyniki oczekiwane, ponieważ można na nią dość istotne wpływać.
Istotne w prezentacji jest jeszcze jedno. Chodzi o low hanging fruits (pol. łatwo osiągalne cele) – kiedy oszacujemy złożoność epiców danej zmiany i podzielimy wyliczone NPV przez daną złożoność, okaże się, które funkcjonalności powinniśmy realizować w pierwszej kolejności jako przynoszące największy zwrot z inwestycji.
Podsumowanie
Na zakończenie chciałem się z Wami podzielić jeszcze dwoma rzeczami.
Po pierwsze, we wszystkich wskazanych metodach / technikach powinniśmy wziąć pod uwagę dwa elementy – ryzyko i naukę. Zarządzanie ryzykiem to bardzo szeroka nauka w dziedzinie zarządzania projektami. Nie chcę Wam tutaj mówić, że macie zgłębiać Prince2 albo inną metodykę. Ale wzięcie tego zagadnienia pod uwagę przy planowaniu (“a jak ktoś wypadnie ze sprintu, bo będzie chory?”), przy wdrożeniach (“co będzie, jak zespół nie dostarczy danej funkcjonalności w spodziewanym czasie?”), czy przy daily (“nie mam żadnych problemów” – “a dlaczego Twoje zadanie od trzech dni jest w “in progress”?”) jest niezbędnym elementem dobrego zarządzania rozwojem oprogramowania. Podobnie jak nauka. Każda nasza czynność powinna tę naukę wspierać po to, abyśmy stawali się jeszcze lepszymi pracownikami. Innym zagadnieniem, ale blisko związanym, jest nauka na błędach. Learning by failure (pol. “nauka na błędach”) dla dojrzałych organizacji jest czymś naturalnym i nikt nie ma problemu z przyznaniem się, że coś nie wyszło. I najważniejsze – zebrać tzw. lessons learned, czyli co z tej porażki wynika? Co możemy zrobić inaczej następnym razem, aby podobna sytuacja się w przyszłości nie powtórzyła?
Po drugie – często zapewne słyszycie, że powinniście tak pracować, aby uzyskać jak największą wartość dla akcjonariuszy. Steve Dening, który stworzył nurt “Radical Managegement”, prezentuje inne spojrzenie. W jednym numerów magazynu Forbes możecie znaleźć kolejny artykuł w temacie “The dumbest idea in the world”. Zgadzacie się tym nurtem?