Métricas de TI para garantizar velocidad y calidad a tu negocio

“La potencia sin control no sirve de nada” era el eslogan de una famosa empresa para la que trabajé hace unos veinte años: es un lema que veía por todas partes, que me gustaba y que se me ha quedado grabado. Tal vez es también ese el motivo por el que he aceptado de buena gana el desafío de organizar la implementación en MailUp de una serie de métricas de TI bien conocidas en bibliografía, en cuya base están el equilibrio entre velocidad y calidad.

¿Qué son las métricas TI? Son mediciones de magnitudes significativas del mundo de la Tecnología de la Información que ayudan a controlar y mejorar los procesos. Como en todos los procesos complejos, la habilidad está en encontrar un número limitado de magnitudes que puedan medirse, que constituyen no solo un buen indicador de cómo están funcionando los procesos y el rendimiento de nuestro producto, sino que nos permiten mejorar estos dos aspectos  a través de intervenciones dirigidas específicamente a cambiar los valores de dichas magnitudes.

¿Parece complicado? En cierto modo lo es, porque no es nada sencillo identificar las métricas más adecuadas para este tipo de control activo. Después de algunos intentos con métricas definidas internamente, hemos optado por adoptar las indicaciones que se presentan en el libro “Accelerate – Accelerate: The Science of Lean Software and DevOps” y que han sido introducidas entre los temas más importantes, de 2012 hasta hoy, de las publicaciones del State of DevOps Annual Report.

Tras una investigación muy amplia, que duró años y que ha involucrado a miles de empresas, los autores de las publicaciones arriba citadas han llegado a la conclusión de que hay una correlación directa entre unas excelentes prestaciones TI y unos resultados igualmente buenos a nivel de negocio para las empresas del sector digital. Estos estudios han identificado cinco métricas principales en las que todas las compañías de máximo nivel en TI (las grandes empresas y las compañías de vanguardia) obtienen resultados de excelencia. Las empresas que han adoptado estos mismos indicadores y que han conseguido igualar los valores de las  empresas con desempeño de élite en las cinco métricas han tenido una tasa de crecimiento muy superior a las demás, lo cual confirma en qué medida es extremadamente eficaz e importante implementar una serie de KPI de TI. El logro de la excelencia en los resultados de la tecnología pasa a ser, en síntesis, un factor habilitador para acelerar el desempeño a nivel de negocio. 

Las 5 métricas TI de las que hemos hablado hasta ahora se basan en conceptos realmente simples: velocidad y calidad. El mensaje es el siguiente: hay que entregar valor a los clientes de modo rápido, continuo y frecuente. A más velocidad, mayor riesgo de cometer errores, por lo cual hay que tener bajo control también la frecuencia de los errores y el tiempo requerido para el restablecimiento después de un problema de funcionamiento.

Si traducimos en números este concepto, se obtienen las 5 magnitudes que pueden medirse y usarse como métricas:

• Lead Time For Changes (LTFC): tiempo medio que transcurre desde el comienzo de un proceso de elaboración hasta que se pone a disposición del cliente (“en producción”)
• Deployment frequency: frecuencia con que se emiten novedades o actualizaciones en producción
• Change Failure Rate (CFR): frecuencia de la actualizaciones en producción, realizadas para restablecer un problema causado por una actualización reciente
• Mean Time To Recover (MTTR): tiempo medio empleado para el restablecimiento después de un problema grave que tiene lugar en producción y que ha tenido impacto en los clientes
• Availability: porcentaje de tiempo en que los servicios de la plataforma han estado plenamente disponibles (obtenido después de haber sustraído la suma de todos los tiempos de restablecimiento).

En MailUp hemos adoptado estas métricas desde septiembre de 2020 mediante instrumentos de medición automática, estableciendo un proceso continuo en el cual:

• monitoreamos la evolución de las mediciones
• fijamos los objetivos que queremos alcanzar
• identificamos las acciones necesarias para alcanzarlos.

Es un recorrido que hay que afrontar con la debida atención, porque a un aumento repentino de la velocidad puede corresponderle un empeoramiento de la calidad.

Un error frecuente es olvidarse de que las métricas son indicadores indirectos a través de los cuales queremos mejorar un proceso. Lo que cuenta, por tanto, no es la medición como fin en sí misma, sino el impacto en el proceso y en el producto que tenemos cuando logramos hacer que esa medida cambie.

En relación con la figura, vamos a ver más en detalle cómo calculamos estas métricas en MailUp:

El Lead Time For Changes lo calculamos como una media de los últimos tres meses del tiempo que una historia (o tarea), correspondiente a un issue Jira, emplea para transitar desde el inicio del proceso a la publicación en producción.  La suite Atlassian Jira nos ayuda en esto porque permite medir el “time in status” de una historia, es decir, el tiempo en que un issue ha permanecido en un determinado estado, para cada transición de su flujo de trabajo. Los datos se visualizan entonces en una Control Chart de Jira o a través de paneles de gestión que realizamos expresamente con Tibco Spotfire, importando y agregando los datos de Jira.

En MailUp medimos también el Lead Time To Deploy, es decir, el tiempo que transcurre desde la última modificación del código fuente hasta la puesta en producción. 

Para la deployment frequency y el CFR hemos integrado nuestros procesos automáticos de entrega en producción (pipeline de deployment) con un flujo que registra en una base de datos la información más significativa para las métricas. El técnico que lleva a cabo una intervención en el entorno de producción, solo debe especificar si se trata de un trabajo ordinario, un hotfix (corrección rápida) o un rollback (restablecimiento de la versión precedente).

El MTTR y la Availabilty se basan en la definición de “incident”, que hemos definido internamente como un fallo en producción cuyo impacto y severidad superan un cierto límite. Para cada incident es obligatorio compilar una “ficha de incident” en Atlassian Jira, en la que se indican varios elementos, como la duración, la causa, los efectos, los impactos y el tipo de resolución. Los datos de las fichas incident se extraen seguidamente mediante un proceso automático para poderlos elaborar y representar gráficamente.

Para cada una de las métricas descritas, tenemos a disposición las tendencias de su evolución temporal y encontramos muy útil el uso de la media móvil en los últimos 3 o 4 meses como medida de referencia, para así contextualizar y compensar elementos engañosos, como un pico aislado o la inercia de una ventana de evaluación demasiado grande.

¿Son suficientes para nosotros estas métricas? Son ciertamente un excelente punto de partida para comprender el estado de salud de la parte tecnológica, aunque nuestro horizonte futuro se haya proyectado ya en dos pasos adicionales:

• la integración de estas métricas con otras medidas significativas, como la velocidad de acceso a las páginas de la plataforma.
• la introducción de un nivel más específico sobre los indicadores existentes, que los detalla mediante submétricas para hacer “drill-down” (análisis en profundidad).

Tenemos así una breve panorámica sobre qué significa y qué ventajas puede garantizar la implementación de una serie de métricas de TI para mejorar los resultados generales del negocio. Si quieres saber más sobre las métricas y sobre cómo se calculan, ¡visita este enlace!