Un día en mi vida gestionando un sistema de ticketing para un AMS
Nuestro servicio tiene dos actividades principales muy diferentes entre sí. Por una parte, estamos realizando una migración de la aplicación del Cliente a una tecnología WEB, y por otra llevamos el servicio de mantenimiento AMS (Servicio de Gestión de Aplicaciones), basado en ITIL . En este artículo me centraré en la segunda parte, cómo es un día como responsable de un servicio de mantenimiento.
Enfoque de la gestión en América Latina y ajuste de horario
Antes de comenzar, me gustaría aclarar que nuestro servicio cubre a varios clientes de la región de América Latina (LATAM), por lo que hemos ajustado nuestro horario de trabajo para adaptarnos a esta zona. En mi equipo hay personas que trabajan por la mañana/tarde y otras trabajan por la tarde/noche para cubrir mejor las necesidades del Cliente. Esto significa que, en algunos casos, podemos ofrecer un sistema de gestión de ticketing “around the clock” para poder trabajar con las necesidades de ticketing urgentes, comenzando por la tarde y acabándolos por la mañana.
¿Qué es el ticketing? La vida de un Work Item
En nuestro servicio de AMS, cada tarea que realizamos se identifica por un “ticket” asociado, que es la unidad de gestión que se utiliza durante todo el trabajo del equipo. En dicho ticket se explica la descripción de la tarea, el problema a resolver y el modo en el que se ha resuelto.
Las tareas de ticketing y mantenimiento se dividen de la siguiente manera:
Recibo un correo electrónico de Azure DevOps (es nuestra herramienta de ticketing) que nos notifica la apertura de un ticket sobre alguno de los proyectos/aplicaciones que mantenemos.
Paso a paso en la gestión del ticketing:
Lo primero que hago en nuestra herramienta de ticketing es verificar a qué categoría pertenece el ticket:
- Bug: Si la aplicación no está funcionando correctamente.
- Task: Cuando un usuario ha cometido un error al ingresar datos y necesita que los modifiquemos en la base de datos. ¡Hemos de pedir permiso para ello!
- Evolutivo: Cuando se solicita que la aplicación realice un proceso nuevo o que adaptemos uno existente a una nueva exigencia del negocio.
Priorización y asignación en el sistema de ticketing
Lo siguiente que hago es priorizar la tarea en función de su tipo y de otros factores:
- Bug: ¿Es un problema crítico? ¿Afecta a más de una cuenta del cliente? …
- Task: ¿Cuántas tablas están involucradas? ¿Impacta en la facturación (proceso crítico del cliente)?
- Evolutivo: ¿Tiene una fecha límite de entrega? ¿Contamos con personal disponible?
Luego asigno la tarea a un miembro del equipo. Normalmente, los Evolutivos se abordan por la mañana cuando hay más disponibilidad de personas y menos tareas urgentes. La asignación en nuestro servicio de ticketing depende de la disponibilidad de personas y si el proyecto ya tiene a alguien trabajando en otro requerimiento. Los bugs y Evolutivos que requieren una solución urgente se asignan al equipo de la tarde. Es importante destacar que si se identifica un Bug después de las 00:00 y es lo suficientemente crítico, podemos abordarlo por la mañana y es el responsable de Kiteris de la mañana quien lo asigna (yo trabajo por la tarde/noche). Ya sea dicha persona o yo, la asignación se realiza a través de nuestra herramienta de gestión de ticketing Azure DevOps, que envía un correo electrónico para notificarlo al miembro del equipo asignado.
Trabajando en la solución
Una vez asignada la tarea, el proceso de gestión del ticketing varía según el tipo:
- Bug:
- Verificamos que se trate de un error real de la aplicación y no de datos incorrectos o un problema en la base de datos. Para ello es clave reproducir el error en nuestros entornos de mantenimiento. En caso de ser lo último, rechazamos el incidente y explicamos el motivo en la herramienta de ticketing Azure DevOps.
- Si el error es real, pasamos a la fase de desarrollo de la solución.
- Task:
- Preparamos el script de base de datos para corregir los datos.
- Validamos con el cliente la solución antes de ejecutarla.
- Lo enviamos al DBA para que lo ejecute en el entorno correspondiente.
- Evolutivo:
- Primero llevamos a cabo una reunión para evaluar junto con los analistas de negocio la necesidad que lo originó, su viabilidad y las posibles repercusiones que podría tener en otros módulos.
- Realizamos un análisis detallado de los módulos, clases y tablas que deben modificarse. .
- Estimamos las horas de trabajo necesarias para el desarrollo y lo comunicamos al cliente.
- Llevamos a cabo el desarrollo que normalmente lo realizamos tras el alta de un nuevo ticket dedicado solo al desarrollo ya que el ticket inicial ha sido solo para el análisis y valoración.
Fase de pruebas
Comenzamos la fase de pruebas. Es importante destacar que trabajamos con tres entornos diferentes: EVO (Evolutivos), PRE (preproducción) y PRO (producción), y cada tipo de tarea sigue un proceso específico:
- Bugs: Si el error ocurrió en EVO, solo se prueba en EVO. Si ocurrió en PRE o PRO, realizamos la prueba en el entorno de PRE utilizando los mismos datos o los más similares posibles a los que generaron el error.
- Task: Una vez que el DBA del Cliente nos informa que ha ejecutado el script, verificamos en el entorno correspondiente que los datos se hayan corregido correctamente.
- Evolutivo: Siempre se prueba en EVO para asegurarnos de que esté completamente implementado (verificando cada punto del análisis) y de que cumpla con los requisitos del Evolutivo.
Fin del recorrido de ticketing: cierre y evaluación
Si las pruebas no son satisfactorias, volvemos al punto anterior. Si son satisfactorias, generamos una versión para EVO o PRE, según corresponda.
Los analistas de negocio de cada país prueban la solución en el entorno desplegado. Si encuentran algún error o si el Evolutivo no cumple con lo solicitado, volvemos al paso de pruebas.
Si la solución es correcta:
- Bug: Generamos una versión para el siguiente entorno y, cuando llega a PRO, se cierra.
- Task: Si es correcto, se cierra directamente.
- Evolutivo: Desde EVO pasa a PRE, donde se somete a una nueva serie de pruebas, y finalmente se despliega en PRO, donde se cierra.
Gestión y seguimiento del Servicio
Al final de cada mes, generamos un informe extraído de la herramienta de ticketing que incluye el número de incidentes abiertos y cerrados, los trabajos realizados por cada persona, el tiempo dedicado a cada ticket y subservicio, los SLAs,… entre otros datos relevantes.
Os invitamos a continuar leyendo otros artículos interesantes en nuestro blog y a descubrir los siguientes casos de éxito en la gestión de ticketing:
- Adaptación de su solución de gestión de riesgo de crédito de empresas en el sector bancario
- Mantenimiento, soporte y evolución (AMS) de las aplicaciones de gestión de proyectos y campañas publicitarias
Muchas gracias y hasta el siguiente post.
