W tym wpisie omówimy, czym jest metoda RICE, jak ją stosować i dlaczego jest tak skuteczna w naszym ulubionym kontekście zwinności.
Priorytetyzacja
Jednym z kluczowych wyzwań w zarządzaniu zwinnym rozwojem produktów jest efektywna priorytetyzacja zadań i funkcji, aby zapewnić maksymalną wartość dla klienta. Jeszcze gorzej się robi, gdy musimy to balansować z szybką reakcją na zmieniające się warunki.
Metoda RICE to narzędzie do priorytetyzacji, które pomaga zespołom Agile określić, które projekty, zadania lub funkcje powinny być realizowane w pierwszej kolejności. RICE to akronim od czterech kryteriów, które są brane pod uwagę przy ocenie i priorytetyzacji: Reach, Impact, Confidence oraz Effort.
Dzięki wykorzystaniu tych czterech kluczowych kryteriów, w języku polskim tłumaczonych jako Zasięg, Wpływ, Pewność i Wysiłek, RICE pomaga Product Ownerom i zespołom podejmować względnie obiektywne decyzje odnośnie priorytetów. Dzięki temu możemy próbować osiągnąć Świętego Graala zwinności – dostarczania maksymalnej wartości dla klienta i organizacji. Przy zachowaniu elastyczności i możliwości dostosowania do zmieniających się warunków, metoda RICE jest doskonałym narzędziem. Ale dość pochwał!
Czym jest RICE?
Działanie w RICE zaczyna się od określenia czterech cech dla wszystkich elementów, które mamy w planach spriorytetyzować. Nie musimy tego robić po kolei, ale jednak przyjęło się, że idziemy zgodnie z akronimem.
W takim wypadku pierwszy będzie Reach, czyli Zasięg. Ta cecha określa, ile użytkowników zostanie dotkniętych danym projektem, zadaniem lub funkcją. Im większy zasięg, tym wyższa wartość w tym kryterium. Pamiętać trzeba, że możemy tutaj używać dowolnej jednostki, aby była ona wspólna dla wszystkich wymagań. Zmiana systemu raportowego obejmie osoby w naszej firmie, ale np. wprowadzenie nowego sposobu płatności dla klientów – wszystkich obecnych i potencjalnych kontrahentów.
Pora na Impact, czyli Wpływ. Wartość tego kryterium mierzy, jak duży wpływ ma projekt na zidentyfikowanych użytkowników bądź organizację. Ponownie – im większy wpływ, tym wyższa wartość. Można znaleźć sugestie, żeby wartość ta zawierała się w przedziale 1-3, niektórzy dodają do tego wartości 0,5 i 0,25. „Jedynki” to będą zmiany, które zasadniczo mogą pozostać niezauważone bądź będą „przezroczyste”. Np. nowy format zapisu raportu (PDF poza Excelem i CSV) nie jest zmianą rewolucyjną. Natomiast możliwość własnego budowania kostek OLAP w zupełnie nowym narzędziu to raczej „trójka”.
Confidence, czyli Pewność mierzy naszą pewność co do pozostałych estymat. Im większa pewność, tym wyższa wartość. Zwykle mamy jakieś oczekiwania, oszacowania bądź podejrzenia, które potrafimy zamknąć w jednej z trzech kategorii – „jesteśmy pewni”, „jesteśmy przekonani” bądź „wydaje nam się”. To odpowiednio 100%, 80% i 50%. Jeżeli nasza pewność jest mniejsza, to nie oszukujmy się – zgadujemy, bo nie mamy żadnej pewności.
Na koniec został nam Effort, czyli Wysiłek. To nic innego jak oszacowanie wielkości pracy. Może to być oczywiście wyrażone w Story Pointach, a może być w man-day’ach, czy jakiejkolwiek innej mierze.
Jak stosować algorytm RICE?
Na początek musimy zbadać rzeczy, które będziemy priorytetyzować i określić zasięg, wpływ, pewność i wysiłek związany z każdym z nich. Oceny może dokonać Product Owner, bądź możemy działać w zespole. W tym drugim przypadku oczywiście mamy trochę więcej problemów i całość zaczyna przypominać dobrze skądiną znaną technikę WSJF.
Mając oszacowane poszczególne parametry, wynik RICE, sumując wartości zasięgu, wpływu i pewności, a następnie dzieląc wynik przez wysiłek. Wynik RICE można obliczyć za pomocą prostego wzoru:
RICE = (Reach x Impact x Confidence) / Effort
Wyższy wynik RICE oznacza wyższy priorytet, przynajmniej w teorii. Ten „wynik” to nic innego jak „jaki wpływ możemy wywrzeć na jednostkę pracy”, czyli trochę taka wartość. W teorii powinien nam posłużyć do priorytetyzacji, ale dobrze wiemy, że nic nie jest takie proste.
Warto jest przejrzeć poszczególne liczby i zobaczyć, czy któreś przypadkiem nie są zbyt podejrzane. Po drugie, dobrze jest sprawdzić zależności i zobaczyć, czy na pewno taka kolejność jest realna i możliwa do utrzymania. Jeśli nie – wprowadźmy odpowiednie korekty. Koniec końców to i tak Product Owner decyduje o kolejności elementów w backlogu, może więc spokojnie wybrać inną.
Wynik RICE to tylko sugestia, a my nie powinniśmy być niewolnikami używanych narzędzi.
