Come tracciare le richieste di funzionalità senza perderle

Il tracciamento delle richieste di funzionalità fallisce quasi sempre in uno di due modi. O le richieste non hanno un posto dove andare, quindi vivono in caselle di posta e thread Slack dove vengono dimenticate una a una, oppure hanno un posto dove andare che nessuno riguarda più, quindi vengono dimenticate tutte insieme. Un sistema che funziona deve reggere entrambi i fallimenti: serve un unico luogo dove ogni richiesta atterra, e una ragione per riaprire quel luogo il mese prossimo.

Da dove arrivano davvero le richieste di funzionalità?

Da più canali di quanti la maggior parte dei sistemi di tracciamento preveda. Un ticket di supporto che include un “sarebbe bello se”. Un commento su una roadmap pubblica. Una chiamata di vendita in cui una potenziale cliente nomina l’unica cosa che blocca l’accordo. Un widget nel prodotto. Ogni canale ha una propria responsabile e propri strumenti, ed è proprio per questo che le richieste si disperdono: la coda ticket del supporto e il backlog del team prodotto raramente sono lo stesso sistema, e una richiesta che raggiunge solo uno dei due ha, di fatto, raggiunto solo un reparto.

Un unico form di raccolta per ogni canale non funziona, perché nessuno lo adotta. Quello che funziona è una destinazione in cui ogni canale confluisce, anche se il routing sono cinque minuti al giorno di copia e incolla finché non viene automatizzato.

Cosa rompe davvero il tracciamento delle richieste?

Quasi sempre due cose. La prima è una destinazione mancante: le richieste vengono risposte nel canale in cui sono arrivate e mai registrate da nessuna parte in modo duraturo, per cui la stessa richiesta di tre clienti diversi sembra tre risposte isolate e scollegate invece di un unico segnale. La seconda, più comune, è una destinazione che si riempie e smette di essere letta. Un foglio di calcolo con 400 righe senza filtro non è più un sistema di tracciamento; è un archivio che risulta essere scrivibile.

Il secondo fallimento è il più pericoloso, perché sembra che il tracciamento funzioni. Le richieste vengono registrate. Niente sembra rotto finché qualcuno chiede “quante persone hanno chiesto X” e la risposta onesta è “dovremmo leggere tutte le 400 righe per saperlo”.

Cosa dovrebbe registrare davvero una richiesta di funzionalità?

Abbastanza per rispondere a tre domande in seguito senza rileggere il messaggio originale: cosa è stato chiesto, possibilmente con le parole di chi ha fatto la richiesta; chi ha chiesto, e come contattarla se la risposta finisce per essere “l’abbiamo costruito”; e cosa servirebbe per capire se è una richiesta comune o un caso isolato. Una citazione testuale conta più di una parafrasi, perché una parafrasi scritta da chi ha smistato la richiesta porta già la sua lettura, ed è proprio quella lettura che una seconda persona non può verificare sei mesi dopo.

Quali etichette valgono la pena?

Due, e rispondono a domande diverse. Un’etichetta di tipo separa una richiesta di funzionalità da un bug report, perché entrambi richiedono responsabili e tempistiche diverse, e mescolarli in una coda sola lascia che le lamentele più rumorose spostino le richieste. Un’etichetta di priorità, mantenuta a un piccolo insieme come low, medium e high, separa “blocca qualcuno nell’uso del prodotto” da “sarebbe carino”, perché entrambe meritano tempi di risposta molto diversi e nessuna dovrebbe ereditare il ritmo dell’altra. Mettere correttamente l’etichetta di tipo presuppone che la richiesta sia quello che dice di essere; quando una richiesta di funzionalità è in realtà un bug copre il caso in cui le parole stesse di una cliente puntano quell’etichetta nella direzione sbagliata.

Il triage automatizzato può applicare entrambe nel momento in cui arriva la richiesta. In changeloop, un invio dal widget riceve l’etichetta feature-request o bug e un’etichetta priority:low|medium|high nello stesso passaggio, più un tag from-widget così l’origine è visibile senza aprire l’elemento. Basta per filtrare il backlog in un minuto invece che in un pomeriggio: mostrami ogni richiesta di funzionalità ad alta priorità arrivata dal widget questo mese.

Una terza etichetta vale la pena appena esiste una roadmap pubblica: uno stato che chi ha fatto la richiesta può controllare da solo. Roadmap pubblica copre per intero gli stati planned, building e shipped; in breve, quell’etichetta trasforma una coda privata in qualcosa che chi ha fatto la richiesta può consultare senza chiedere di nuovo.

Come si decide cosa costruire dopo?

Raggruppare prima di contare. Dieci richieste formulate in modo diverso per la stessa capacità sottostante si leggono come dieci righe disperse in un foglio di calcolo, e come un segnale forte appena raggruppate, e quel raggruppamento è di solito il passaggio mancante, non il conteggio. Un conteggio grezzo senza raggruppamento tende a premiare la funzionalità con il nome più accattivante, non quella con più domanda reale dietro.

Pesare in base a chi chiede, non solo a quanti chiedono. Una richiesta da un account vicino al rinnovo porta un’urgenza diversa dalla stessa richiesta da una registrazione di prova, e un sistema di tracciamento che scarta questo contesto a favore di un conteggio nudo sta ottimizzando per il numero più facile da calcolare, non per quello più utile.

Ogni decisione qui produce anche richieste che perdono, e anche quelle meritano una risposta; come rifiutare una richiesta copre cosa dire a chi ha fatto una richiesta che non ce l’ha fatta. Raggruppare e pesare è solo metà di “cosa costruire dopo”; come dare priorità alle richieste di funzionalità copre i framework veri, RICE, ponderazione per fatturato e conteggi grezzi, e dove ognuno si rompe.

Come si chiude il cerchio una volta rilasciato qualcosa?

Questo è il passaggio che i sistemi di tracciamento saltano più spesso, ed è quello che chi ha fatto la richiesta nota davvero. Chiudere il ciclo di feedback con il cliente copre la meccanica per intero; ciò che conta qui è che chiudere il cerchio funziona solo se la richiesta originale è rimasta collegata a chi l’ha fatta. Un template di richiesta di funzionalità costruito da un issue GitHub, con l’identità di chi ha chiesto legata all’issue invece che sepolta in un commento, è ciò che rende possibile una notifica automatica di “rilasciato” invece di una che qualcuno deve ricordarsi di inviare. Template di richiesta di funzionalità mostra il template concreto e a cosa serve ogni campo.

FAQ

Che strumento dovrei usare per tracciare le richieste di funzionalità? Ciò che il team già controlla ogni giorno batte qualsiasi strumento dedicato che nessuno apre. Un tracker di issue GitHub funziona bene se l’ingegneria vive già lì; una board leggera funziona bene se il prodotto vive lì. Lo strumento conta meno del fatto che venga riaperto.

Come evito che le richieste di funzionalità si duplichino? Raggruppare per capacità sottostante prima di smistare per formulazione. Una ricerca tra le richieste esistenti prima di aprirne una nuova intercetta la maggior parte dei duplicati; un passaggio mensile di raggruppamento intercetta il resto. Unire i duplicati senza perdere la voce originale copre cosa fare con la formulazione una volta fatto il raggruppamento in sé, così la fusione non restringe silenziosamente la richiesta a qualunque segnalazione sia arrivata per prima.

Ogni richiesta di funzionalità dovrebbe ricevere una risposta? Ognuna dovrebbe ricevere una conferma, anche breve, ma non ognuna ha bisogno di una decisione subito. Uno stato visibile, come un’etichetta di roadmap che chi ha chiesto può controllare da solo, sostituisce la maggior parte delle risposte individuali che un team dovrebbe altrimenti.

Qual è la differenza tra tracciamento delle richieste e roadmap pubblica? Il tracciamento è il registro interno di ogni richiesta, incluse quelle che non verranno mai rilasciate. Una roadmap pubblica è il sottoinsieme a cui un team si impegna pubblicamente, con uno stato che chi ha fatto la richiesta può vedere senza chiedere di nuovo.

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