Como JIRA se cargó la matríz de prioridad

0

JIRA cada vez más está monopolizando las áreas de gestión de servicios, y más desde que publico su producto Service Desk. Hoy en día en mi entorno me cuesta encontrar una empresa que no haya puesto JIRA para gestionar a sus equipos de desarrollo. Y poco a poco veo como JIRA se está metiendo en áreas para las que no fue diseñado, como son la gestión de procesos de la empresa, o la gestión de incidencias. Así que últimamente me topo con las limitaciones de esta herramienta y me cuesta mucho más de lo normal convencer de las buenas prácticas. ¿Y cuál es la mejor práctica que se ha perdido por culpa de JIRA? La matriz de prioridad. Descanse en paz.

¿Por qué JIRA se mete en otras áreas?

Lo que en su momento fue una aplicación estupenda para la gestión de equipos de desarrollo, ha pasado rápidamente a convertirse en un gestor de procesos global. Y esto ¿por qué pasa?. Pues desde mi punto de vista por dos motivos:

  • Una interfaz simple y fácil de configurar.
  • Opciones de personalización que le convierten en un BPM.

Un BPM (Business Process Modeller) es una herramienta en la que podemos definir un proceso, darle estados, definir roles y la herramienta controlará la ejecución. JIRA permite eso, y lo hace con una elegancia que lo convierte en algo muy sencillo.

Así, vemos como cualquier usuario de JIRA enseguida se le ocurre cómo explotar la aplicación y empezar a mapear procesos de su empresa, y esto sin pagar un coste adicional.

¿Y qué tiene esto de malo?

A priori puede parecer que nada. Que todos son ventajas. Pero hay dos grandes peligros acechando.

El primer peligro es que perdemos el conocimiento experto. Hay procesos que son exclusivos de un sector o que van muy ligados a la cultura de la empresa, pero hay otros procesos que son comunes a cualquier organización. Por ejemplo, un proceso de contratación de personal, es bastante estándar y las buenas prácticas sobre el mismo son conocidas. Lo mismo pasa con el proceso de gestión de incidencias. Da igual si tu empresa es una organización de transportes o un servicio de alta criticidad en la nube, tu proceso de gestión de incidencias tiene una base común. Cuando incorporas una herramienta como SAP, te traes esos procedimientos y la empresa crece. No sólo crece porque te pongan una herramienta potente, sino porque tienes que modificar los procesos de empresa a los de SAP, y así mejoras. Lo mismo pasa con incidencias, que con una herramienta como BMC Remedy mejoras, porque te fuerza a usar procesos que incorporan mejores prácticas. Con JIRA, al definir el proceso la empresa no incorpora la experiencia de esas herramientas, y la organización debe evolucionar lentamente hasta madurar el proceso. Resumiendo, experimenta (y gasta) con un proceso que podría haber tenido de serie.

El segundo peligro es que un BPM no es sólo un flujo, también son reglas sobre la información que se maneja durante el proceso. JIRA te deja crear reglas, pero a la que quieres mejorar, te vas a programar. Así que muchas empresas optan por no programarlo y hacerlo manualmente. Cuando incorporas una herramienta como SAP esos cálculos o reglas de negocio se fuerzan desde el día 0. Con JIRA tardarás mucho en tenerlos forzados.

Resumiendo, los procesos creados con JIRA no incorporan conocimiento experto y las reglas son limitadas (aunque no lo parecen).

La matriz de prioridad

Si juntamos los dos problemas anteriores, entendemos lo que le ha pasado a la matriz de prioridad.

Primero, JIRA trae un campo de prioridad, no trae campos de urgencia o impacto. Así que cuando la empresa se decide a montar un proceso de gestión de incidencias no piensa en crearlos (ya que JIRA no trae conocimiento experto). Así vemos procesos de gestión de incidencias en empresas creados con JIRA que no incorporan estos campos. Pero es que el JIRA Service Desk, que está en teoría orientado a ITIL y posee la certificación Pink Verify, tampoco los tiene. Sinceramente no consigo entender como se las apañan para conseguir el sello, cuando de ITIL no tienen realmente nada.

Segundo, cuando llega alguien que conoce algo de ITIL y lo pide, se encontrará con dos problemas:

  1. Por un lado le costará mucho convencer a la empresa, porque ha comprado una aplicación para gestionar incidencias (Service Desk) que no tiene esos campos. Es su palabra contra la herramienta. La lucha es desigual…
  2. Por otro lado, no sólo es añadir dos campos, es añadir la lógica que calcula y fuerza la prioridad. Así que hay que programar sí o sí (reglas limiatadas). Lo que supondrá una gran barrera.

El resultado: Todavía no conozco una empresa que use JIRA como su gestor de incidencias, que tenga una matriz de prioridad.

¿Y cuál es el problema de no tener la matriz?

El problema de no tenerla se traduce en una consecuencia que veo en todas las empresas por las que he pasado: que la prioridad carece de significado. Algunas han conseguido que sólo una persona ponga la prioridad a todo, pero eso sólo es posible en estructuras pequeñas. Si tienes más de una persona, la prioridad comienza a bailar. Y dado que la prioridad, si tiene valor, determina el orden de resolución, comienza la carrera de prioridades y comienzas a ver como todo el mundo eleva la prioridad de sus tiquets al máximo. Resultado final: Los equipos resolutores, comienzan a ignorar el campo de prioridad. Cuando todo es prioritario, es que no hay prioridad.

Otros afectados

El resto de buenas prácticas de la gestión de incidencias también están gravemente atacados con JIRA. No veo en los despliegues de JIRA conceptos como:

  • Diferenciación entre roles de propietario y asignado (clave en ITIL!)
  • Estructura en grupos de soporte y asignación.
  • Notificaciones orientadas a grupos o niveles de soporte (en JIRA las notificaciones son a personas).

La gran diferencia entre Service Desk y el resto de JIRA es el cálculo de SLA y el portal de autoservicio. Nada más.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información.
Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector.
Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo.
Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios