Cum prioritizezi cererile de funcționalități care se adună

Urmărirea cererilor de funcționalități rezolvă unde trăiesc. Nu rezolvă care iese prima, iar această a doua întrebare e cea de care echipele rămân cu adevărat blocate. Un backlog de trei sute de cereri, grupate și etichetate, tot are nevoie de o regulă de decizie, pentru că “construiește lucrul cel mai cerut” funcționează doar până când două cereri sunt apropiate și a treia are o susținătoare zgomotoasă, ceea ce se întâmplă în majoritatea săptămânilor. Cadrele de mai jos nu sunt răspunsuri concurente la aceeași întrebare. Fiecare se potrivește unui tip diferit de cerere, iar folosirea unuia singur pentru toate e de obicei greșeala reală.

Ce face prioritizarea cererilor de funcționalități diferită de prioritizarea unei roadmap?

O decizie de roadmap pornește de la strategie și întreabă ce să construiască. O decizie despre o cerere de funcționalitate pornește de la o cerere care deja există și întreabă dacă să acționeze pe baza ei, iar cele două trag suficient de des în direcții diferite încât o cerere poate avea cerere mare și tot să fie greșit să o construiești, sau poate avea cerere mică și tot să merite, pentru că deblochează un cont strategic. Tratarea fiecărei cereri ca un vot de roadmap sare peste această verificare.

Ce e RICE, și funcționează pentru cererile de funcționalități?

RICE notează o idee pe reach, impact, încredere și efort, apoi împarte primele trei la al patrulea ca să obțină un număr comparabil. A fost construit pentru idei de roadmap în care o echipă crede deja, unde partea grea e compararea unor pariuri diferite între ele. Cererile de funcționalități vin deja cu un număr de reach, numărul celor care au cerut, care e mai concret decât reach-ul pe care îl are de obicei o idee de roadmap proaspătă. Locul unde RICE se încordează cu o cerere e încrederea și impactul: o echipă poate fi sigură că o cerere e reală și tot să nu aibă bază pentru cât va mișca o metrică, pentru că “impactul” pentru o cerere care are deja un nume și o urmă de utilizatori reali e un tip diferit de estimare față de impactul unei idei pe care nimeni din afara camerei nu a văzut-o încă.

Folosește RICE pentru cererile luate serios în considerare și încă nedecise. Nu îl aplica fiecărei cereri primite; efortul de notare se justifică doar la cele suficient de apropiate încât au nevoie de un departajor.

Ar trebui ponderat după venit, sau după cine a cerut?

După cine a cerut, dar nu doar după venit. Un cont aproape de reînnoire, un cont care a escaladat deja, și un cont a cărui cerere deblochează o afacere în desfășurare poartă o urgență pe care o cifră plată de venit nu o surprinde singură, iar o cerere de la o înregistrare de probă tot poate conta dacă blochează o decizie care devine curând venit. Ponderarea după venit e cea mai ușor de calculat dintre toate acestea, și tocmai de aceea cea mai ușor de supra-încrezut: elimină corect zgomotul de la conturi fără miză reală, și la fel de ușor poate retrograda o cerere care ar aduce un cont mult mai mare, încă în pipeline.

Ce rol joacă de fapt voturile?

Un semnal ieftin și continuu pentru cererile care deja există, și un mod prost de a descoperi ce cereri ar trebui să existe în primul rând. Un număr de voturi ajunge doar la utilizatorii care au găsit deja cererea și au considerat-o demnă de un clic, ceea ce înseamnă că totalul de voturi al unei roadmap publice reflectă vizibilitatea la fel de mult ca cererea: o cerere veche aproape de vârful listei continuă să acumuleze voturi parțial pentru că e ușor de găsit, iar o cerere mai nouă, la fel de reală, pornește de la zero. Articolul despre roadmap-ul public pledează pentru a lăsa voturile complet în afara roadmap-ului. Tratează voturile ca pe un semnal care trebuie grupat și ponderat după recență, nu ca pe un clasament construit în ordine. Tichete de suport vs. cereri acoperă celălalt punct orb din numărul de voturi: un decalaj real poate genera aproape niciun vot dacă utilizatoarele care-l întâlnesc nu găsesc niciodată lista, în timp ce apare zgomotos în suport.

Când câștigă cel mai zgomotos client, și e o problemă?

Uneori, și e o problemă doar când nimeni nu observă. Un client care escaladează des, scrie tichete detaliate sau are o linie directă cu cineva din echipă își va vedea cererile examinate mai repede decât un client mai tăcut, cu o cerere la fel de validă, iar un proces de prioritizare care nu verifică asta niciodată va favoriza sistematic pe cine insistă cel mai mult, nu pe cine are cazul cel mai solid. Clienții zgomotoși nu sunt problema de reparat; cererile lor sunt adesea cu adevărat importante. Reparația e un obicei: treci periodic prin backlog după sursă și verifică dacă același grup mic de conturi explică majoritatea a ceea ce s-a lansat recent, și întreabă-te dacă asta se potrivește cu unde e cu adevărat cererea.

Cum devine o decizie de prioritizare un răspuns?

Fiecare decizie de aici produce câștigătoare și pierzătoare, și ambele merită un răspuns care numește raționamentul real, nu doar o schimbare de stare fără explicație. Cum refuzi o cerere de funcționalitate acoperă ce spui unei cereri care a pierdut, într-un mod care păstrează relația intactă în loc să sune ca un refuz generic. Munca de grupare și etichetare care face toate acestea posibile de la bun început e acoperită în urmărirea cererilor de funcționalități; prioritizarea funcționează doar pe cereri deja înregistrate și grupate suficient de bine încât să poată fi comparate.

FAQ

Care e cel mai bun cadru pentru prioritizarea cererilor de funcționalități? Niciunul singur. Folosește numerele brute ca să găsești cel mai zgomotos semnal, RICE ca să compari o listă scurtă de candidate serioase, și o verificare de venit sau de cont ca să prinzi cazurile în care o cerere tăcută de la un cont strategic cântărește mai mult decât un grup mai zgomotos, dar mai puțin important.

Ar trebui cererile de funcționalități prioritizate la fel ca ideile de roadmap? Nu. Ideile de roadmap pornesc de la strategie; cererile de funcționalități pornesc de la o cerere care deja există. Notarea lor împreună face ca un pariu strategic bine argumentat, dar cu puțină cerere existentă, să piardă constant în fața unei cereri care pur și simplu are mai mulți oameni care au cerut-o.

Voturile de pe o roadmap publică reflectă cererea cu acuratețe? Doar printre oamenii care au găsit deja cererea. Cererile mai vechi, mai vizibile, adună voturi mai repede, indiferent cât de multă cerere reală stă în spatele uneia mai noi, așa că tratează totalurile de voturi ca pe un semnal, grupat și ponderat după recență, nu ca pe un clasament construit în ordine.

Cât de des ar trebui reevaluate prioritățile cererilor de funcționalități? Pe un ciclu fix, nu doar când cineva escaladează. O trecere lunară sau trimestrială care regrupează cererile și reverifică ponderarea prinde deviația, cum ar fi un grup mic de conturi care domină ce se lansează, pe care un proces pur reactiv nu o scoate niciodată singur la lumină.

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