Scorarea RICE: formulă, exemplu rezolvat și capcane

Scorarea RICE ordonează ideile de produs cu un singur număr: acoperire înmulțită cu impact înmulțit cu încredere, împărțit la efort. Un scor mai mare înseamnă mai multă valoare așteptată pentru fiecare unitate de muncă. Metoda vine de la echipa de produs de la Intercom și a devenit un mod implicit de a compara cereri de funcționalități care nu pot fi departajate din intuiție. Funcționează cel mai bine pe o listă scurtă de candidați serioși și este la fel de bună ca estimările care intră în ea.

Care este formula scorării RICE?

Scorul este Acoperire × Impact × Încredere ÷ Efort. Acoperirea, impactul și încrederea se înmulțesc pentru că fiecare scalează câștigul, iar efortul împarte pentru că același câștig costă mai mult când cere mai multă muncă. Alege o singură fereastră de timp pentru acoperire, de pildă un trimestru, și folosește-o pentru toate elementele, altfel scorurile nu se pot compara.

Prezentarea originală de la Intercom definește scalele din tabelul de mai sus, iar majoritatea echipelor le păstrează neschimbate, ca scorurile să rămână comparabile între oameni.

Cum scorezi fiecare factor RICE?

Acoperirea vine din date pe care le ai deja. Pentru o cerere de funcționalitate, pornește de la numărul de conturi distincte care au cerut-o, apoi adaugă o estimare a conturilor care ar folosi-o fără să o ceară. Impactul este cel mai puțin precis factor, așa că folosește scala cu cinci valori și rezistă tentației de a inventa zecimale. Încrederea este un discount pentru presupuneri: folosește 100% doar când ai date de utilizare sau un prototip testat, 80% când ai semnale puternice și 50% când ghicești în mare parte. Efortul este timpul tuturor celor implicați, design și testare incluse, în persoană-luni.

Două persoane care scorează același element ar trebui să ajungă la cel mult un pas distanță pe fiecare factor. Dacă nu se întâmplă asta, elementul nu e înțeles suficient de bine ca să fie ordonat, iar dezacordul este concluzia.

Cum arată un exemplu de scorare RICE?

Ia patru cereri dintr-un backlog urmărit, scorate pe un trimestru.

Rezolvă primul rând: 400 × 1 × 0,8 ÷ 1 = 320. Modul întunecat ajunge la de trei ori mai mulți oameni, dar fiecare câștigă puțin, așa că se plasează chiar sub export. Integrarea Slack are un scor bun la impact, pe care încrederea îl înjumătățește, ceea ce îți arată că pasul următor este cercetarea, nu construirea.

Single sign-on se clasează ultimul, iar asta merită o a doua privire. Șaizeci de conturi înseamnă o acoperire mică, dar dacă sunt conturile mai mari și de funcționalitate depind mai multe reînnoiri, scorului îi lipsește ceva ce metoda nu poate vedea.

Care sunt greșelile obișnuite în RICE?

Prima este precizia falsă. O acoperire de 1.247 și un impact de 1,3 par riguroase și nu poartă mai multă informație decât 1.200 și 1. Rotunjește agresiv.

A doua este scorarea elementelor pe care ai hotărât deja să le construiești. Scorurile sunt atunci ajustate până câștigă favoritul, iar exercițiul produce doar un alibi.

A treia este ignorarea celui care a cerut. RICE numără oameni, așa că o cerere de la zece conturi mici depășește ca scor o cerere de la un singur cont care valorează mai mult decât toate zece la un loc. Când contează veniturile, adaugă o coloană pentru ele și citește-o lângă scor. Ponderarea pe conturi este tratată în cum prioritizezi cererile de funcționalități.

A patra este compararea scorurilor din ferestre de timp diferite sau pe scalele unor echipe diferite. Păstrează o singură foaie, o singură fereastră și un singur set de definiții.

Când ar trebui să folosești altceva decât RICE?

Când nu ai date despre acoperire, folosește ICE (impact, încredere, ușurință), care renunță la acoperire și înlocuiește efortul cu o notă de ușurință, și acceptă că este mai aproximativ. Când întrebarea este ce fel de valoare aduce o funcționalitate, nu cât de multă, modelul Kano clasifică cererile în funcționalități obligatorii, de performanță sau încântătoare, iar cele două se combină bine. Când decizia ține de ordine și de calendar, nu de clasament, se potrivește mai bine un format de roadmap, iar cum construiești o roadmap de produs îl tratează.

Cum păstrezi scorurile RICE oneste în timp?

Păstrează intrările lângă scor, nu doar rezultatul, ca oricine să vadă ce presupunere a determinat un loc în clasament. Reia un element când faptele lui se schimbă, de pildă când un nou val de cereri ridică acoperirea sau când un inginer observă că efortul s-a dublat. După lansare, compară acoperirea și impactul prevăzute cu ce s-a întâmplat și ajustează felul în care estimează echipa data viitoare. Materia primă pentru acoperire este lista grupată și etichetată de cereri descrisă în urmărirea cererilor de funcționalități, iar rezultatul își are locul în răspunsul trimis celor care au cerut.

FAQ

Ce este un scor RICE bun? Nu există un prag universal, pentru că numărul depinde de fereastra ta de acoperire și de unitatea de efort. Compară scorurile doar în aceeași foaie și tratează clasamentul, nu valoarea absolută, drept rezultat.

Care este diferența dintre scorarea RICE și ICE? ICE înmulțește impactul, încrederea și ușurința și lasă deoparte acoperirea. Se completează mai repede și este mai puțin exactă când funcționalitățile afectează numere foarte diferite de utilizatori, caz pentru care a fost creat RICE.

Cum estimezi acoperirea pentru o cerere de funcționalitate? Pornește de la numărul de conturi care au cerut-o, adaugă ponderea conturilor active care ar folosi-o neîndemnate și exprimă totalul pe trimestru. Dacă estimarea e aproximativă, scade factorul de încredere în loc să inventezi precizie.

Ar trebui scorată cu RICE fiecare cerere de funcționalitate? Nu. Scorarea merită efortul pentru cele câteva elemente suficient de apropiate cât să aibă nevoie de un departajator. Câștigurile evidente și respingerile evidente pot fi hotărâte fără ea.

Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.

Pe changeloop: Documentație pentru dezvoltatori, Comparație instrumente changelog