Come scalare la gestione dei Bug del tuo prodotto

In questo post scoprirai come implementare una gestione dei Bug più efficace e più efficiente al crescere della complessità del tuo prodotto e dei team coinvolti.

Finora, infatti, abbiamo visto come pianificare le Sprint, come gestire il backlog e alcune fasi di pianificazione, abbiamo nominato i bug in alcuni casi ma non ce ne siamo mai occupati direttamente.

E’ importante per te sapere che i Bug e la loro individuazione sono parte del lavoro del team di sviluppo e se non tenuti nella giusta considerazione il tempo dedicato al fixing potrebbe fagocitare qualsiasi buona intenzione e piano eccellente.

In principio era il caos

Sviluppo, delivery, deploy, bugfixing, brainstorming, facevano parte tutti di un unico minestrone che consentiva al prodotto di sopravvivere. Non usavo metodologie Agile, Scrum, Kanban o altro. Non sapevo neanche esattamente cosa volesse dire costruire un prodotto digitale, né esattamente cosa dovessi fare.

L’unico obiettivo era capire come avere più utenti, fare più soldi, rompendo meno cose possibile. Crescere alla velocità della luce, sopravvivendo.

Un giorno, non ricordo esattamente quando, ho scoperto che esisteva un nome per definire “quando il software era rotto” o non funzionava come ci si aspettava. Questo nome era Bug.

C’era un Bug quando il software non si comportava come ci si aspettava si comportasse, che, tra l’altro, è esattamente la definizione stessa di Bug, ovvero: un comportamento inaspettato del software.

Il Debugging, ovvero la progressiva individuazione e rimozione dei bug era un processo del tutto casuale. Sì, facevamo qualche test, ma sviluppavamo su un unico ambiente e l’unico modo per capire se il prodotto funzionava era darlo in mano agli utenti.

La cosa mi divertiva all’inizio. Avevo anche dei pupazzetti che portavo a Claudio (claudio era lo sviluppatore) e ognuno corrispondeva alla gravità del problema. Glieli portavo e rimanevano sul suo tavolo finchè il Bug veniva fixato, ovvero il software riprendeva a comportarsi “normalmente”.

Questa cosa è andata avanti per un po’. Finché eravamo pochi e con poche persone in mezzo (che poi ho scoperto che anche per loro c’era un nome, ovvero stakeholder) tutto filava liscio: i pupazzetti andavano da un tavolo all’altro e i Bug avevano vita breve. Anzi, esagerando, i bug erano i nostri migliori amici: una dimostrazione che il nostro prodotto veniva usato e che i nostri utenti ci tenevano.

Facevamo tutto a mano ed era giusto così. Poi da qualche utente che usava il nostro prodotto siamo passati a qualche decina, poi a centinaia, migliaia, decine di migliaia e così via, il prodotto cresceva di complessità e così il team e l’organizzazione.

Dovevamo scalare e, anche in questo caso, era giusto così. Ricordati sempre che scalare prima che ce ne sia bisogno è uno degli sprechi maggiori da evitare.

Anche la gestione dei bug doveva cambiare: i simpatici pupazzetti che viaggiavano da un tavolo all’altro si erano trasformati in un esercito di demoni che infestavano le nostre vite!!! Arrivavano da tutte le parti (mail, telefono, post-it, chat, riunioni, alla macchinetta del caffè, dovunque) e non riuscivamo a fermarli, si riproducevano senza sosta.

Come Scalare la gestione dei Bug

La prima cosa che tengo a precisare è che come tutto quello di cui scriviamo su product Heroes quello che leggerai non è la verità assoluta, ma il risultato di una serie di tentativi ed errori che mi hanno portato ad adattare ad ogni fase di vita dei prodotti che ho gestito diversi modi per gestire il bug fixing.

Da qui in poi diamo per assodato che la fase dei pupazzetti sia finita e che il team sia più numeroso, il prodotto con più utenti, il team con più stakeholder esterni e che ci sia estremamente più pressione nel bug fixing.

Come capire quando si è in questa fase? Semplice: quando il metodo con cui finora hai gestito i bug non è più efficiente ed efficace e bisogna necessariamente cambiare.

Di base ti renderai conto che la buona volontà degli sviluppatori nello sviluppare e fixare non basta più. E’ il momento di organizzarsi.

Inizio con alcuni consigli pratici.

Assicurati che tutti capiscano cosa è un Bug

