Trabajamos para conseguir un cero

Hola,

hace unos meses me comprometí a compartir el número de incidencias por cambio de versión del primer trimestre del año.

Reducir incidencias y en particular las de cambio de versión es un punto de foco importante para nosotros, y este primer trimestre teníamos que ver reflejado en el cambio a la versió 7.4, el resultado de las herramientas que hemos creado para mejorar.

Antes de entrar en detalle, recuerda que el día 18 de este mes de mayo, de 10h a 12h, estás invitado/a a una charla en nuestra oficina. Hablaremos sobre todo de cómo integrar la IA en la estrategia de tu empresa. Si quieres venir, sólo tienes que decirlo contestando este correo.

Una aplicación sin cambios

Si una aplicación no recibe mejoras y sólo correcciones, la curva de errores que se espera es la siguiente:

Muchas incidencias inicialmente, que van reduciéndose a lo largo del tiempo aunque siempre se va detectando alguna incidencia meses o incluso años más tarde.

Nuestros datos

Dado que en este caso nos interesa analizar las incidencias derivadas del cambio de versión, lo que nosotros hacemos es observar especialmente las incidencias que se han producido durante los 30 días posteriores al cambio de versión. Estos son los datos desde la versión 6.4 hasta la 7.4:

Cojo desde la 6.4 porque es desde el momento en que tenemos automatizado el proceso de registro de la fecha de cambio de cada base de datos de cliente.

Aunque ya tenemos clientes en la versión 7.6 y en la 7.8, cojo hasta la 7.4 porque es la última versión por la que han pasado más de 30 días desde el cambio de versión para todas las bases de datos, además de que la muestra es la mayor posible.

En el gráfico podemos observar cómo hemos reducido prácticamente un 65% el número de incidencias de cambio de versión.

También debemos tener en cuenta cuál es el número de incidencias residual: el número de incidencias que se encuentran incluso meses después del cambio de versión.

Por ejemplo, a los 12 meses después de actualizar la versión esta cifra fue de 0,74 para el caso de la versión 6.8 (la más baja de las cuatro). La cifra concretamente representa el número de incidencias que se produjeron los 30 días después de cumplir 12 meses desde el cambio de versión.

Si lo miramos así, es decir, si restamos a las incidencias de cambio de versión, las 0,74 que quedan de incidencias residuales, la reducción alcanza el 70%.

Los datos de las trazas

Dado que todos estos datos incluyen incidencias que llegan de forma automática y también introducidas manualmente, es más fácil que tengan algunas distorsiones, así que aunque no es completa, también me parece interesante analizar aparte las incidencias recibidas automáticamente.

En este caso todo lo que llega de forma automatizada siempre son errores a resolver, si bien en algunos casos puede que los usuarios no se den cuenta: bien sean porque son cosas que realmente no alteran su operativa o bien porque se hace en procesos automáticos que se pueden acabar haciendo más tarde.

En este caso las cifras son las siguientes:

Este gráfico es curioso porque parece realizado con regla, pero te aseguro que son los datos reales. En este caso, pasamos de 3,07 a 0,97, una caída del 68%.

Saltos grandes o saltos pequeños?

Hay una pequeña trampa en estos datos: el cambio a la versión 7.4 ha supuesto para la mayoría de clientes el salto de una sola versión (las versiones de Tryton saltan de 6.4, a 6.6, a 6.8, 7.0, 7.2, 7.4, etc, pero nosotros no siempre hemos pasado por todas las versiones).

Así que claro, en el cambio a la 7.4 es lógico que tengamos menos incidencias porque el salto ha sido menor.

¡Lo curioso del caso es que hemos tenido algún cliente que ha saltado de la versión 6.8 directamente a la 7.4 y ha sido este cambio el que ha hecho incrementar mucho el número de incidencias en la estadística global!

Si descartamos estos casos, el número de incidencias en los primeros 30 días después del cambio a la versión 7.4 pasa de 2,72 a sólo 2, y las incidencias automáticas pasan de 0,97 a 0,89. Esto es una caída del 73% y del 71% versus la versión 6.4 respectivamente.

Así pues, las cifras mejoran aunque consideramos que hemos dado un salto de versión en lugar de dos.

Además de reducir el número de errores este año hemos incrementado mucho el ritmo de cambios de versión pasando prácticamente a todos los clientes por cada versión, ahora haciéndolo a una frecuencia superior al de cada 6 meses.

Esto es muy importante: dado que los cambios de versión pueden comportar algunos errores, muchas empresas intentan reducirlas al mínimo, pero esto lleva a saltos más grandes ya menos experiencia en los cambios. Nosotros hacemos muchísimos más cambios de versión, lo que reparte las posibles incidencias pero también las reduce porque al hacerlo a menudo nos permite mejorar más y más rápido.

Y fíjate que incluso si no mejoráramos, si tuviéramos el mismo número de incidencias por cada versión, el tiempo de respuesta y la experiencia del usuario es mucho mejor si éstas se reparten en un período mucho más largo.

Continuamos trabajando para conseguir cero incidencias

Para seguir mejorando la calidad, ahora mismo ponemos énfasis en incrementar el número de test específicos de cada cliente y también el testeo de la interfaz gráfica de usuario que es lo más complicado de automatizar pero ya hemos empezado.

Además, también realizaremos cambios a varios niveles para que las incidencias que se produzcan se resuelvan más rápidamente.

Pienso que en seis u ocho meses volverá a ser momento de hacer balance, así que entonces te compartiré cómo han evolucionado estas cifras.

¡Salud y buena semana!