Come siamo riusciti a zero bug e implementato una politica di zero bug

Quindi, quanti bug hai nel tuo backlog? Centinaia? Di Più? Di meno? Non sei del tutto sicuro? Bene, posso dirti quanti bug ci sono nel nostro backlog in questo momento. Il numero di bug nel nostro backlog è ... aspettalo ... ZERO. Zero, zilch, nada. Non stai leggendo questo male. Abbiamo zero bug nel nostro backlog. - Non solo abbiamo zero bug nel nostro backlog, ma prevediamo di mantenerlo così con la nostra politica Zero Bug. Come abbiamo raggiunto questo traguardo incredibile e come prevediamo di aderire allo Zero Bugs andando avanti? La risposta non è così complicata come si potrebbe pensare, ma non senza alcuni ostacoli.

Innanzitutto, un po 'di storia

Poco più di 2 anni fa, quando mi sono unito a ConceptShare per guidare il Quality Team, nel backlog c'erano oltre 350 bug documentati (non pazzi, ma neanche piccoli). La mia prima domanda dopo aver scrutato profondamente l'abisso è stata “Posso eliminare tutti i bug che hanno più di un anno? Che dire di tutti i bug che hanno più di sei mesi.? ”La risposta, ovviamente, era No: c'era una conoscenza contenuta in quell'esteso elenco di bug, conoscenza che potremmo usare per migliorare la qualità del nostro prodotto e, a sua volta, migliorare il esperienza per i nostri clienti. Allo stesso tempo, avevamo ancora bisogno di un modo per affrontare l'arretrato di vecchi bug insieme a tutti i nuovi bug che avevano un impatto sull'esperienza del cliente E continuare lo sviluppo di nuove funzionalità e miglioramenti del prodotto.

Perché è importante avere zero bug?

Avere bug nel backlog che raccoglie polvere fa davvero schifo.

  1. Fa schifo per i nostri clienti perché i bug influiscono sulle prestazioni del nostro prodotto per loro - non ci piace. Vogliamo che i nostri clienti utilizzino e sperimentino il nostro prodotto nel modo in cui doveva essere sperimentato: niente soluzioni alternative, niente "oopsie, ci siamo persi", non "lo scopriremo ... una volta risolti questi altri bug ...". La nostra politica progressiva pone i nostri clienti in primo piano, permettendoci di concentrarci sulla loro esperienza con il nostro prodotto e spostando la conversazione da "Sarebbe bello se ConceptShare facesse correttamente X" a "Funzionava alla grande! Esploriamo altri modi in cui ConceptShare può aiutarci a fare il nostro lavoro ".
  2. Fa schifo per i nostri Creative Operations Advisors, che sono il nostro supporto in prima linea per i nostri clienti. Invece di dedicare il loro tempo a sentire le stesse lamentele dei clienti riguardo a bug noti e non essere in grado di fornire una vera linea temporale su quando saranno in atto le correzioni, possono trascorrere il loro tempo a mostrare ai nostri clienti i nuovi ed eccitanti modi in cui ConceptShare li aiuta a lavorare fatto. Ciò significa che possono spostare la loro attenzione dal servizio clienti al supporto del vero successo del cliente.
  3. Infine, fa schifo per il nostro team di sviluppo prodotto. La navigazione tra le carenze esistenti durante la creazione di nuove funzionalità aggiunge tempo e complessità inutili al loro lavoro, il che significa meno funzionalità e miglioramenti, che alla fine incidono sui nostri clienti. Essere in grado di dire "quale grande cosa stiamo spedendo dopo?" È incredibilmente rinfrescante da "Dovremmo correggere questi bug prima di iniziare questa funzione?" I bug esistenti non sono "gotcha" nel nuovo lavoro e mantengono il nostro team di sviluppo concentrato sulle idee e innovazione, non correzioni di bug.

Ottenere il buy-in

Avere l'idea di arrivare a Zero Bugs e implementare una strategia e una politica al riguardo era una cosa. Prima che potessimo persino pianificare il modo in cui lo avremmo fatto, avevamo bisogno del supporto e del buy-in da parte del senior management team. Altrimenti, la spedizione di nuove funzionalità e la risposta alle richieste dei clienti metterebbero sempre correzioni di bug nel back burner. Ecco il caso che abbiamo fatto:

- Perché questo era un obiettivo importante per cui lottare? 1. per i nostri clienti (esternamente) e 2. per i membri del nostro team (internamente)

- Qual è il costo attuale del nostro arretrato di bug (produttività, incapacità di fornire più funzionalità più velocemente), perdita di entrate, impatti sulla crescita dei conti e spreco di denaro in infrastrutture non necessarie per mantenere i livelli di prestazione)

- Come arriveremmo a zero?

- Come manteniamo la nostra politica sui bug zero una volta raggiunto lo zero?

Ci sono voluti tempo e alcuni cicli di discussione per far sì che il nostro CEO fosse pienamente coinvolto. L'idea di dedicare tempo di sviluppo esclusivamente alla riduzione del numero di bug non sembrava possibile. Tuttavia, spiegando quanto sopra è stato chiarito che non si trattava solo di avere zero bug. Questo era molto di più per i nostri clienti, per il nostro team e per la nostra capacità di continuare a innovare e costruire un prodotto che i nostri clienti amano. (e la nostra linea di fondo!)

Siamo riusciti a prenderlo da "WTF! Non è possibile dedicare così tanto sforzo a questo "a" Questo ha assolutamente senso. Di cosa hai bisogno per farlo? ”Non solo lo abbiamo conquistato, ma ha scritto il suo post sull'argomento ed è ora un sostenitore zelante di zero bug!

Iniziare

Abbiamo iniziato ad affrontare l'arretrato definendo un calendario con obiettivi mensili che ritenevamo realizzabili. Il team del prodotto si è impegnato a ridurre l'arretrato di dieci bug al mese in concomitanza con la lotta ai nuovi bug che sono arrivati ​​E mantenere il lavoro delle funzionalità che si muove a una velocità rispettabile. Come puoi immaginare, ha funzionato bene per il primo mese, ok per il secondo mese e per il terzo mese, stavamo lottando per tenere il passo sia con l'arretrato che con i nuovi bug perché rischiare che le tempistiche delle funzionalità per raggiungere gli obiettivi di riduzione dei bug si fossero rivelate un chiamata difficile costretta agli sviluppatori. Per recuperare il ritardo, abbiamo fatto un'esplosione di correzione di bug. Il backlog e i "nuovi" bug erano in declino. Questo ci ha riportato sulla buona strada, ma, in quattro mesi, ci siamo ritrovati a ricadere in vecchi modi: i bug venivano spinti da parte per il lavoro di funzionalità e così via. Qualcosa doveva dare - lasciare gli insetti com'è e continuare sul percorso attuale, o, trovare un nuovo approccio.

Adattare il piano

Poiché il nostro primo approccio per arrivare a zero bug non ha funzionato come previsto, abbiamo iniziato a pensare a diversi modi per affrontare questo problema. Si scopre che l'approccio di successo nell'affrontare i bug era proprio di fronte a noi, non abbiamo mai considerato di applicare l'approccio alle correzioni di bug. In ConceptShare lavoriamo in quelli che chiamiamo "Feature Team", consentendo agli sviluppatori di lavorare insieme sulle funzionalità che li interessano di più. È un ottimo approccio perché possiamo sfidare noi stessi e scegliere ciò su cui lavoriamo. Buona mentalità da lavoratore e tutto il resto. Quindi, abbiamo pensato e se avessimo trattato i bug come qualsiasi altra caratteristica? Qualcuno del team di sviluppo sarebbe interessato a distruggere i bug finché non se ne fossero andati tutti? c'erano membri del team che erano felici di affrontare questa sfida e portarci a Zero Bugs. Si formò una squadra, fece un piano e si mise al lavoro.

L'abbiamo fatto! Zero Bugs. E adesso?

Dopo 18 mesi di lavoro dedicato, alcuni dibattiti su come concentrare i nostri sforzi, alcune piccole modifiche al nostro processo e due mesi in anticipo rispetto alla nostra data obiettivo - abbiamo raggiunto il nostro obiettivo - abbiamo zero bug nel nostro backlog. Io ripeto. Abbiamo bug ZERO nel nostro backlog. È una pietra miliare fantastica da colpire. Il nostro team è estatico. E ora?

  1. Abbiamo implementato una nuova politica di bug zero:

"La nostra politica impone che per ogni data versione, la massima priorità è quella di eliminare i bug sulla creazione di nuove funzionalità. Questo per ridurre i costi di correzione dei bug, reattività per i nostri utenti e mantenimento della qualità del nostro prodotto il più alto possibile. "

2. Il nostro team di bug è tornato al lavoro sulle funzionalità del prodotto, consentendo loro di scegliere le loro funzionalità successive tenendo presente che, insieme ad altri membri del nostro team di prodotto, rimangono impegnati nella nostra politica sui bug zero.

3. Il nostro team di prodotti continua a impegnarsi per far crescere il nostro prodotto senza la preoccupazione di essere ritardato a causa di vecchi bug. Ora possiamo davvero mettere il piede sul gas e fornire molte più funzioni e miglioramenti più velocemente di quanto potessimo prima

4. I nostri consulenti per le operazioni creative sono ora in grado di concentrarsi completamente sull'aiutare i nostri clienti a realizzare tutto ciò che possono ottenere con il nostro prodotto, senza dover attendere la correzione di Bug X e Bug Y.

5. E, soprattutto, i nostri clienti possono utilizzare meglio ConceptShare per lavorare in modo più intelligente, più veloce e migliore, senza essere impantanati da fastidiosi bug nel software.

Come rimaniamo a Zero Bugs?

Per fare ciò, abbiamo aumentato il nostro processo di bug (che probabilmente assomiglia a qualsiasi altro processo di bug là fuori ad alto livello) per allinearci con la nostra politica ufficiale di bug zero. Queste sono le modifiche che abbiamo apportato:

Triage di bug

Le nostre riunioni di triage si svolgono in genere settimanalmente da un gruppo di parti interessate (PM / COA / Dev Team Member (s) e QA). I bug verranno ora valutati all'arrivo dal nostro team di controllo qualità che otterrà ulteriori informazioni dalle parti interessate se la gravità / l'impatto non sono chiari. I bug verranno quindi inviati al team del prodotto affinché qualcuno li possa catturare.

I bug triaged vengono immediatamente rivendicati

I bug valutati non restano più in attesa e aspettano che qualcuno inizi a lavorarci su. Abbiamo un sistema di gioco integrato nelle tempistiche delle funzionalità in modo che gli sviluppatori possano anche dedicare del tempo a raccogliere nuovi bug senza rischiare il loro lavoro.

QA Team adotta un approccio più aggressivo

Se un bug triaged non viene rivendicato (ovvero il lavoro è iniziato) entro un periodo di tempo specifico, il nostro team addetto al QA contatterà il team del prodotto per ottenere il bug assegnato in modo che il lavoro possa iniziare

Aumentando le nostre iterazioni di rilascio

Ci adopereremo per essere ancora più aggressivi nei nostri cicli di rilascio, quindi le nostre correzioni di bug si fanno strada più rapidamente nelle mani dei nostri clienti piuttosto che essere vincolate a una specifica versione di funzionalità.

Avvolgendo

Zero bug, ha abbastanza l'anello, ed è stato piuttosto il viaggio finora con alcuni su / giù e buche di coniglio pazzo - ma non si ferma qui. Nell'ultimo anno e mezzo, abbiamo realizzato molto di più che semplicemente adottare una nuova politica su come gestiamo i nostri bug qui su ConceptShare. Questo fa ora parte della nostra cultura - integrata nel modo in cui lavoriamo mentre sviluppiamo più funzionalità e capacità della massima qualità, qualità che permea i nostri stakeholder più importanti, i nostri clienti.

Vorrei anche dire un enorme "GRAZIE!" Alla squadra che ha reso possibile questo. (guarda come abbiamo festeggiato con una pinata a forma di insetto.)

Sono curioso: qualcun altro ha cercato di arrivare a zero bug e, in tal caso, come hai fatto? Cos'hai imparato?

Questa storia è pubblicata in The Startup, dove oltre 258.400 persone si incontrano per leggere le storie di spicco dell'imprenditoria di Medium.

Iscriviti per ricevere le nostre storie migliori qui.