Finchè si stava tutti vicini, era facile capire cosa fosse un bug e cosa invece una scelta, ma quando aumenta la complessità non devi dare nulla per scontato.

Esempio: quando compili un form correttamente, in una light-box, clicchi invia e il form sparisce è un Bug?

Tecnicamente potrebbe non esserlo in quanto i tuoi dati sono stati salvati, ma dal punto di vista dell’esperienza, da utente, non capisci bene cosa sia successo.

Questa immagine rende bene l’idea.

Dal punto di vista dell’utente cambia poco se è un bug o un’omissione, ma se si tratta di uno stakeholder interno all’azienda le cose sono diverse.

Dai sempre seguito alle richieste

Qualunque sia il tool che usi per la gestione dei ticket dai sempre seguito e aggiorna chi ti ha segnalato il Bug. Ancora peggio di un Bug che rende il prodotto più difficile da utilizzare c’è il non essere mai aggiornati sullo stato di avanzamento di un bug che hai segnalato.

Come sempre esagerare con la comunicazione è meglio di non comunicare.

Non lasciare agli altri la prioritizzazione dei bug

Ricordo la prima volta che abbiamo introdotto un sistema di ticket interno lasciando il campo priorità a chi apriva il ticket. Stranamente era sempre priorità massima!!!

Non lo fare mai! Ci deve sempre essere la prioritizzazione da parte del PM della gravità del Bug.

I Bug vanno sempre in Backlog, a meno che non sia necessaria la Fastlane

Consiglio spassionato: non ti far prendere da gesti magnanimi per far contento il tuo capo o il collega di turno portando un bug segnalato in risoluzione. Non farlo mai, a meno che l’impatto e la probabilità di verifica siano molto alti come vedremo dopo.

Anche se dei bug (stranamente gravi!!!) ti vengono segnalati a telefono o su slack, fai sempre in modo che quel bug venga poi inserito in un ticket e quindi passi dal backlog.

La risoluzione immediata è da concedere solo in casi estremi.

Misura l’ABA e altri indicatori 

Ogni Bug deve avere una vita e una morte! Tenere i Bug in Backlog per sempre non ha alcun senso, se non fixi dei bug dopo 9-12 mesi probabilmente non lo farai mai.

Inoltre, ha molto senso misurare quanto tempo impieghi in media per fixare un Bug (ABA: average bug age) questo ti dà un’indicazione di quanto il team stia migliorando nel tempo.

Altro Key Result che usavamo era numero di bug gravi o bloccanti/numero di bug lievi.

L’ownership è degli Sviluppatori

C’è poco da fare, un bug deriva (solitamente) da un errore nella scrittura del codice, può essere il codice appena deployato o quello precedente con cui va in conflitto, poco importa l’ownership è del team di sviluppo.

Ce lo siamo detti più volte se il WHY è del Product Manager, l’HOW è del team di sviluppo e nel caso dei bug si tratta di una scelta sbagliata o di un errore casuale.

In generale non è un problema. I bug sono la normalità se fai software, ma innescare un meccanismo per cui “allora tutto è legittimo” è completamente sbagliato.

Te lo dico perchè mi sono ritrovato in questa situazione e non è stato affatto piacevole. Ciò non significa trovare il colpevole, ma prendere atto che esiste un problema e che va risolto.

Test, Test, Test

Mi ricordo esattamente quando siamo passati da “bug is the new normal” alla quasi assenza di bug.

E’ cambiato tutto quando abbiamo iniziato ad applicare una struttura organizzativa in cui il testing era parte integrante dei nostri processi: poco importa se riesci già ad automatizzarlo o se fai ancora tutto a mano. 

La cosa più importante è che ci sia del tempo dedicato al test prima di andare in produzione. Non ti fare prendere dalla fretta, dedica il tempo giusto e vedrai che ti cambia la vita.

Sotto trovi un esempio: su 15 giorni lavorativi di sprint, 9 erano dedicati allo sviluppo e i 5 finali al test e al planning.

Ho fatto veramente fatica a cedere quei 5 giorni, ma da quel momento è cambiato tutto.

Sul test non dare nulla per scontato: identifica i sistemi operativi e i device su cui vuoi testare (fallo prima!), verifica sempre gli acceptance criteria, fai test di regressione, etc.

Inutile dire che senza ambienti separati la tua vita sarà un inferno in terra!

Un Esempio pratico e semplice di flusso per la gestione dei Bug

