Bug Fixing: ‘innamorarsi del problema’ è possibile?

Sì, ed è il consiglio più sdoganato da condividere con chi si occupa di prodotto o ha intenzione di fondare una startup. In questo articolo vi racconto come Adopto aiuta i Product Team con il Bug Fixing

La nostra avventura come startup ha inizio con un team composto da: un product manager, un tech lead, uno sviluppatore full-stack, un designer UI e una user researcher. Accomunati dal desiderio di creare qualcosa di nuovo, ci stacchiamo dalla realtà in cui lavoravamo su prodotti SaaS enterprise per inseguire il sogno che ci accomuna: fare prodotto.

Una startup composta all’80% da builders che amano fare solo una cosa: costruire soluzioni. Come Dan Olsen ci insegna, “We live in the solution space”, e questo è probabilmente ancor più vero se parliamo di un tech team.

Noi, e come tanti prima di noi, abbiamo provato a seguire una scorciatoia: validare la soluzione senza aver prima validato il problema. Abbiamo iniziato quest’avventura con una soluzione che ci portavamo dietro dall’esperienza passata, cercando di inventarci un problema e un segmento di mercato a cui venderla. Un po’ come quando da bambino giochi con le formine geometriche e cerchi di far entrare il cerchio dove andrebbe un quadrato. In poche parole? Un incubo.

L’importanza della problem discovery per il bug fixing

Come la maggior parte di voi saprà, quello che dovresti fare prima di sviluppare un prodotto non ha nulla a che fare col costruire e sviluppare soluzioni. Il tuo tempo e le tue energie dovrebbero essere dedicate al problem discovery che vanno dalle customer interviews, alle ricerche di mercato, alle analisi dei competitors. Fortunatamente (o sfortunatamente?), ci abbiamo sbattuto la testa anche noi e siamo rinsaviti giusto in tempo. Quando ci siamo accorti che la soluzione non avrebbe funzionato – perché non ancorata ad un problema sentito e validato -, abbiamo tirato il freno a mano e abbiamo fatto pivot.

Ci siamo armati di pazienza e abbiamo iniziato la nostra ricerca di un problema che valesse la pena risolvere e che ci appassionasse. Abbiamo deciso così di esplorare i processi che sono propri di tutti i team di prodotto: quelli che hanno a che fare con lo sviluppo di nuove feature e la risoluzione di problemi tecnici e bug. Ovviamente, i bug ci sembravano più sexy delle nuove feature.

Bug Fixing: come vengono segnalati i bug?

Abbiamo quindi passato gli ultimi quattro mesi a fare customer discovery, interviste ai potenziali customer, a parlare con loro su LinkedIn, su vari Reddit, canali di Discord, e su Slack in tante community di prodotto (vi suggerisco di entrare in Mind the Product, The Product Folks e The Product Coalition. Sono tutti molto disponibili e generosi con i feedback).

Come potete immaginare, la difficoltà che provavamo era sempre la stessa: inibire la tentazione di scappare e rifugiarsi nel “solution space” ogni qual volta le risposte faticavano ad arrivare. Ma abbiamo tenuto duro, spaventati soprattutto dall’ennesimo pivot che volevamo evitare. Così, dopo aver consultato un centinaio di persone tra product manager, agenti di customer support, e account manager di aziende di diversa grandezza, business model, e industria, abbiamo validato che effettivamente c’è un problema legato alla segnalazione di bug. 

Segnalazione di un bug: il “ping pong” infinito

Nonostante le singole peculiarità che sono proprie di ogni azienda, il processo attualmente in piedi in tantissime aziende può essere semplificato così: bug e presunti tali trovati da utenti finali vengono riportati al customer care e customer support, che poi ha l’ingrato compito di interpretare il problema e raccogliere manualmente informazioni tecniche spesso difficili da ottenere. Immaginatevi, per esempio, di chiedere ad un utente medio di condividere lo schermo e utilizzare il browser inspector per poter leggere i log della console e di riportarle in un sistema di ticketing più o meno strutturato.

Questo processo porta ad un “collo di bottiglia”: il team di sviluppo/prodotto responsabile della risoluzione del bug riceve un report molto spesso poco dettagliato, che non permette di identificare gli step per riprodurre l’errore, e le specifiche tecniche necessarie per identificare se è un bug reale o un problema specifico (ad esempio di device o di sistema operativo).

