Dare priorità alle richieste che si accumulano

Tracciare le richieste di funzionalità risolve dove vivono. Non risolve quale esce per prima, e questa seconda domanda è quella su cui i team restano davvero bloccati. Un backlog con trecento richieste raggruppate ed etichettate ha comunque bisogno di una regola decisionale, perché “costruisci la cosa più richiesta” funziona solo finché due richieste sono vicine e una terza ha una sostenitrice rumorosa, che è la maggior parte delle settimane. I framework qui sotto non sono risposte in competizione alla stessa domanda. Ognuno si adatta a un tipo diverso di richiesta, e usarne uno solo per tutte è di solito il vero errore.

Cosa rende diverso dare priorità alle richieste di funzionalità rispetto a una roadmap?

Una decisione di roadmap parte dalla strategia e chiede cosa costruire. Una decisione su una richiesta di funzionalità parte da una domanda che esiste già e chiede se agire su di essa, e le due tirano in direzioni diverse abbastanza spesso che una richiesta può avere molta domanda ed essere comunque sbagliata da costruire, o avere poca domanda ed essere comunque utile perché sblocca un account strategico. Trattare ogni richiesta come un voto di roadmap salta questo controllo.

Cos’è RICE, e funziona per le richieste di funzionalità?

RICE valuta un’idea su portata, impatto, fiducia e sforzo, poi divide i primi tre per il quarto per ottenere un numero confrontabile. È stato costruito per idee di roadmap in cui un team crede già, dove la parte difficile è confrontare scommesse diverse tra loro. Le richieste di funzionalità arrivano già con un numero di portata, il conteggio di chi ha chiesto, che è più concreto della portata che di solito ha un’idea di roadmap appena nata. Dove RICE va in tensione con una richiesta è su fiducia e impatto: un team può essere sicuro che una richiesta sia reale e comunque non avere basi per sapere quanto muoverà una metrica, perché “impatto” per una richiesta che ha già un nome e una traccia di utenti reali è un tipo di stima diverso dall’impatto di un’idea che nessuno fuori dalla stanza ha ancora visto.

Usa RICE per le richieste che vengono prese seriamente in considerazione e non ancora decise. Non applicarlo a ogni richiesta in arrivo; lo sforzo di valutazione si ripaga solo su quelle abbastanza vicine da avere bisogno di uno spareggio.

Bisogna pesare per fatturato, o per chi ha chiesto?

Per chi ha chiesto, ma non solo per fatturato. Un account vicino al rinnovo, un account che ha già fatto escalation, e un account la cui richiesta sblocca un affare in corso portano un’urgenza che una cifra di fatturato piatta non cattura da sola, e una richiesta da una registrazione di prova può comunque contare se blocca una decisione che presto diventa fatturato. La ponderazione per fatturato è la più facile da calcolare tra queste, e proprio per questo la più facile su cui riporre troppa fiducia: rimuove correttamente il rumore da account senza vera posta in gioco, e con la stessa facilità può declassare una richiesta che porterebbe un account molto più grande ancora nella pipeline.

Che ruolo giocano davvero i voti?

Un segnale economico e continuo per richieste che esistono già, e un pessimo modo per scoprire quali richieste dovrebbero esistere in primo luogo. Un conteggio di voti raggiunge solo gli utenti che hanno già trovato la richiesta e l’hanno ritenuta degna di un clic, il che significa che il totale dei voti di una roadmap pubblica riflette tanto la visibilità quanto la domanda: una richiesta vecchia vicino in cima alla lista continua ad accumulare voti in parte perché è facile da trovare, e una richiesta più nuova e altrettanto reale parte da zero. L’articolo sulla roadmap pubblica sostiene di lasciare del tutto i voti fuori dalla roadmap. Tratta i voti come un segnale che va raggruppato e pesato per recency, non come una classifica da costruire in ordine. Ticket di supporto vs. richieste copre l’altro punto cieco nei conteggi voti: un divario reale può generare quasi nessun voto se le utenti che ci si imbattono non trovano mai la bacheca, mentre compare rumorosamente nel supporto.

Quando vince la cliente più rumorosa, ed è un problema?

A volte, ed è un problema solo quando nessuno se ne accorge. Una cliente che fa escalation spesso, scrive ticket dettagliati o ha una linea diretta con qualcuno del team vedrà le sue richieste esaminate più in fretta di una cliente più silenziosa con una richiesta altrettanto valida, e un processo di prioritizzazione che non lo verifica mai favorirà sistematicamente chi insiste di più, non chi ha il caso più solido. Le clienti rumorose non sono il problema da correggere; le loro richieste sono spesso genuinamente importanti. La correzione è un’abitudine: passare in rassegna il backlog per origine periodicamente e verificare se lo stesso pugno di account spiega la maggior parte di ciò che è stato rilasciato di recente, e chiedersi se corrisponde a dove sta davvero la domanda.

Come si trasforma una decisione di prioritizzazione in una risposta?

Ogni decisione qui produce vincitrici e perdenti, ed entrambe meritano una risposta che nomini il ragionamento reale, non solo un cambio di stato senza spiegazione. Come rifiutare una richiesta di funzionalità copre cosa dire a una richiesta che ha perso, in un modo che mantiene intatta la relazione invece di leggersi come un rifiuto generico. Il lavoro di raggruppamento ed etichettatura che rende possibile tutto questo è coperto in tracciare le richieste di funzionalità; la prioritizzazione funziona solo su richieste già registrate e raggruppate abbastanza bene da poter essere confrontate.

FAQ

Qual è il framework migliore per dare priorità alle richieste di funzionalità? Nessuno da solo. Usa i conteggi grezzi per trovare il segnale più rumoroso, RICE per confrontare una breve lista di candidate serie, e un controllo su fatturato o account per individuare i casi in cui una domanda silenziosa da un account strategico pesa più di un gruppo più rumoroso ma meno importante.

Le richieste di funzionalità dovrebbero essere prioritizzate come le idee di roadmap? No. Le idee di roadmap partono dalla strategia; le richieste di funzionalità partono da una domanda che esiste già. Valutarle insieme fa sì che una scommessa strategica ben argomentata ma con poca domanda esistente perda costantemente contro una richiesta che semplicemente ha più persone che l’hanno chiesta.

I voti su una roadmap pubblica riflettono accuratamente la domanda? Solo tra le persone che hanno già trovato la richiesta. Le richieste più vecchie e visibili accumulano voti più in fretta indipendentemente da quanta domanda reale ci sia dietro una più nuova, quindi tratta i totali dei voti come un segnale, raggruppato e pesato per recency, non come una classifica da costruire in ordine.

Con che frequenza andrebbero rivalutate le priorità delle richieste di funzionalità? Con un ciclo fisso, non solo quando qualcuno fa escalation. Una revisione mensile o trimestrale che riraggruppa le richieste e ricontrolla la ponderazione individua le derive, come un pugno di account che domina ciò che viene rilasciato, che un processo puramente reattivo non fa mai emergere da solo.

Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.

Correlati su changeloop: Documentazione per sviluppatori, Strumenti di changelog a confronto