Nell’esempio che vedi sopra usavamo Phabricator come tool di Project Management e avevamo diversi entry point per la segnalazione dei bug: contact form e simili per gli utenti “sterni”, un Google Form e email per operation e stakeholder interni. 

Tra i vari form di contatto e “la scrittura” su Phabricator c’era l’intermediazione di una persona che gestiva il follow-up con chi aveva segnalato il bug se il problema non era chiaro o si incaricava lui stesso di risolvere la issue quando non si trattava di un bug per esempio.
I Product manager poi durante le fasi di Backlog Grooming prioritizzavano i vari Bug ed eventualmente li portavano in Sprint Backlog durante la fase di Sprint Planning.

Come prioritizzare i Bug da Fixare?

Devi prendere in considerazione due elementi principali: l’impatto e la possibilità che quel bug si verifichi.

Questa Matrice rende perfettamente l’idea.

Spesso infatti viene preso in esame solo l’Impatto del Bug, ma difficilmente la probabilità.

L’esempio tipico è il CEO dell’azienda che si spulcia dalla mattina alla sera il tuo prodotto e che (purtroppo per te) troverà sempre i bug nascosti, nonostante si tratti di “luoghi” poco o per nulla frequentati dagli utenti.

Esempio in un ecommerce: una volta riempito il carrello e inseriti i dati di carta di credito, la pagina crasha.

L’impatto è massimo in quanto rende impossibile ad un utente intenzionato a comprare la possibilità di farlo, ma se questo accade solo su utenti windows con Internet Explorer 7, la possibilità che questo si verifichi è abbastanza remota.

5-3-2: Una metodologia per la gestione dei bug (e della product Discovery).

Tra tutte le combinazioni che ho provato questa è quella che mi ha dato più soddisfazioni. Non so se esiste un nome diverso per definirla o se è un Framework già esistente. Noi ce la siamo inventati da zero dopo aver lavorato su altre soluzioni possibili per mesi.

Prima della 5-3-2 facevo la 5-5-5 😂, come Oronzo Canà, provavo a riempire lo sprint backlog di più roba possibile sperando che ce la facessimo. Non sono mai stato un tipo paziente e l’idea di dedicare parte del preziosissimo sprint backlog al bug fixing mi faceva soffrire troppo. 

Non ce la facevo. Era più forte di me.

Quando il gioco ha iniziato a farsi serio e i nostri prodotti usati da troppi utenti ho dovuto fare un passo indietro.

Come funziona la 5-3-2?

Semplicemente allochi il 50% del tuo sprint Backlog alla Delivery, 30% alla Product Discovery e il 20% al Bug Fixing.

Mi rendo conto che andrebbe fatto un post dedicato su questa metodologia e se ti interessa scrivilo nei commenti, ma in questo post la cosa importante da puntualizzare è che per la prima volta, allocavamo il 20% delle risorse esclusivamente al bug fixing.

Quando ho iniziato ad applicare la 5-3-2 era su una linea di prodotto abbastanza nuova su tecnologie che fino a quel momento avevamo usato poco, questo per dirti che la percentuale allocata al bug fixing successivamente è andata a decrescere.

La cosa importante che è cambiata è che i Bug venivano gestiti esattamente come feature, con un loro peso e una loro dignità in backlog.

Questo 20% allocato di default inoltre ci dava un grande vantaggio nei casi di bug gravi improvvisi in quanto non dovevamo togliere capacità di delivery, ma usavamo quella allocata per il bug fixing.

Un’altra metodologia che non ho provato: Fixa Tutto subito 

Non l’ho mai applicato concretamente, ma mi è stato proposto e ho letto qualcosa a proposito.

Se ti va di approfondire puoi farlo da questo link

In breve si tratta di restituire il Bug al mittente, ovvero allo sviluppatore che ha scritto il pezzo di software dove il bug si verifica.

Alcune ipotesi alla base di questo approccio:

1. Una sorta di stimolo-risposta pavloviano: Restituire il bug al mittente in teoria dovrà mettere lo sviluppatore davanti all’evidenza che il suo codice non era “buono”, e se questo accade ripetutamente lo sviluppatore (in teoria) dovrà necessariamente migliorare.
2. Limita i “danni” che un membro del team incline a scrivere codice buggato potrà causare.
3. Premia i team che scrivono codice pulito (clean code). Non mettendoli mai a debuggare.

Onestamente non l’ho mai provato, mi è stato proposto, ma ho sempre rifiutato. Se hai feedback in merito ti prego di condividerli nei commenti.