Una volta aperto il ticket, inizia una conversazione tra coloro che sono responsabili della risoluzione del bug e gli stakeholder che l’hanno segnalato. Si fa avanti e indietro diverse volte per chiedere e ottenere i dettagli mancanti, a volte anche dovendo ritornare all’utente finale che aveva trovato il bug. Questo “collo di bottiglia” è sentito molto dal team tecnico e, oltre ad essere frustrante, è un ping pong infinito che fa perdere tantissimo tempo a tutti gli attori coinvolti, senza assicurare di fatto che si arrivi ad un’effettiva risoluzione del problema.

Abbiamo raccolto alcuni degli spunti più interessanti che abbiamo ritrovato lungo il cammino. Mi piacerebbe condividerli anche con voi.

Bug Fix: Non c’è bisogno di un processo, finché non ce n’è bisogno

La prima cosa che abbiamo imparato durante le nostre customer interview è che c’è un momento in cui ti rendi conto che il team non può più sopravvivere senza un processo di bug reporting. Abbiamo notato che si passa dal ricevere chiamate e messaggi istantanei su Slack da chiunque trovi o creda di aver trovato un bug, all’avere uno spazio dedicato che raccoglie tutte le segnalazioni.

Si passa da una versione basic tipo uno spreadsheet condiviso ad un canale Slack #issues dove il team di sviluppo riesce a raccogliere tutte le segnalazioni inviate dai colleghi. I più bisognosi e audaci, invece, arrivano alla creazione di veri e propri template (o form) per guidare i colleghi alla raccolta di determinate informazioni utili per riprodurre e fare triage del bug, e poterne definire la priorità nel backlog.

Risoluzione di un bug: ecco come facilitare il processo

Quale sono i dettagli che, se presenti nella segnalazione, facilitano ed efficientano questo processo di risoluzione del bug? 

• Dove si è riscontrato il bug: ovvero tutte quelle informazioni che permettono di escludere problemi non specifici al prodotto in sé, come device, sistema operativo, browser, versione dell’app, e, se possibile, lo user ID;
• Step per riprodurre il bug: azioni che hanno portato l’utente a imbattersi nel malfunzionamento. La regola è “più si scende nel dettaglio, più è utile”. Solitamente queste informazioni si ottengono chiedendo all’utente di raccontare il processo che l’ho portato a trovare il bug;
• Comportamento desiderato: molto spesso quelli che vengono riportati come bug altro non sono che scelte più o meno fortunate di UI o UX, che creano una frizione nell’utilizzo del prodotto. Per poter riconoscere questi “non-bug”, è importante chiedere di esplicitare cosa l’utente si sarebbe aspettato succedesse;
• Informazioni tecniche: in un mondo ideale, fare front-loading (cioè anticipare potenziali problemi) aiuta ad efficientare il processo di risoluzione dei bug. È per questo che si dovrebbero raccogliere immediatamente tutti i dati tecnici che potrebbero aiutare gli sviluppatori ad identificare il problema (tipo le richieste di network e i log della console). Queste informazioni sono utili quando non è facile risalire al problema, eppure raccoglierle rappresenta uno scoglio per i colleghi non tecnici che interagiscono direttamente con i clienti e gli utenti. (Immaginatevi di chiedere all’utente di condividere lo schermo e attivare il browser inspector per poter raccogliere i log. Un po’ estrema come situazione, soprattutto con utenti meno esperti a livello digitale);
• Priorità: una stima più o meno esatta della priorità con cui si dovrebbe agire sul bug. L’idea è per il team di sviluppo di avere qualcosa a cui aggrapparsi quando si stabiliscono le task per lo sprint. Questa metrica può essere derivata da diversi fattori, come la quantità di utenti che sperimentano il problema o l’importanza della funzionalità che risulta malfunzionante, ma anche l’impatto economico del cliente che ha segnalato il bug sulla revenue.

La realtà è che – nonostante tutto l’impegno per incanalare gli sforzi dei colleghi attraverso un template -, c’è sempre qualcuno che non ci casca e che preferisce alzare il telefono o inviare un messaggio direttamente su Slack al product manager o allo sviluppatore di turno. E qui passiamo al secondo punto.

Bug: i template sono utili, ma non sono abbastanza

Abbiamo tutti incontrato almeno una volta un collega che si rifiutava categoricamente di utilizzare uno strumento nuovo che avrebbe facilitato e velocizzato non solo il suo lavoro, ma anche quello di tutti gli altri. La curva di adozione per uno strumento digitale di questo tipo segue la forma sinusoidale della curva di adozione di qualsiasi innovazione tecnologica introdotta negli ultimi due secoli (qui in basso una rappresentazione visiva da The New York Times).

