2,7K

Jak priorytetyzować metodą Weighted Shortest Job First.

Priorytetyzacja kluczem do zwinności

Osiągnie zwinności w wytwarzaniu produktów w dużej mierze sprowadza się do umiejętności dostarczenia minimalnego zakresu, który przyniesie dostateczną wartość użytkownikom, by chcieli z nich korzystać (Minimum Viable Product lub inaczej Minimum Marketable Product) , a następnie płynne rozwijanie i zwiększanie ich wartości. Cała ta zabawa jest relatywnie prosta, gdy mamy już rozwiązanie wdrożone produkcyjnie i kolejne przyrosty są dość łatwe do określenia. Pomysły na cele i zakresy kolejnych iteracji i dostarczanych przez nie przyrostów nasuwają się same, bądź są podsuwane przez użytkowników. A to usuniemy jakieś bugi, a to usprawnimy coś, dorzucimy dodatkowy widok, nowy rodzaj raportu, czy nową funkcjonalność. Dużo trudniej jest przez parę, paręnaście sprintów budować od zera MVP produktu, w którym dopiero po dostarczeniu pewnej masy krytycznej funkcjonalności możemy mówić o czymś używalnym, a po paru lub parunastu następnych funkcjonalnościach, o czymś naprawdę atrakcyjnym dla użytkownika. W każdym jednak momencie będziemy mieli do czyniania z całą masą pomysłów i zadań do realizacji, które przy ograniczonych zasobach będa tworzyły kolejkę. Piękno agile’a polega na tym, że nie staramy się przewidzieć wszystkiego na starcie, tylko pozwalamy sobie na budowanie naszych wyobrażeń o efekcie końcowym w trakcie realizacji projektu (własciwie trafniejsze byłoby określenie “w trakcie budowania produktu”)* bazując na namacalnych efektach naszych prac. Przy takim podejściu do zarządzania zakresem prac i dostarczaną wartością, kluczowa staje się umiejętność priorytetyzowania. WSJF, jest techniką używaną do priorytetyzacji elementów backlogów. Jej autorem jest Donald Reinertsen, a Scaled Agile Framework bardzo chętnie ją zaadoptował i propaguje. Zachęcam do zapoznania się z nią nawet tych, którzy w SAFe jako frameworku nie widzą dużej wartości.

Jeśli chciałbyś dowiedzieć się więcej odnośnie tego, dlaczego priorytetyzacja prac w podejściu zwinnym jest tak ważna, to odpowiedzi znajdziesz w tym artykule:

WSJF, czyli Weighted Shortest Job First

Skrót WSJF oznacza Weighted Shortest Job First (przetłumaczmy to powiedzmy, jako Najkrótsza Ważona Praca jako Pierwsza), zatem jak możemy wywnioskować już z samej nazwy, jest podejściem, w którym najwyżej w rejestrze produktu powinny znaleźć się elementy, które jesteśmy w stanie dostarczyć najszybciej, przy uwzględnieniu paru innych czynników decydujących o ich wartości biznesowej.

Dlaczego mielibyśmy chcieć realizować szybko-dostarczalne prace w pierwszej kolejności?

Jeśli inwestujemy nasz czas i zasoby w wytworzenie czegoś, co ma nam przynosić korzyści w przyszłości, to oczywistym jest że chcemy mieć to gotowe do użycia jak najszybciej. Problem w tym, że najczęściej takich inwestycji mamy w realizacji wiele, a chcielibyśmy mieć ich jeszcze więcej. Życie jest krótkie, również życie produktów, czasu mamy zawsze za mało, więc odruchowo staramy się robić jak najwięcej rzeczy naraz chcąc zrobić w danym czasie jak najwięcej. Ile rzeczy możemy robić jednocześnie? Ile zadań mogą wykonywać w tej samej chwili pracownicy? Ile projektów jesteśmy w stanie prowadzić w tym samym czasie? Patrząc na to co robimy na co dzień wydaje się, że wiele, bardzo wiele, jesteśmy zaangażowani równolegle w parę czy paręnaście projektów, najczęściej robimy całą masę rzeczy naraz, angażując w każdą z nich ułamek naszych zasobów. Odnoszę wrażenie, że liczba naraz uruchamianych w firmach inicjatyw dąży do nieskończoności. Nie spotkałem się z tym, żeby ktoś powiedział “Nie, za dużo tego robimy. Odpuśćmy sobie na chwilę nowe projekty i skończmy najpierw te, które mamy w toku”. Znasz to ;]

Załóżmy, że na tym rysunku widzimy projekty, które chcemy mieć zrealizowane:

Jednym z podejść jest rozpoczęcie jak największej ilości z nich. W końcu nie wszystkie wymagają zaangażowania tych samych zasobów w tym samym czasie. Niektóre będą długo przechodziły przez etap uruchamiania, w tym czasie część już będzie analizowana, zanim skończy się analiza tych największych, to zaczniemy już dewelopować w tych mniejszych lub w tych, które zaczęliśmy wcześniej. Fazy wytwarzania pewnie ponachodzą na siebie, ale sprawne zarządzanie w strukturze macierzowej pozwoli nam realizować wiele inicjatyw na raz. Z takiego założenia wychodzimy. Przez takie rozpraszanie robimy dużo w tym samym czasie, ale ogólnie posuwamy się dość wolno. Taką sytuację na poziomie projektów ilustruje ten obrazek, dla uproszczenia projekty nie zostały wydłużone o czas potrzebny na przestrajanie się między zadaniami, ale wiadomo że ten koszt występuje, wiadomo też że nie jest wartością trywialną:

Rysunek poniżej przedstawia alternatywny scenariusz. Bierzemy te same projekty, o takiej samej pracochłonności, ale ustawiamy je sekwencyjnie. Dzięki temu, nawet jeśli sumarycznie czas realizacji całego portfela będzie taki sam, lub podobny, to w międzyczasie uda nam się doprowadzić część projektów do końca i już wcześniej czerpać korzyści z ich produktów.

W dużym uproszczeniu można założyć, że zrobienie w pierwszej kolejności najmniejszych, najkrótszych projektów, bądź pełna koncentracja na minimalnej ilości inicjatyw przeprowadzanych na raz pozwoli nam szybciej zacząć osiągać korzyści i będziemy je osiągali już w czasie, w którym, w alternatywnym scenariuszu, posuwalibyśmy się jeszcze powoli w realizacji wielu rozgrzebanych wątków. Życie jednak nie jest takie proste. Małe projekty, możemy relatywnie szybciej ukończyć, ale te duże są zazwyczaj smaczniejszymi kąskami i przynoszą więcej korzyści. Funkcjonujemy zatem w środowisku wielu zmiennych i musimy na co dzień podejmować decyzje odnośnie tego, co potrzebujemy na już, a na co możemy jeszcze poczekać. Sam fakt priorytetyzowania, abstrahując już od metody priorytetyzacji, i tak jest jednak lepszy niż podejście, w którym wszystko jest najważniejsze i wszystko chcemy mieć już.

Nie tylko projekty

Podobne mechanizmy, co dla projektów, występują również w przypadku mniejszych inicjatyw, takich jak np. epiki albo pojedyncze funkcjonalności. Nie wchodząc zbytnio w hierarchię wymagań, jaką stosuje dana organizacja można przyjąć, że WSJF może służyć do priorytetyzacji elementów backlogów, jednak gdy zapoznasz się ze szczegółami tej metody, to zauważysz że jej stosowanie jest zasadne tylko przy relatywnie dużych pakietach prac.

WSJF bazuje na wartości CoD (Cost of Delay – Koszt Zwłoki)

Koncepcja WSJF mówi o tym, że jeśli musimy podejmować decyzje odnośnie tego, który projekt opóźnimy, to powinniśmy opóźnić ten, którego odsunięcie w czasie będzie nas mniej kosztować. Tak, wiem, brzmi banalnie, ale wytrwaj, jeszcze się rozkręcę. Ten Koszt Zwłoki, który możemy też nazywać Kosztem Utraconych Korzyści, ma najczęściej dwa wymiary, na przykładzie wprowadzania nowych produktów na rynek:

1. pierwszy wymiar jest dość prosty – jeśli coś wprowadzimy na rynek później, to przesuniemy moment, w którym zaczynamy na tym zarabiać, więc zarabiamy mniej o wartość którą uzyskalibyśmy, gdybyśmy zaczęli sprzedaż wcześniej,
2. drugi wymiar już nie jest tak powszechnie rozumiany – cena jednostkowa lub popyt na nasz produkt może być różny w czasie, np. jeśli wejdziemy na rynek po premierze konkurencji będziemy musieli sprzedawać po niższej cenie albo będziemy mogli sprzedać mniej; może mieć również miejsce sytuacja, w której musimy trafić z produktem przed jego sezonem (np. w przypadku nart) i tutaj opóźnienie będzie dla nas kosztowne, niezależnie od tego jak zachowa się konkurencja

Zobrazowany Cost of Delay

Poniżej mamy dwa warianty realizacji poszczególnych funkcjonalności rozwijanego przez nas produktu.

