with 3 komentarze

Jednym z zadań Product Ownera jest priorytetyzacja wymagań. Niestety, sprawia ona wiele trudności, ponieważ podpada pod kategorię #tozależy.

Nie ma jednego, najlepszego sposobu priorytetyzacji. To co się sprawdzi zależy od specyfiki projektu, klienta, rynku oraz etapu w jakim ten projekt się znajduje. 

Podstawy

To może zacznijmy od początku. Czym jest priorytetyzacja? Jest to proces szeregowania wymagań w celu określenia ich względnej ważności. W czasie tego procesu wymagania otrzymują większy lub mniejszy priorytet. Może to odnosić się zarówno do wartości tych wymagań dla interesariuszy lub kolejności implementacji ze względu na inne czynniki. 

W zasadzie powinien być to proces ciągły, ale jeżeli pracujesz w software house to w praktyce można podzielić priorytetyzację wymagań na dwa etapy:

  • wyznaczanie priorytetów przez biznes przed implementacją i stworzenie roadmapy / harmonogramu wersji (release)
  • priorytetyzacja w trakcie implementacji na bazie ustaleń z punktu pierwszego

Co to znaczy?

Jedną z sytuacji, która pomoże Ci zrozumieć podział na wyżej wymienione fazy jest sytuacja, w której klient przychodzi z pomysłem na produkt do software house. Zazwyczaj nie zdaje sobie sprawy ile kosztuje realizacja takiego produktu. Wszystko wydaje się “proste” i “szybkie” 🙂 

W momencie przedstawienia oferty okazuje się, że nasza wycena przekracza zakładany budżet. Wtedy często mamy przygotowany plan B – pokazujemy koszt dostarczenia poszczególnych części sytemu oraz wyróżniamy te, które stanowią jego istotę (MVP). Żeby móc to zrobić należy właśnie przeprowadzić proces priorytetyzacji – w tym przypadku ze względu na wartość dostarczoną użytkownikowi końcowemu. Wszystkie “wodotryski”, a więc wymagania, które w naszym przekonaniu nie zaspokajają głównej potrzeby użytkownika są planowane w kolejnych releasach (wersjach). 

Czy wiesz, że w MVP Instagrama nie było na przykład procesu odzyskiwania hasła? Twórcy woleli przeznaczyć swój czas i pieniądze na budowanie tych funkcjonalności, które miały kluczowe znaczenia dla użytkownika, a więc filtrów.

W momencie podpisania umowy i rozpoczęcia prac musimy dokonać ponownej priorytetyzacji – zdecydować co dokładnie będziemy robić w pierwszej kolejności, a co później. 

Kryteria priorytetyzacji

