În cele mai multe echipe de produs, backlogul este un loc în care urgența merge să moară. Totul ce intră în el a fost urgent când a fost adăugat — o plângere a clientului, o cerere de vânzări, o funcție de competitor, o idee internă. Șase luni mai târziu, totul este încă acolo, și totul se simte încă urgent, și nimeni nu știe exact ce să facă următor.
Problema nu este o lipsă de instrumente. Există duzini de cadre de prioritizare: RICE, MoSCoW, Kano, ICE, notare ponderată. Problema este că cele mai multe cadre necesită un fel de precizie falsă — asignarea numerelor la necunoscute — care le face să arate riguroase în timp ce de fapt doar spălau sentimentul de burtă printr-un foi de calcul.
Ceea ce de fapt funcționează este mai simplu: două dimensiuni, onest evaluate și disciplina de a acționa asupra rezultatului.
Prioritizarea se reduce la două întrebări. În primul rând: cât de mult îmbunătățește aceasta rezultatul pe care ne pasionează? (Impactul.) În al doilea rând: cât ne va costa să o livrăm? (Efortul.) Totul altceva este fie o rafinare a acestor două, fie o distragere de la ele.
Încrederea este uneori adăugată ca a treia dimensiune — „cât de siguri suntem despre impact?" — și merită să o ții în minte. Dar în practică, cele mai multe echipe știu când ghicesc. Disciplina este să etichetezi ghicitul cu sinceritate, nu să-l scoreszi pe o scară de 1–5 și să-l aduni la o formulă.
Impactul este dimensiunea care echipele găsesc cea mai greu de evaluat, pentru că adesea necesită predicția viitorului. Tentația este să-o scoreszi numeric și să te simți științific despre asta. O abordare mai bună este calitativă, dar structurată.
Pune trei întrebări pentru fiecare funcție sub considerare:
Cât de ușor este de asignat? Echipele sistematic subestimează efortul. Două practici ajută. În primul rând, întreabă întotdeauna ingineria înainte de a scora efortul, nu după. PM care scoresează efortul unilateral subestimează aproape întotdeauna. În al doilea rând, folosește conceptul de "necunoscute necunoscute" ca multiplicator de efort explicit. Orice funcție care atinge o zona nouă de codebase, o API de terță parte, sau un flux de utilizatori care nu a fost testat recent merită o scor de efort de 1,5 ori mai mare decât munca evidentă sugerează.
Cea mai mare parte a urgență într-un backlog de produs nu este urgență reală — este recentitate. Un client s-a plângut săptămâna trecută, deci cererea lor se simte presantă. Un competitor a lansat ceva luna trecută, deci potrivirea pare critică. Dar recentitatea nu este același lucru cu importanță, și a reacționa la recentitate este una dintre cele mai fiabile modalități de a lăsa munca cu adevărat importantă să alunece.
Un test practic: întreabă-te dacă ai considera aceasta urgentă dacă ai fi auzit despre ea cu șase luni în urmă în loc de săptămâna trecută. Dacă răspunsul este nu, este prag de recentitate în lucru, nu prioritate strategică. Înregistrează-o, evaluează-o calm împotriva grilei și rezistă la tragere pentru a o accelera doar pentru că este proaspătă.
Clientul care trimite cele mai multe email-uri despre o funcție este rar reprezentativ pentru baza ta de utilizatori. Prioritizează pe baza lărgimii și adâncimii problemei, nu persistența persoanei raportând-o.
Grila nu produce întotdeauna un răspuns curat. Două articole se pun în același cadran cu scoruri similare și încă trebuie să alegi una. În aceste cazuri, două tie-breaker sunt utile: alinierea strategică (care te mută mai aproape de unde vrei să fii în 18 luni?) și reversibilitate (care este mai greu de anulat dacă se greșește?). Preferă articolul care este mai strategic aliniat și mai reversibil.