Quando una richiesta di funzionalità è in realtà un bug

“Potete aggiungere un’impostazione per aumentare il limite di esportazione?” si legge come una richiesta di funzionalità, e la maggior parte dei sistemi di triage la etichetta così sul posto. A volte lo è. A volte l’esportazione fallisce a un numero sotto il limite documentato per colpa di un bug, e la cliente, incapace di vedere il codice, ha inventato la soluzione più plausibile che sa descrivere: datemi un numero più grande e forse funzionerà. Quali etichette valgono la pena copre l’etichetta di tipo che divide un backlog in richieste di funzionalità e bug; questo è il caso in cui le parole stesse di una cliente puntano l’etichetta nella direzione sbagliata, e il costo di sbagliare è una deriva lenta verso un backlog pieno di richieste che nessuno vuole davvero una volta guardato sotto.

Come si presenta una richiesta di funzionalità che in realtà è un bug?

Nomina un workaround invece del problema. Una richiesta di funzionalità genuina di solito descrive un risultato che il prodotto non supporta affatto: “lasciatemi programmare questo per dopo”, “aggiungete una modalità scura”. Un bug mal classificato descrive un numero, una soglia o un comportamento specifico che suona come un’impostazione mancante ma in realtà è un sintomo: “aumentate il timeout”, “aggiungete un’opzione di retry”, “lasciatemi esportare più righe alla volta”. Il segnale è che chi chiede propone un’implementazione, un’impostazione, un interruttore, un override, invece di descrivere un obiettivo, perché ha già provato la funzionalità come documentata e non ha fatto quello che la documentazione dice che dovrebbe fare.

Perché questo conta più di quanto sembri?

Perché le due code hanno responsabili, tempistiche e criteri di successo diversi, e un bug archiviato come richiesta di funzionalità viene prioritizzato contro le richieste di funzionalità, competendo per l’attenzione con lacune di prodotto reali invece di essere risolto secondo la tempistica che un bug merita. Come tracciare le richieste di funzionalità copre perché mescolare bug e funzionalità in una sola coda lascia che le lamentele più rumorose spostino le richieste reali; una richiesta di funzionalità che in segreto è un bug fa il danno opposto, resta nel backlog di prodotto accumulando voti per una “funzionalità” che sparirebbe non appena il bug sottostante venisse risolto, il che spreca il segnale di prioritizzazione per chiunque legga quel backlog.

Come si distingue quando le parole stesse della cliente puntano nella direzione sbagliata?

Chiedete cosa si aspettava che succedesse, non cosa vuole che aggiungiate. “L’esportazione si è fermata a 500 righe e me ne servono 2.000, potete alzare il limite” suona come una richiesta di funzionalità di aumento del limite finché la domanda di follow-up, “500 è il limite documentato”, non rivela che il numero documentato era 5.000 e l’esportazione fallisce in anticipo. Quella sola domanda, cosa si aspettava contro cosa è successo, fa la maggior parte del lavoro di classificazione, perché una richiesta di funzionalità genuina non ha un comportamento documentato a cui viene meno; non c’è niente da aspettarsi perché la capacità ancora non esiste.

Dovrebbero decidere gli agenti di supporto o le ingegnere?

Gli agenti di supporto fanno il primo passaggio, perché vedono il ticket per primi, ma l’etichetta dovrebbe essere facile da cambiare ed economica da sbagliare, non una decisione una tantum che fissa l’elemento nella coda sbagliata per sempre. Un secondo controllo leggero, un’ingegnera che scandaglia settimanalmente le nuove etichette “richiesta di funzionalità” per qualcosa che puzza di bug travestito, cattura quelle che un agente di supporto senza contesto sul codice non avrebbe potuto riconoscere. Non deve essere formale; è più uno sguardo di cinque minuti che un processo di revisione.

Chiudere il ciclo cambia una volta trovato il bug vero?

Sì, e migliora il messaggio che potete inviare. Chiudere il ciclo di feedback del cliente copre l’avvisare chi ha chiesto quando qualcosa viene rilasciato; un bug ricategorizzato riceve una versione migliore di quel messaggio, perché “abbiamo trovato e risolto il bug dietro a questo” suona come competenza, mentre “abbiamo costruito la funzionalità che avete chiesto” sarebbe stato vero solo per caso, perché la vera richiesta di funzionalità, un limite di esportazione davvero più alto, potrebbe non venire mai costruita una volta che il bug è sparito e il limite originale di 5.000 righe basta.

Cosa succede se la classificazione sbagliata non viene mai colta?

Il backlog si riempie di richieste che sembrano domanda reale e non lo sono, e le decisioni di prioritizzazione prese contro quel backlog ereditano la distorsione. Una “funzionalità” con quaranta voti potrebbe in realtà essere quaranta persone che incontrano lo stesso bug, e costruire la richiesta letterale, un’impostazione per alzare un limite che non era mai stato davvero il vincolo, consegna complessità che non risolve niente, mentre il bug sottostante continua a generare nuove “richieste di funzionalità” da clienti che non hanno ancora trovato questo thread.

FAQ

Vale la pena aggiungere un passaggio formale per controllare ogni richiesta di funzionalità contro bug noti? Non un passaggio formale, piuttosto un’abitudine: chiunque triagi una nuova richiesta di funzionalità dovrebbe chiedere “il comportamento documentato afferma già di fare questo” prima di applicare l’etichetta, perché quella sola domanda cattura la maggior parte delle classificazioni sbagliate senza aggiungere sovraccarico di processo.

E se la cliente insiste che è una richiesta di funzionalità anche dopo che il bug è stato trovato? Spiegate cosa avete trovato e perché l’impostazione che proponeva non servirebbe più una volta risolto il bug. La maggior parte delle clienti chiede un workaround perché ha assunto che la vera soluzione non fosse disponibile, non perché volesse specificamente quell’impostazione.

Un elemento ricategorizzato perde i voti o i commenti che ha accumulato come richiesta di funzionalità? Dovrebbe conservarli, visibili, perché quei voti sono la prova che ha portato a trovare il bug in primo luogo, e nascondere quella traccia rende più difficile cogliere la stessa classificazione sbagliata la prossima volta, su un ticket diverso.

Può succedere al contrario, un bug che in realtà è una richiesta di funzionalità? Meno spesso, ma sì: “questo è rotto” a volte significa “questo non fa quello che ho assunto che facesse”, che è una capacità mancante, non un difetto. La stessa domanda, cosa si aspettava contro cosa è documentato, classifica anche in questa direzione.

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