W procesie priorytetyzacji można kierować się różnymi założeniami w zależności od produktu, stopnia jego dojrzałości i adaptacji na rynku, sytuacji biznesowej klienta i wieloma innymi. Do podstawowych kryteriów priorytetyzacji należą:

  • Korzyść, którą osiągają stakeholderzy w wyniku implementacji wymagania. Jak pewnie wiesz, każdy projekt ma wielu stakeholderów (Stakeholder, czyli kto? – NataliaCholewa.pl), więc ta korzyść może wyglądać różnie dla każdego z nich.
  • Kary, czyli konsekwencji, które wynikają z niewdrożenia danego rozwiązania. Obejmuje to priorytetyzację wymagań w celu spełnienia kwestii regulacyjnych lub wymagań polityki nałożonych na organizację, które mogą mieć pierwszeństwo przed innymi interesami interesariuszy. Każdy, kto pracował w maju 2018 roku w IT doświadczył siły tego kryterium. Wtedy to wchodziło w życie RODO. Wizja konsekwencji (kary) za nie zaimplementowanie tego wymagania była tak silna, że wszystkie wymagania niezwiązane z RODO były odsuwane w czasie.
  • Koszt, a więc wysiłek i zasoby potrzebne do wdrożenia wymagań. Może być wyrażony w różny sposób, w zależności od sposobu współpracy IT z biznesem. W przypadku współpracy klient – software house, koszty często będą przedstawiane w postaci konkretnych kwot, a w przypadku współpracy wewnętrznego IT z decydentami mogą to być estymacje czasowe. Rzadko ‘koszt’ jest stosowany jako kryterium samodzielnie – najczęściej łączymy go z analizą kosztów i korzyści.
  • Ryzyko jako szansa, że wymaganie nie może dostarczyć potencjalnej wartości lub nie może być w ogóle zaimplementowane. Jeśli istnieje ryzyko, że rozwiązanie nie jest technicznie wykonalne, to najbardziej ryzykowne wymaganie może otrzymać najwyższy priorytet. W ten sposób szybko dowiemy się, czy proponowane rozwiązanie może być dostarczone.
  • Zależności, czyli relacje pomiędzy wymaganiami, gdzie jedno wymaganie nie może być spełnione, jeśli inne wymaganie nie jest spełnione. Zależności mogą być wewnętrzne (wymagania między sobą w jednym projekcie), jak i zewnętrzne, a więc sytuacja, w której zależymy od jakiegoś zewnętrznego rozwiązania (np. API).
  • Wrażliwość czasowa, czyli data po której implementacja wymagania traci znaczącą wartość. Obejmuje to scenariusze, jeśli funkcjonalność zostanie dostarczona przed konkurencją, ale może również odnosić się do funkcjonalności sezonowej, która ma wartość tylko w określonym czasie w roku (np. przed świętami Bożego Narodzenia). Będzie to ważne wymaganie dla każdej osoby, która pracuje w branży ecommerce.
  • Stabilność rozumiana jako prawdopodobieństwo, że wymaganie nie ulegnie zmianie. Może tak się stać, gdy wymaga ono dalszej analizy lub dlatego, że interesariusze nie osiągnęli konsensusu na jego temat. Jeśli wymaganie nie jest stabilne, będzie najprawdopodobniej mieć niższy priorytet, aby zminimalizować nieoczekiwane przeróbki i zmarnowany wysiłek.
  • Zgodność z regulacjami, a więc konieczność wdrożenia w celu spełnienia wymogów regulacyjnych (legislacyjnych lub wewnętrznych regulacji organizacji). Podobnie jak z kryterium kosztów, rzadko kiedy to kryterium będzie samodzielnie decydowało o priorytecie wymagania. Można je łączyć np. z analizą kosztów i korzyści wynikających ze spełnienia wymagania. Zdarza się, że świadomie nie wdrażamy wymagań, które dostosowują system do wymagań prawnych, bo koszty zaniechania są po prostu niższe niż koszty implementacji.

Skąd ta trudność?

Priorytetyzacja to ocena względnej wartości. Każdy z interesariuszy może cenić coś innego. Nieuniknione w tej sytuacji są konflikty między nimi. Dodatkowym problemem może być trudność z określeniem jakiegokolwiek wymagania jako niższego priorytetu, a to może wpłynąć na zdolność do dokonywania niezbędnych kompromisów. 

Sposoby priorytetyzacji

W ostatnim czasie mam sporo do czynienia z różnymi MVP i widzę jak trudno podejmować decyzje nawet nie w kwestii “co” implementować, ale w jakiej kolejności. Można posiłkować się parafrazami lub analogiami, które ułatwią znalezienie tej relatywnej istotności wymagań.

Moją ulubioną analogią jest ta wymyślona przez Beatę – moją koleżankę z zespołu. Mniej więcej wygląda ona tak:

Wyobraź sobie, że masz odwieźć dziecko do przedszkola. Wydaje się, że jest mnóstwo rzeczy koniecznych do zrobienia, aby to się mogło wydarzyć. Na przykład musisz się ubrać, umyć, wsadzić dziecko do auta i pojechać do przedszkola. Ale tak naprawdę, jak się chwilę zastanowisz to odwiezienie dziecka będąc w piżamie JEST MOŻLIWE. Nie będzie to może dla Ciebie komfortowe, ale da się zrobić, prawda? W całym procesie jedyna kluczowa rzecz to wsadzenie dziecka do auta (bez tego ciężko osiągnąć cel: dziecko w przedszkolu). To jest Twoje MVP.

