Stima di un bug segnalato da un cliente
Come valutare un bug segnalato da un cliente: è l’account indicato nel ticket a determinare l’entità del problema. Come distinguere una correzione di una sola riga da una risposta che compromette lo sprint.
Il problema non è la dimensione. È il cliente a determinare la dimensione.
Un bug segnalato da un cliente comporta una portata che il team non è in grado di cogliere solo dal ticket. La correzione tecnica potrebbe consistere in una sola riga di codice. Tuttavia, il lavoro correlato rappresenta spesso la parte più consistente dell’intervento: riprodurre il problema sui dati del cliente, redigere un’analisi post-incidente, preparare la risposta, decidere se accreditare l’account, comunicare con gli altri clienti interessati. Nulla di tutto ciò è riportato nel ticket. Tutto ciò incide negativamente sulla velocità di elaborazione.
Si devono stimare due aspetti: la correzione e la risposta. La correzione consiste nel normale “planning poker”. La risposta, invece, è un concetto poco familiare ai team di ingegneri e viene sistematicamente sottostimata; ecco perché i bug segnalati dai clienti sembrano protrarsi per tutto lo sprint anche quando il voto sul mazzo di carte è risultato basso.
Ciò che viene detto nella stanza
Backend: “La correzione consiste in una sola riga.”
Primo Ministro: «Quale fonte lo ha riportato?»
Assistenza: “Il loro responsabile del servizio clienti richiede un’analisi delle cause alla radice (RCA) entro venerdì.”
Responsabile: “Ci sono altri clienti coinvolti? Dobbiamo inviare loro un’e-mail?”
Domanda di controllo qualità: “È possibile riprodurre il problema utilizzando i loro dati, oppure è necessaria un’esportazione dei dati anonimizzata?”
Domande da porsi prima di votare
- Chi ha segnalato il problema e quali sono i relativi valori di ARR, SLA o lo stato del contratto?
- È necessario effettuare una valutazione RCA o un’analisi post mortem a livello esterno?
- Ci sono altri account coinvolti e come possiamo scoprirlo?
- È necessario concedere un credito, effettuare un rimborso o prorogare il periodo di prova?
- Chi redige la risposta destinata al cliente? E tale risposta è contenuta in questo ticket?
- Riproduzione: dati del cliente, dump anonimizzato o dati sintetici?
La suddivisione è utile: la correzione è un ticket, la risposta è un altro. Entrambi passano attraverso il “planning poker”; solo uno dei due riguarda l’aspetto tecnico.
Si prega di fornire una stima separata per la correzione e per la risposta. È il nome dell’account a determinare l’entità della risposta.
Si vedano gli errori più comuni nel Planning Poker relativi alla modalità di fallimento della votazione su attività che non rientrano nelle competenze del team. Si consultino gli altri esempi di stima già elaborati oppure si avvii una sessione gratuita di Planning Poker con entrambe le storie già pronte.