W wariancie pierwszym realizujemy funkcjonalności zaczynając od tych najkrótszych (a jednocześnie bardzo wartościowych), żeby minimalizować całkowity Koszt Zwłoki.

Koszt Zwłoki funkcjonalności A wynosi zero, gdyż w jej przypadku nie ma żadnej zwłoki. Koszt Zwłoki funkcjonalności B wynosi 9 jednostek (3 jednostki czasu potrzebne na dostarczenie funkcjonalności A razy 3, czyli Jednostkowy Koszt Zwłoki funkcjonalności B). Koszt Zwłoki funkcjonalności C wynosi 45 jednostek (9 jednostek czasu potrzebnych na dostarczenie funkcjonalności A i B razy 5, czyli Jednostkowy Koszt Zwłoki funkcjonalności C). Całkowity Koszt Zwłoki dla tej kombinacji funkcjonalności A, B i C wynosi 54 jednostki.

W wariancie drugim realizujemy funkcjonalności zaczynając od C, np. dlatego, że chcemy zacząć od największego pakietu prac.

Koszt Zwłoki funkcjonalności C wynosi zero, gdyż w jej przypadku nie ma żadnej zwłoki. Koszt Zwłoki funkcjonalności B wynosi 30 jednostek (10 jednostek czasu potrzebnych na dostarczenie funkcjonalności A razy 3, czyli Jednostkowy Koszt Zwłoki funkcjonalności B). Koszt Zwłoki funkcjonalności A wynosi 144 jednostki (16 jednostek czasu potrzebnych na dostarczenie funkcjonalności C i B razy 9, czyli Jednostkowy Koszt Zwłoki funkcjonalności A). Całkowity Koszt Zwłoki dla tej kombinacji funkcjonalności A, B i C wynosi 177 jednostek.

To są oczywiście skrajne przypadki, z być może mało prawdopodobnymi wartościami, ale dobrze ilustrują omawiane zależności.

Stosując metodę WSJF realizujemy w pierwszej kolejności prace o najlepszym stosunku Kosztu Zwłoki do czasu trwania (lub pracochłonności, ale o tym później), jeśli postawimy wartości z naszego przykładu do wzoru:

WSJF = Cost of Delay/Duration (Job Size)

czyli

WSJF = Koszt Zwłoki/Czas Realizacji (Pracochłonność)

to otrzymamy następujące wartości:

Interesuje nas największa wartość WSJF, a tą posiada funkcjonalność A. Korzystając jedynie z kalkulacji metodą WSJF właściwie nie ma większego znaczenia, czy najpierw zrealizujemy B, czy C, ale z kolei stosując podstawowe pryncypia zwinności wybierzemy zapewne B, żeby móc szybciej dostarczyć ją użytkownikom, otrzymać feedback i móc czerpać z niej korzyści.

Wyznaczanie Cost of Delay

W życiu będziemy mieli do czynienia z różnymi kombinacjami pracochłonności zadań, wartości biznesowej i wynikającego z niej Kosztu Zwłoki. Żeby Koszt Zwłoki wyznaczyć jak najbardziej obiektywnie i precyzyjnie wyrażamy nim różne aspekty realizacji danych prac. Rozbijamy go na trzy składowe:

Wartość Biznesowa Użytkownika (User Business Value)

Presja Czasu (Time Criticality)

Redukcja Ryzyka i/lub Wyzwolenie Szans (Risk Reduction and/or Opportunity Enablement)

Parametry te możemy tłumaczyć następująco:

Wartość Biznesowa Użytkownika (User Business Value)

Co preferują użytkownicy? Na co najbardziej liczą? Bez czego nie będa chcieli korzystać z naszego produktu? Jakie przełożenie dana funkcjonalność będzie miała na nasz wynik finansowy? Jakie oszczędności wygeneruje dane rozwiązanie?

Presja Czasu (Time Criticality)

Jak wartość danej funkcjonalności dewaluuje z czasem? Jak na wartość naszych rozwiązań wpłynie wyprzedzenie nas przez konkurencję? Czy istnieje jakiś deadline wywierający presję dostarczenia danego elementu (może doroczne targi branżowe, na których musimy się pokazać? może wejście w życie jakiś regulacji prawnych)?

Redukcja Ryzyka i/lub Wyzwolenie Szans (Risk Reduction and/or Opportunity Enablement)

