Backlog produktu nie powinien być zbyt duży, aby można nim było wydajnie zarządzać. Nawet jeśli spełnia on ten wymóg, nie jest łatwo określić właściwe priorytety. Czy Product Owner powinien patrzeć na ważność, pilność, pracochłonność, czy po prostu preferencje klienta? Istnieje kilka różnych podejść, które warto znać i w razie potrzeby zastosować.
Priorytet czy priorytety?
Mówiąc o priorytetach, używamy tego słowa najczęściej w liczbie mnogiej. W wielu firmach jest ich całkiem sporo, a większość powinna zostać zrealizowana na wczoraj (lub jeszcze wcześniej).
Na przestrzeni wieków nie zawsze tak jednak było – kiedyś słowo to istniało w liczbie pojedynczej, priorytet mógł być jeden. To rzecz najważniejsza, którą należy realizować w pierwszej kolejności, więc nielogiczne byłoby umieszczanie na szczycie listy kilku rzeczy. W XVII wieku słowo to zaczęło się powoli pojawiać w liczbie mnogiej (w języku angielskim), aby w okolicy 1940 roku na dobre zadomowić się w tej formie. Prawdopodobnie nie miało to związku ze zmianami kulturowymi, lecz gramatycznymi.
Niezależnie od tego, ile priorytetów masz w swoim backlogu (lepiej mniej), powinieneś zastosować jakąś metodę ich ustalenia. Aby ułatwić sobie zadanie, możesz skorzystać z jednej z opisanych poniżej.
Priorytetyzacja backlogu przez porównanie
W teorii jest to prosty sposób, polegajacy na okresleniu ważności danego elementu w backlogu produktu. Wystarczy ustalić kategorie, a następnie porównując pomiędzy sobą elementy, przyporządkować je do jednej z nich. W praktyce możesz ulegać tendencji do ustawienia zbyt dużej liczby zadań jako najważniejszych.
Porównywanie możesz stosować jednowymiarowo, określając listę priorytetów, np. wysoki, średni lub niski. Na tej podstawie powinieneś realizować w pierwszej kolejności zadania, które trafiły do ważniejszej kategorii.
Inną opcją jest dwuwymiarowa skala, na przykład ważność i pilność (tzn. macierz Eisenhowera). Podobnie jak poprzednio powinieneś porównać zadania i umieścić je w odpowiednim miejscu na osiach. Później możesz zacząć realizowanie od zadań, które są pilne i ważne, pozostałe zostawić na później, delegować lub usunąć z listy.
Metoda MoSCoW
Jest to znana i często używana metoda pomagająca określić priorytety. Jej nazwa nie pochodzi od stolicy naszego wschodniego sąsiada, ale od pierwszych liter nazw kategorii, do jakich możesz przyporządkować poszczególne elementy backlogu:
- M (ang. must have) – musi być. Najważniejsze elementy, bez których tworzony produkt nie ma sensu. Powinny się pojawić w jego pierwszej wersji.
- S (ang. should have) – powinien być. Istotne funkcjonalności, jednak możesz je zrealizować później. Możliwe jest spełnienie ich w inny sposób.
- C (ang. could have) – może być. Jeśli będziemy mieli możliwość, warto je zrealizować, ale możesz je też pominąć lub odsunąć w czasie.
- W (ang. won’t have) – nie będzie. Tych funkcjonalności nie potrzebujemy w pierwszej wersji lub w ogólne możemy z nich zrezygnować.
Najprostszym sposobem na określenie, do której kategorii należy dany element backlogu produktu, jest zwizualizowanie ich jako kolumny. Następnie poszczególne zadania możesz umieścić na fizycznych lub wirtualnych karteczkach i zdecydować, w której grupie powinny się znaleźć.
Aby ograniczyć liczbę elementów o najwyższym priorytecie, można przeznaczyć na nie mniejszą ilość miejsca na fizycznej lub wirtualnej tablicy. Będzie to podświadomie pomagać w podjęciu decyzji o późniejszej realizacji lub nawet pominięciu mniej istotnych zadań.
Model Kano, czyli priorytety klienta
Jest to metoda stworzona przez profesora Noriaki Kano w latach osiemdziesiątych. Polega na przyporządkowaniu elementów backlogu produktu do jednej z pięciu kategorii, określających oczekiwania klienta.
Elementy obowiązkowe (ang. Must be)
Funkcjonalności, które muszą się znaleźć w produkcie, gdyż realizują podstawowe potrzeby klienta. Nie powodują wzrostu jego satysfakcji, po tym względem traktuje je neutralnie. Z drugiej strony ich brak prowadzi do niezadowolenia użytkownika. Może to być na przykład opcja cofnięcia ostatniej zmiany w twojej aplikacji.
Elementy atrakcyjne (ang. Attractive)
Cechy, które powodują zadowolenie klienta i stanowią dodatkową wartość podczas korzystania z produktu. Jednocześnie ich brak nie będzie odebrany negatywnie, użytkownik nie oczekuje tych funkcjonalności.
Elementy jednowymiarowe (ang. One-Dimensional)
Gdy są w produkcie, klient będzie szczęśliwy, a ich brak powoduje jego niezadowolenie. W przeciwieństwie do elementów atrakcyjnych są one wymagane przez użytkownika.
Elementy obojętne (ang. Indifferent)
Są to elementy, które nie wpływają pozytywnie ani negatywnie na klienta. Mogą być jednak przydatne z twojego punktu widzenia, gdyż wpływają na twoją pracę. W przypadku aplikacji może to być refaktoryzacja, zwiększająca czytelność kodu, przez co jego późniejsze zmiany będą łatwiejsze. Nie stanowi to jednak bezpośredniej wartości dla klienta.
Elementy odwrotne (ang. Reverse)
Stanowią przeciwieństwo elementów jednowymiarowych. Twój klient będzie niezadowolony, gdy zostaną dodane do produktu, ich brak spowoduje wzrost jego satysfakcji z używania. Może to być na przykład trudne do rozszyfrowania pole captcha, dodane na każdym formularzu w aplikacji.
Po przyporządkowaniu zadań do poszczególnych kategorii możesz zdecydować, od których zaczniesz realizację. Priorytetowo powinieneś traktować te, które najbardziej zwiększają satysfakcję klienta.
Metoda Kano skupia się bardzo mocno na użytkowniku, a nie twoich własnych preferencjach. Może to skutkować lepszym dopasowaniem priorytetów i większym zadowoleniem naszych użytkowników.
Priorytety na podstawie obliczeń
Jeśl jest ci trudno określić relację pomiędzy elementami backlogu, możesz pomóc sobie wyliczeniami. Następnie będziesz mógł porównać poszczególne wyniki i na ich podstawie określić najlepszą kolejność realizacji zadań.
Pierwszym krokiem powinno być zdefiniowanie kategorii, według których ocenisz poszczególne pozycje w backlogu. Może to być na przykład zadowolenie klienta, czas lub koszt wytworzenia, liczba użytkowników, ryzyko. Warto to dobrze przemyśleć, im lepsze kategorie zdefiniujesz, tym wartościowszy będzie wynik końcowy.. Następnie dla każdej z nich określ liczbowo wagę. Im będzie większa, tym dana kategoria jest według ciebie istotniejsza w wyliczeniach.
Teraz możesz wyznaczyć skalę ocen, według której ocenisz każdy element backlogu w poszczególnych kategoriach, na przykład od 1 do 10. Później pozostaje już tylko przypisać te liczby.
Gdy je określisz, wystarczy kilka prostych obliczeń. Każdą ocenę wystarczy pomnożyć przez wagę i dodać (w przypadku cech pozytywnych) lub odjąć (w przypadku negatywnych) od całości. Kolejność elementów uzyskasz sortując je według otrzymanej liczby.
Koszt zwłoki a priorytety
Ten sposób priorytetyzacji backlogu produktu polega na określeniu, jaki koszt za każdą jednostkę czasu stanowi dla ciebie późniejsze dostarczenie danej funkcjonalności. Możesz go określić, porównując czas realizacji poszczególnych elementów oraz koszty, jakie ponosisz w wyniku opóźnienia.
Możesz także przypisać zadania do kategorii, określonych na podstawie momentu ponoszenia kosztów, Następnie na tej podstawie możesz określić priorytety ich realizacji.
Liniowy koszt zwłoki
Tracisz każdego dnia, gdy nie dostarczyłeś produktu lub funkcjonalności. Przykładowo konkurencyjna aplikacja otrzymała funkcjonalność, dzięki której klienci chętniej ją wybierają.
Określona data
Gdy produkt lub funkcjonalność nie zostanie dostarczona w określonym terminie, spowoduje to całkowitą lub dużą stratę. Przykładowo może to być aplikacja zamówiona na konkretną, niemożliwą do zmiany datę, na przykład Mistrzostwa Świata w piłce nożnej.
Rosnący koszt zwłoki
Koszt opóźnienia jest na początku mały, ale po jakimś czasie znacznie rośnie. Mogą to być wykryte błędy w aplikacji lub nieczytelność kodu, który wymaga refaktoryzacji.
Przyspieszający koszt zwłoki
Jeśli nie zrealizujesz tego elementu w najbliższym czasie, koszt wzrośnie w znaczący sposób. Może to być na przykład jakiś poważny błąd w aplikacji lub zmiany w przepisach, które spowodują, że jakaś jej część będzie bezużyteczna.
Be First to Comment