Quello che è importante e da tener a mente è che, per qualsiasi nuovo strumento e processo interno da implementare, incontreremo un uno o due colleghi su dieci che saranno entusiasti e felici di provare qualcosa di nuovo – i cosiddetti innovator ed early adopter. Dei restanti otto, sette avranno bisogno di essere convinti, spinti e ingaggiati anche solo per fare una prova, mentre uno o due probabilmente remeranno sempre contro. Questa è la verità, fa male, ma prima l’accettiamo e meglio sarà.

Bug Fixing: la priority non è matematica

Parlando con molti product manager abbiamo identificato un altro pain point molto sentito: nonostante le indicazioni – se presenti – sul come stimare il livello di priorità per la risoluzione del bug, le segnalazioni ricevute da colleghi non tecnici sono caratterizzate sempre da “Priorità alta”.

“Figurati, la priorità è alta anche quando parliamo di un refuso o un problema di allineamento di un bottone nell’interfaccia del back-office”, ci hanno confidato in molti. 

Questo è uno di quei casi in cui è difficile cavare il ragno dal buco: ogni team ha i suoi obiettivi e i suoi KPIs di successo. Se chiediamo ad un agente di customer support, ci dirà che il suo KPI è chiudere il ticket di assistenza il prima possibile. Se lo domandiamo ad un account manager, la risposta sarà una retention rate alta e un NPS superiore a 9. Di fatto, aiutare l’utente o il cliente insoddisfatto e assicurarsi di essere veloci ed efficienti nel farlo ha altissima priorità per questi due ruoli, che sono di solito i più attivi nel riportare bug e malfunzionamenti tecnici. 

L’unica cosa da fare è prendere coscienza di questo fattore, mostrare empatia – eh sì, proprio quella che cerchiamo di utilizzare con i nostri utenti – verso colleghi che hanno obiettivi diversi, e prepararvi a fare un bug triage indipendente e ottimizzato, a prescindere dal livello di priorità segnalato. E qui passiamo al prossimo punto: la comunicazione (a volte insoddisfacente) tra team di sviluppo e i colleghi non tecnici. Un tema importante e di cui abbiamo parlato in questo articolo dedicato alle hard e soft skill del product manager.

Bug Tracking: il “Sì, certo! Ti farò sapere” non funziona 

Il team di prodotto ha dei KPIs molto diversi rispetto a quelli dei colleghi in sales o in customer care. Proviamo a fare un piccolo gioco di ruolo mettendoci nei panni di questi poveri colleghi di sales o customer care.

Utilizziamo un po’ di quell’empatia di cui abbiamo parlato sopra: un cliente mi segnala un problema tecnico, a mia volta passo parola al team tecnico cercando di racimolare quante più informazioni possibili (anche se sono sicuro che lo sviluppatore non sarà soddisfatto). Va da sé che il mio bisogno è poter avere una visione costante dell’avanzamento della segnalazione, così da poter dimostrare al cliente che mi ricontatterà domani che non mi sono dimenticato di ciò che mi ha segnalato, ho prestato attenzione e mi sto assicurando che il suo problema venga risolto prima possibile. Piuttosto semplice empatizzare con questo collega, vero?

Eppure,quello che è venuto fuori da conversazioni fatte con operatori di customer care è che i “Sì, certo! Ti farò sapere” che ricevono spesso dal team di sviluppo non soddisfano questo bisogno e, soprattutto, non danno loro la possibilità di fare bene il proprio lavoro. Ovviamente, poi non possiamo aspettarci che la stessa persona faccia quell’extra mile per procurarci tutti i dettagli tecnici che renderebbero il nostro di lavoro più facile e meno frustrante, o mi sbaglio?

Le aziende che credono ad allineamento vero tra prodotto e sales/customer care spendono un po’ di più e garantiscono ai colleghi non tecnici l’accesso sulle piattaforme di gestione di task (e.g., Jira, Trello o ClickUp per menzionare le più diffuse). Così, quando la task avanza, il collega riceve un’email e sa cosa dire al cliente frustrato che lo ricontatterà l’indomani.

Segnalazione bug: il QA testing non è abbastanza

