Visualización de métricas de incidencias con un Kanban Board de Jira.

En pocas ocasiones se percibe el esfuerzo que implica solucionar un problema en uno de nuestros sistemas. Sin embargo, cuando el fontanero llega a nuestra casa, toca la pieza adecuada y nuestra lavadora deja de hacer ese ruido infernal y estridente que nos hacía temer lo peor, nos parece que el trabajo merece el salario (aunque puede que después del susto y con más calma podamos tener alguna duda al respecto). Cuando se trata de arreglar una incidencia, la percepción no es la misma, principalmente porque el software es muy etéreo.

Esta era la percepción de nuestro cliente cuando nos pidió desarrollar un sistema para analizar las métricas y donde pudieran ver el ritmo con que el equipo solucionaba las incidencias. Estas eran generadas en Jira por el centro de atención al cliente y decidimos usar el API que ofrece (de la que ya nos hizo un repaso Manuel Zaforas) para desarrollar un dashboard donde mostrar ciertas métricas que nos dieran datos con los que describir la situación real.

En este tipo de sistemas es esencial la correcta clasificación de las incidencias según afectan a los usuarios o al negocio. Tan importante puede ser que afecte a un volumen grande de usuarios (por ejemplo, nadie puede acceder a su área privada) como a uno pequeño, ya que por ejemplo están generando mucho ruido vía redes sociales, afectando a la imagen del cliente.

Para ello es importante tener una figura que sepa diferenciar lo urgente de lo importante, además de tener claro el valor de negocio de las diferentes funcionalidades. Cuando el número de incidencias graves aumenta por encima de la capacidad del equipo es clave definir un orden de prioridad de resolución y seguirlo sin que el equipo se vea constantemente interrumpido.

Como es de entender, para un cliente, el ritmo de resolución de incidencias nunca es el perfecto. En una situación idílica, no debería haber incidencias pero bien sabemos que esto no se asemeja en absoluto a la realidad.

Siempre existen sistemas que se saturan, que dejan de funcionar correctamente, circunstancias particulares para un usuario que no se tuvieron en cuenta en el último desarrollo, etc. Por este motivo es muy importante realizar mediciones sobre el ritmo de resolución de incidencias, obtener métricas y hacer partícipe al cliente de esta información.

En nuestro caso, el cliente dispone de un Call Center para la gestión de incidencias de los usuarios. Cuando un operador encuentra algún error o alguna funcionalidad que no se comporta del modo esperado, registra en sus sistemas una incidencia que, de forma automática, registra también en uno de nuestros tablones de Jira.

Es importante vigilar el ritmo de creación de incidencias, esto puede indicar un error crítico que dificulta las operaciones.

En muchas ocasiones, un crecimiento excesivo en la creación de tickets suele implicar la creación de incidencias muchas de ellas relacionadas entre sí. Es, por tanto, un indicador importante del estado del servicio.

El tablón de incidencias en nuestro caso consiste en un Kanban Board de Jira y está constituido por el siguiente flujo de estados:

• El estado creado, indica el momento de creación del ticket por parte del Call Center. El día inmediatamente posterior, pasa a Abierto.
• Abierto denota que se creó con anterioridad y que aún nadie ha comenzado a trabajar en él.
• El estado reabierto ocurre cuando una incidencia se resolvió, pero el Call Center no ha dado por buena la solución realizada con anterioridad, ya sea porque no funciona bien para un caso concreto o porque es necesario realizar otras acciones adicionales.
• Bloqueado significa que el equipo no puede realizar ninguna corrección, ya sea por falta de datos, por no poder reproducir el problema, etc. y recae en el Call Center la responsabilidad de solventar dicho bloqueo.
• Resuelto es el estado que indica que el error ya fue subsanado por el equipo en producción y falta ser validado por el cliente.
• Una vez el Call Center revisa que la incidencia ha sido corregida correctamente pasa su estado a cerrada. En caso contrario se pasa a reabierta*.*

Gracias al API de Jira y al módulo de Python desarrollamos un pequeño gráfico que facilitara comprender la situación de las incidencias de un solo vistazo. En la figura 1 se puede ver el estado de las incidencias durante una semana completa tras realizar una de prospección de datos y gracias a las facilidades de visualización que nos ofrece Highcharts.

Figura 1

Para cada día aparecen 2 columnas. La primera está relacionada con los tickets creados, abiertos o reabiertos por el Call Center. Define la cantidad de trabajo que queda por realizar. La segunda columna indica la capacidad operativa del equipo de desarrollo (con los bloqueos y las resoluciones). Por último, tenemos la columna con los tickets cerrados por parte del Call Center.

Para cada día también se muestran 3 KPIs. El primero de ellos es el ritmo de resolución frente al de creación (en la gráfica indicado como Sol.). Como se puede apreciar en el segundo gráfico depende mucho de cuándo el cliente valida y marque como resuelta una incidencia.

El segundo KPI es el tiempo medio de resolución (Time) según todas las tareas marcadas como resueltas en la fecha en cuestión. Esta medida es muy interesante ya que nos mide cuánto tiempo de media tarda el equipo en solventar una incidencia. Junto con ésta, muchas veces es también interesante incluir la desviación o, de una forma más sencilla, el tiempo de la tarea que más tardó en completarse, con ánimo de no dar una falsa expectativa al cliente.

La última de las medidas es el ritmo de procesamiento (Proces.) que es una media del tiempo invertido en los tickets en los que se ha trabajado ese día. Un gráfico que refleja mejor esta medida puede verse en la tercera imagen. Esta medida abarca desde el momento en que el equipo toma la tarea hasta que le da una respuesta (bien bloqueada por falta de información o resuelta a falta de ser validada por el cliente) sobre las incidencias que quedan por tratar.

Figura 3

Como se puede apreciar en las métricas, las tareas relativas al equipo de desarrollo no avanzan durante el fin de semana (las primeras dos columnas del gráfico son sábado y domingo), mientras que las del Call Center sí. Obviamente se debe a que la disponibilidad de ambas partes no es la misma.

Conclusión

Este es un modo sencillo para ofrecer métricas con datos reales al cliente sobre el ritmo de resolución de incidencias, de manera que pueda tener una idea clara del funcionamiento del flujo de trabajo del equipo, si existe una falta de capacidad o una previsión sobre la duración de la resolución de una incidencia en producción, entre otras cosas.