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 ridursi a una sola riga di codice. Tuttavia, il lavoro che la circonda — 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 coinvolti — spesso costituisce la parte più consistente dell’intero processo. Nulla di tutto ciò è riportato nel ticket. Tutto ciò rallenta la velocità di sviluppo.
Si devono stimare due aspetti: la correzione e la risposta. La correzione segue le normali regole del planning poker. La risposta, invece, è un concetto poco familiare ai team di ingegneri e viene sistematicamente sottostimata — motivo per cui i bug segnalati dai clienti sembrano protrarsi per tutto lo sprint anche quando il voto sul mazzo di carte era basso.
Ciò che viene detto nella stanza
Backend: “La correzione consiste in una sola riga.”
PM: «Quale account lo ha segnalato?»
Assistenza: “Il loro responsabile del servizio clienti richiede un’analisi delle cause alla radice entro venerdì.”
Responsabile: “Ci sono altri clienti coinvolti? Dobbiamo inviare loro un’e-mail?”
QA: “È possibile riprodurre il problema utilizzando i loro dati, oppure è necessaria un’esportazione con i dati anonimizzati?”
Domande che vale la pena 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 è riportata in questo ticket?
- Riproduzione: dati del cliente, dump anonimizzato o dati sintetici?
La suddivisione è utile: la correzione è un ticket, la risposta è un altro. Entrambi vengono sottoposti al “planning poker”; solo uno dei due riguarda l’aspetto tecnico.
Si prega di stimare separatamente il costo della riparazione e quello della risposta. È il nome dell’account a determinare l’entità della risposta.
Si veda Errori comuni nel Planning Poker per quanto riguarda le modalità di insuccesso del voto su attività che non rientrano nelle competenze del gruppo. Si consultino gli altri esempi di stime efficaci, oppure si avvii una sessione gratuita di Planning Poker con entrambe le storie già pronte.