L’ultimo punto riguarda il tema del testing e qui si scontrano opinioni contrastanti. Sulla carta, tutti i team di prodotto sanno quanto sia importante avere in pipeline un momento dedicato a testare prima del rilascio in produzione. Idealmente, questo momento dovrebbe servire per assicurarsi che il codice non presenti errori, il cosiddetto Quality Assurance (QA) testing, ma anche che l’esperienza utente e l’usabilità dell’app siano ottimizzate (User Acceptance Testing o UAT). Tutti sanno che questo è ciò che dovrebbe succedere nel mondo ideale.

Eppure, circa la metà delle persone con cui abbiamo parlato ci ha confidato di non avere risorse dedicate a queste attività di testing. In alcuni casi è il product manager che si smazza il task, provando il prodotto e mettendosi nei panni del dummy user che clicca cose a caso. A volte è lo stesso sviluppatore che testa ciò che ha sviluppato: in questo caso, però, ci sono diverse opinioni sulla validità o meno di un test fatto dallo stesso sviluppatore che ha scritto il codice (in questo articolo trovate alcuni spunti interessanti sul tema).

Ci sono aziende in cui il QA testing non solo è fatto bene, ma viene anche efficientato in modo da evitare il più possibile errori umani. Ad oggi, ci sono tantissimi strumenti che permettono di ricevere segnalazioni di errore di codice in modo automatizzato. Il problema è che i bug riportati non sono sempre bug nel senso stretto del termine, ma spesso sono il risultato di scelte infelici di UI/UX che l’utente percepisce come malfunzionamenti tecnici. Su questo tema, avevamo anche dedicato un articolo ad hoc su come scalare la gestione dei bug del tuo prodotto.

Questi casi riflettono la maggioranza delle segnalazioni ricevute secondo i product manager che abbiamo intervistato. Purtroppo non c’è molto da fare se non armarsi di tanta, tanta pazienza.

Come si risolve un bug più velocemente

Vi domanderete, dunque, come finisce la storia della nostra startup che ha imparato a fare customer e problem discovery? Dopo aver intervistato i product manager e aver individuato il problema, e a seguito del job-to-be done con i vari pain point associati, ci siamo finalmente spostati nel solution space.

È qui che abbiamo iniziato a definire e costruire Adopto Bug Fix, lo strumento che permette ai team di prodotto di poter ricevere segnalazioni di bug dettagliate e veloci senza dover fare avanti ed indietro, sprecando tempo e risorse preziose in conversazioni con customer care e utenti finali.

Immaginate il seguente scenario: un utente si mette in contatto con il customer care per segnalare un problema tecnico, l’agente di supporto dovrà chiedere all’utente di premere una semplice combinazione di tasti sulla tastiera o di cliccare su un bottone visibile sull’app, e successivamente di riprovare a compiere l’azione che ha portato all’errore.

Adopto Bug Fix funziona attraverso uno snippet di codice che viene inserito nella piattaforma target. Si comporta come Siri: esiste ma è silente ed invisibile agli occhi degli utenti solo finché non viene attivato. Successivamente all’attivazione (tramite una combinazione di tasti o attraverso un bottone), Adopto inizia a registrare la sessione in corso, raccogliendo una serie di informazioni.

Tra le informazioni raccolte abbiamo:

• Uno screen recording delle azioni effettuate dall’utente fino al problema tecnico;
• Le user action;
• I log della console;
• Le richieste del network;
• Le formazioni relative a device, sistema operativo, risoluzione dello schermo, user id, eccetera.

Tutti questi dati strutturati vengono poi condivisi in un report accessibile dalla nostra piattaforma. Il report può essere facilmente condiviso su qualsiasi strumento di gestione di task. In questo modo, si può sfruttare il processo già esistente di comunicazione dello stato di avanzamento della segnalazione.

Ad oggi siamo in fase Beta, significa che stiamo migliorando l’esperienza utente e sviluppando nuove funzionalità con l’aiuto di alcuni team di prodotto. Questi sono team relativamente giovani (non parlo di età anagrafica, ma di maturità del prodotto), che hanno una webapp attivamente in sviluppo, che ricevono molte segnalazioni incomplete da utenti e colleghi non tecnici, e che hanno provato a risolvere il problema con un processo che sfortunatamente non ha dato i risultati aspettati.

Se anche tu vuoi scoprire come gestire al meglio i bug informatici del tuo prodotto e credi che Adopto potrebbe facilitare la tua vita e quella del tuo team, visita la nostra landing page ed entra a far parte del nostro programma Beta!

Il tuo feedback sarà prezioso per migliorare l’esperienza utente e sviluppare nuove funzionalità del nostro Adopto!