Czy dana funkcjonalność odblokowuje jakieś inne funkcjonalności? Może dotyczy to jakiegoś rozwiązania technicznego, które umożliwi nam dotarcie do nowej grupy użytkowników? Może funkcjonalność generowania raportów dla użytkowników pozwoli również nam lepiej zrozumieć ich zachowanie i lepiej dostosowywać nasze produkty do ich potrzeb?

Czas Realizacji, a Pracochłonność

Metoda WSJF dopuszcza dwa warianty mianownika, do którego odnosić będziemy Koszt Zwłoki.

WSJF = Cost of Delay/Duration (Job Size)

Zasadniczo interesuje nas Czas Realizacji (Duration) mówiący o tym, jak bardzo dana wartość będzie odroczona w czasie. Czasami jednak będzie to trudne do określenia jeśli jeszcze nie wiemy, jakimi zespołami będziemy realizować daną funkcjonalność (lub projekt), gdyż na czas trwania wpłynie zarówno wielkość zespołów, jak i ich kompetencje. Możemy wtedy odnieść się do wartości nieco mniej względnej – Pracochłonności (Job Size). Nie ma znaczenia jakimi jednostkami wyrazimy pracochłonność (ManDays, czy Story Points), nie jest też oczekiwana bardzo duża precyzja tych estymacji. Bezwzględne wartości nie są w tej metodzie istotne dlatego, że służy ona do priorytetyzacji elementów backlogów, a nie określenia uzasadnienia biznesowego poszczególnych prac. Interesuje nas zatem, która funkcjonalność jest względnie kosztowniejsza i jakiego rzędu jest to różnica.

Praktyczne wyliczanie wskaźnika WSJF

Koszt Zwłoki odnosimy do Czasu Realizacji, zatem całkowity wzór na WSJF wygląda następująco:

WSJF = Cost of Delay/Duration (Job Size)

a dokładniej

WSJF = User Business Value + Time Criticality + Risk Reduction and|or Opportunity Enablement)/Duration (Job Size)

Oprócz samej idei i wzoru ciekawa jest też technika priorytetyzowania grupy elementów backlogu. Zalecana sekwencja działań jest następująca:

0. Wylistuj interesującą Cię grupę prac w tabeli

Źródło: www.scaledagileframework.com

1. Nadaj wartość 1 dla parametru User-Business Value funkcjonalności (projektowi, pakietowi prac) o najmniejszej wartości biznesowej/użytkownika.
2. Nadaj wartości 2,3,5,8,13, 20 dla parametru User-Business Value kolejno pozostałym elementom backlogu.
3. Przypisz wartości 1, 2,3,5,8,13, 20 kolejnym parametrom (Time Criticality, RR/OE, Job Size) poruszając się kolumnami po kolei (nie zaczynam kolejnej kolumny jeśli nie skończyłeś przydzielać wartości wszystkim elementom), zawsze zaczynając od wartości 1.
4. Wylicz wartość Cost of Delay.
5. Wylicz wartość parametru Weighted Shortest Job First.
6. Interesują Cię elementy o najwyższej wartości WSJF

WAŻNE: Priorytetyzacji dokonuje się dla danej grupy elementów względem siebie. Wszystkie wartości są relatywne w zadanej grupie. Gdy zatem pojawi się w backlogu jakikolwiek nowy element, ćwiczenie powinno zostać powtórzone (oczywiście praktyczniejsze jest dorzucanie elementów grupami, żeby nie  ugrzęznąć w “wiecznej” repriorytetyzacji).

Do czego to wykorzystać?

Metoda WSJF umożliwia szybką priorytetyzację elementów backlogów i określanie zakresu najbliżej iteracji w zwinnym wytwarzaniu produktów. Nie powinno się jej używać do podejmowania decyzji Start/Stop dla inicjatyw, bo nie daje precyzyjnych wartości i nie dostarcza uzasadnienia biznesowego. Jeżeli jednak mamy backlog elementów, które przeszły walidację założeń, wszystkim daliśmy zielone światło i pozostaje nam określenie co chcemy mieć w pierwszej kolejności, a na co możemy jeszcze poczekać, to ta metoda jest błyskawiczna i wystarczająco precyzyjna.  

Dla ułatwienia, na dobry początek, arkusz przygotowany pod priorytetyzację metoda WSJF:

SZABLON DO PRIORYTETYZACJI METODĄ WSJF

* Niby kosmetyczna różnica: “realizacja projektu” a “wytwarzanie produktu”, ale w agile’u, zwłaszcza w agile’u myślimy i działamy bardziej w kontekście rozwoju produktów (ciągłego i iteracyjnego), niż realizacji projektów (z dość ściśle określonym zakresem oraz możliwie najdokładniej zdefiniowanym czasem realizacji).