Treballem per aconseguir un zero

Hola,

fa uns mesos em vaig comprometre a compartir el número d'incidències per canvi de versió del primer trimestre de l'any.

Reduir incidències i en particular les de canvi de versió és un punt de focus important per a nosaltres, i aquest primer trimestre havíem de veure reflectit en el canvi a la versió 7.4, el resultat de les eines que hem creat per millorar.

Abans d'entrar en detall, recorda que el dia 18 d'aquest mes de maig, de 10h a 12h, estàs convidat/da a una xerrada a la nostra oficina. Parlarem sobretot de com integrar la IA a l'estratègia de la teva empresa. Si vols venir, només m'ho has de dir contestant aquest correu.

Una aplicació sense canvis

Si una aplicació no rep millores i només correccions, la corba d'errors que s'espera és el següent:

Moltes incidències inicialment, que es van reduint al llarg del temps encara que sempre es va detectant alguna incidència mesos o fins i tot anys més tard.

Les nostres dades

Com que en aquest cas ens interessa analitzar les incidències derivades del canvi de versió, el que nosaltres fem és observar especialment les incidències que s'han produït durant els 30 dies posteriors al canvi de versió. Aquestes són les dades des de la versió 6.4 fins a la 7.4:

Agafo des de la 6.4 perquè és des del moment en què tenim automatitzat el procés de registre de la data de canvi de cada base de dades de client.

Tot i que ja tenim clients a la versió 7.6 i a la 7.8, agafo fins a la 7.4 perquè és l'última versió per la qual han passat més de 30 dies des del canvi de versió per a totes les bases de dades, a més de que la mostra és la més gran possible.

En el gràfic podem observar com hem reduït pràcticament un 65% el número d'incidències de canvi de versió.

També hem de tenir en compte quin és el número d'incidències residual: el número d'incidències que es troben fins i tot mesos després del canvi de versió.

Per exemple, al cap de 12 mesos després d'actualitzar la versió aquesta xifra va ser de ser de 0,74 pel cas de la versió 6.8 (la més baixa de les quatre). La xifra concretament representa el número d'incidències que es van produir els 30 dies després de fer 12 mesos des del canvi de versió.

Si ho mirem així, és a dir, si restem a les incidències de canvi de versió, les 0,74 que queden d'incidències residuals, la reducció arriba al 70%.

Les dades de les traces

Com que totes aquestes dades inclouen incidències que arriben de forma automàtica i també introduïdes manualment, és més fàcil que tinguin algunes distorsions, així que tot i que no és completa, també em sembla interessant analitzar a banda, les incidències rebudes automàticament.

En aquest cas tot el que arriba de forma automatitzada sempre són errors que cal resoldre, si bé en alguns casos pot ser que els usuaris no se n'adonin: bé siguin perquè són coses que realment no alteren la seva operativa o bé perquè es fa en processos automàtics que es poden acabar fent més tard.

En aquest cas les xifres són les següents:

Aquest gràfic és curiós perquè sembla fet amb regle, però t'asseguro que són les dades reals. En aquest cas passem de 3,07 a 0,97, una caiguda del 68%.

Salts grans o salts petits?

Hi ha una petita trampa en aquestes dades: el canvi a la versió 7.4 ha suposat per la majoria de clients només el salt d'una sola versió (les versions de Tryton salten de 6.4, a 6.6, a 6.8, 7.0, 7.2, 7.4, etc, però nosaltres no sempre hem passat per totes les versions).

Així que és clar, en el canvi a la 7.4 és lògic que tinguem menys incidències perquè el salt ha estat més petit.

El curiós del cas és que hem tingut algun client que ha saltat de la versió 6.8 directament a la 7.4 i ha estat aquest canvi el que ha fet incrementar-ne molt el número d'incidències!

Si descartem aquests casos, el número d'incidències els primers 30 dies després del canvi a la versió 7.4 passa de 2,72 a només 2, i les incidències automàtiques passen de 0,97 a 0,89. Això és una caiguda del 73% i del 71% versus la versió 6.4 respectivament.

Així doncs, les xifres milloren encara que considerem que hem fet un salt de versió enlloc de dos.

A més de reduir el número d'errors aquest any hem incrementat molt el ritme de canvis de versió passant pràcticament tots els clients per cada versió, ara fent-ho a una freqüència superior al de cada 6 mesos.

Això és molt important: com que els canvis de versió poden comportar alguns errors, moltes empreses intenten reduir-les al mínim, però això porta a salts més grans i a menys experiència en els canvis. Nosaltres fem moltíssims més canvis de versió, el que reparteix les possibles incidències però també les redueix perquè en fer-ho molt sovint ens permet millorar més i més ràpid.

I fixa't que fins i tot si no milloréssim, si tinguéssim el mateix número d'incidències per cada versió, el temps de resposta i l'experiència de l'usuari és molt millor si aquestes es reparteixen en un període molt més llarg.

Continuem treballant per aconseguir zero incidències

Per continuar millorant la qualitat, ara mateix posem èmfasi en incrementar el número de tests específics de cada client i també el testeig de la interfície gràfica d'usuari que és el més complicat d'automatitzar però ja hem començat.

A més, també farem canvis a diversos nivells per tal que les incidències que es produeixin es resolguin més ràpidament.

Penso que d'aquí sis o vuit mesos tornarà a ser moment de fer balanç, així que llavors et compartiré com han evolucionat aquestes xifres.

Salut i bona setmana!