Są też bardziej konwencjonalne techniki, którymi można się posiłkować, m.in.:

  • szeregowanie (ang. ranking) – jest to po prostu szeregowanie wymagań w kolejności od najważniejszego do najmniej ważnego. Może momentami sprawiać trudności, gdy trzeba zdecydować, które z wymagań jest ważniejsze przy pozornie takim samym poziomie istotności.
  • grupowanie (ang. grouping lub numerical assignment) – w tej technice ustalamy różne poziomy istotności i przyporządkowujemy wymagania do tych poziomów. Ile ich będzie i jak się te poziomy będą nazywać jest zupełnie dowolne. Zazwyczaj ma co najmniej 3 stopnie. 
  • MoScoW – odmiana grupowania, ale na tyle rozpowszechniona, że warto o niej wspomnieć osobno. Tutaj odgórnie mamy ustalone cztery grupy do których przypisujemy wymagania, a sama nazwa jest akronimem od nazw tych grup: 
    • Must, a więc te wymagania, które są konieczne do zaimplementowania
    • Should są to wymagania, które nadal są bardzo ważne i powinny być zaimplementowane, ale można to zrobić później
    • Could to wymagania, które dobrze żeby były zaimplementowane, ale świat się bez nich nie zawali
    • Would, wszystkie te wymagania, które mogą być zaimplementowane “gdy starczy czasu
  • studolarówka (ang. Hundred Dollar Method) – metoda w której stakeholder (lub stakeholderzy) dostaje wirtualne 100 dolarów, które może wydać na wymagania. Pieniądze można wydać w dowolny sposób: dając po 1 dolarze na każde ze 100 wymagań lub całą setkę na jedno wymaganie, jeżeli jest w subiektywnych odczuciu tyle warte. Po takim ćwiczeniu zlicza się wartość wymagań i szereguje według tego.
  • model Kano – jedna z ciekawszych metod, która daje dobrą przejrzystość w kierunku rozwoju produktu. Bardzo chciałabym opisać tę metodę w dwóch zdaniach, ale jest to po prostu niemożliwe, dlatego odsyłam Cię do poniższego filmiku:

To oczywiście nie są wszystkie techniki. Opisałam te, które są najczęściej stosowane. Omówienie wszystkich technik to temat na zupełnie osobny artykuł 🙂 

Ciągła priorytetyzacja

Jak (prawie) wszystko w obecnym świecie, priorytety mogą ulegać zmianie w miarę rozwoju sytuacji. Nie ma sensu priorytetyzować całego backlogu z założeniem, że to się już nie zmieni. 

Początkowo priorytetyzacja odbywa się na wyższym poziomie abstrakcji. W miarę jak wymagania są doprecyzowane możesz odkryć różnego rodzaju zależności lub otoczenie biznesowe może ulec zmianie. 

Wraz z dostępną ilością szczegółów jest też spora szansa, że zmienią się koszty wdrożenia jakiegoś wymagania, przez co biznes może chcieć wpłynąć na kolejność implementacji albo nawet zrezygnować z jakiegoś wymagania lub wymyślić zupełnie nowe.

Spodobało się? Podziel się!

3 Odpowiedzi

  1. Marta
    | Odpowiedz

    Mam małą uwagę do MOSCOW. 🙂 Powinno być na końcu Won’t Have this time czyli, to czego w danym Sprincie lub okresie czasu nie będziemy realizować. Istotne jest też to, że coś co w danym sprincie jest Won’t Have this time może być MUST w kolejnym sprincie.

    • Natalia Cholewa
      | Odpowiedz

      Masz rację, choć to zależy od przyjętej metodologii (bo nie ma jednej słusznej 😉 ). Ja nie lubię tego założenia, że jak czegoś nie robimy teraz to musimy to zrobić później, bo warunki się zmieniają i może być to ograniczające. Dlatego wolę “Would” 🙂

  2. […] Powoli odchodzi się od “priorytetyzowania” backlogu, na rzecz “uszeregowania”. Póki co moje odczucie jest takie, że nadal chodzi o to samo, tylko nazywamy to inaczej, żeby było łatwiej cały proces przeprowadzić. Tak czy inaczej jest to częścią zarządzania backlogiem. Więcej o priorytetyzowaniu możesz przeczytać tutaj. […]

Zostaw Komentarz