Uso de Jira -Instructivo Reporte de incidencias

Jira es un canal de comunicación con el equipo de soporte técnico donde podrán solicitar la resolución de problemas, solicitar permisos, suministrar información y darle seguimiento a las solicitudes creadas.

A continuación encontrarás la explicación detallada acerca de: cómo crear, cómo darle seguimiento y cómo se cierran las incidencias.

CÓMO REPORTAR UN INCIDENTE.

Para reportar un incidente, deberán ingresar a soporte.thinkindot.com y loguearse con el usuario y contraseña autorizados.

Una vez allí, tendrás la opción de reportar incidentes críticos (Urgencias), o bien reportar otro tipo de incidente (Soporte).

Los incidentes están predeterminados en el sistema como Urgencias o Soporte, según corresponda para facilitar el reporte, tal como se visualiza en la imagen siguiente:

Cómo reportar un incidente crítico (URGENCIA):

Para reportar una urgencia, deberás seleccionar entre las opciones predeterminadas, la que representa tu necesidad.

Una vez que hayas seleccionado la urgencia predeterminada, se abrirá un formulario donde deberás completar los siguientes campos:

• Portal: deberás indicar el portal donde se presenta el incidente. Este campo permite incluir más de uno.

• Descripción: en este campo deberás detallar el problema a reportar.

• Adjunto: en este campo deberás agregar la captura de pantalla completa con la URL que muestra el error y sumar todas las capturas que consideres necesarias para reportarlo. Esto ayuda al equipo de soporte a tener la visualización del problema y contar con mayor información, mejorando el tiempo de resolución. 

• Compartir Con: en este campo se determina quién puede darle seguimiento a la solicitud. Si seleccionas “toda la organización”, estará visible para todos los perfiles de la organización autorizados en Jira. Si seleccionas “nadie”, sólo estará visible para quien crea la solicitud (recomendado para pedidos de presupuesto).

Una vez que hayas completado todos los campos, debes clickear en ENVIAR.

Cómo reportar otro tipo de incidente (SOPORTE):

Para reportar cualquier tipo de incidente, deberás seleccionar entre las opciones predeterminadas la que representa tu necesidad, o bien, crear un incidente desde cero.

Una vez que hayas seleccionado el tipo de incidente a reportar, se abrirá un formulario donde deberás completar los siguientes campos:

• Resumen: en este campo, deberás completar “el asunto” del incidente a reportar. En el caso de elegir una opción predeterminada, ya estará completo.

• Descripción: en este campo, deberás especificar y brindar toda la información necesaria para que el equipo de soporte entienda el requerimiento y pueda darle curso. 

• Imagen: en este campo deberás agregar la captura de pantalla completa con la URL que muestra el error y sumar todas las capturas que consideres necesarias para reportarlo. en este campo deberás agregar la captura de pantalla completa con la URL que muestra el error y sumar todas las capturas que consideres necesarias para reportarlo. Esto ayuda al equipo de soporte a tener la visualización del problema y contar con mayor información, mejorando el tiempo de resolución. 

• Prioridad: puedes indicar la prioridad de tu requerimiento. 

(IMPORTANTE) -  En el caso de reportar “otros requerimientos” el sistema sugerirá artículos explicativos de uso de producto en función a palabras clave, ya que muchas veces los reportes se relacionan con el uso de alguna funcionalidad. Las sugerencias aparecen como en la imagen que sigue:

Una vez que hayas completado todos los campos, debes clickear en ENVIAR.

 

CÓMO DAR SEGUIMIENTO A LAS INCIDENCIAS

Una vez creada la incidencia, sea crítica o no, sigue un circuito con distintos “estados” que nos permite darle seguimiento.

Toda incidencia entra al sistema automáticamente en estado “ESPERANDO POR AYUDA”. Este estado indica que la solicitud ha ingresado al sistema y que está a la espera de revisión y asignación interna por parte del equipo de soporte.

Cabe destacar que las urgencias, activan un alerta interna que las prioriza y acelera todo el circuito.

Cuando la tarea ha sido asignada, el equipo de soporte de Dos al Cubo pasa el card al estado “EN CURSO”. En función al avance de la resolución del requerimiento, el equipo de soporte puede pasar el card a los siguientes estados:

• Esperando por el cliente: esto indica que el equipo necesita mayor información por parte del cliente para dar curso a la solución. Es necesario que el cliente responda el requerimiento para pasarlo a “en curso” nuevamente. Este flujo de comunicación puede repetirse tantas veces como sea necesario hasta que el equipo de soporte cuente con toda la información que permita “resolver” el incidente.

• En Revisión interna: esto indica que el cliente ha respondido la solicitud y el equipo ha recibido la respuesta. Si la información provista por el cliente es suficiente para continuar con el proceso, pasará al “en curso”. Si se necesita mayor información, volverá a “Esperando por el cliente”. 

• En estimación: esto indica que la solicitud tiene aparejado un costo adicional que debe ser estimado por el equipo. Una vez enviada la cotización, pasará a “esperando por el cliente” para su aprobación y su consecuente estado “en curso” o bien, para su desestimación y consecuente estado “Cancelado”. 

• En Revisión por el Cliente: : esto indica que el requerimiento ha sido resuelto por el equipo de Dos al Cubo y se encuentra disponible para que el cliente haga su revisión.  Cuando el equipo de soporte haya terminado de trabajar, pasará el card al estado “en revisión por el cliente” y a partir de allí el cliente deberá notificar la conformidad o no de su resolución.

  • En el caso que el cliente no esté conforme con la resolución y lo notifique al equipo de soporte, el ticket volverá al estado en curso, para que el equipo vuelva a trabajar sobre el requerimiento. Cuando el equipo de soporte haya resuelto el tema, volverá a pasar el card a “en revisión por el cliente”. Este flujo de comunicación se mantendrá hasta que el cliente nos notifique la conformidad de la resolución. A partir de la confirmación, pasa al estado CERRADO.

• CANCELADO: esto indica que el requerimiento será desestimado. Siempre que un requerimiento sea cancelado, se notificarán las razones de la cancelación:

• Requerimiento Duplicado: en el caso que el mismo requerimiento haya sido reportado más de una vez (puede suceder que distintos usuarios reporten lo mismo), se cancelan las solicitudes duplicadas y se relacionan a la única incidencia que queda activa y sobre la cual se trabaja y se da seguimiento.

• Requerimiento Rechazado por el cliente: el cliente solicita que se desestime el requerimiento. Esto puede suceder porque notaron que estaba mal reportado, porque tuvo solución sin intervención del equipo de soporte o bien, porque la solución está asociada a un costo adicional que no ha sido aprobado.

• Requerimiento Rechazado por DaC: el equipo de soporte desestima el requerimiento. Esto puede suceder porque el requerimiento está mal reportado (la solución no está en nuestras manos), porque el problema está resuelto en otra versión del producto, o porque requiere un desarrollo adicional que no será realizado

.

• Requerimiento Inactivo: el equipo de soporte da por cerrado el requerimiento, luego de transcurrido un tiempo de inactividad (Falta de respuesta / aprobación por parte del cliente).

• CERRADO: esto indica que el requerimiento ha sido cerrado porque fue resuelto o porque fue cancelado. Una vez cerrado un incidente, no se puede volver a abrir, por esta razón si se desea retomar la incidencia, se deberá crear una nueva.

(!) CIERRE AUTOMÁTICO de INCIDENCIAS ABIERTAS.

Debido a que el sistema Jira no sólo es un medio de reporte de incidentes y comunicación del avance de la solución de requerimientos, sino que también es una herramienta que permite relevar los tiempos de respuesta, el sistema, de forma automática, dará por cerrado los cards que no presenten actividad luego de un período de tiempo.

• Cierre automático de Cards en estado CANCELADO: Cuando el equipo de soporte pasa el card al estado “Cancelado” (por las razones antes descritas), el sistema, automáticamente lo asignará al como “Cerrado”. 

• Cierre automático de Cards en estado EN REVISIÓN POR EL CLIENTE: Cuando el equipo de soporte informa al cliente la resolución del requerimiento al pasar el card del estado “en curso” al estado “En revisión por el cliente”, el cliente tiene que prestar conformidad de la resolución, o bien, notificar al equipo de soporte que necesita revisión. Si la incidencia permanece durante 10 días en estado “En revisión por el cliente” sin presentar actividad, el sistema interpreta la conformidad del cliente y automáticamente lo pasa a estado “Cerrado”. Una vez cerrado el ticket, si el cliente necesita revisión, deberá generar un nuevo ticket.

• Cierre automático de Cards en estado ESPERANDO POR EL CLIENTE: Cuando el equipo de soporte informa al cliente la necesidad de mayor información al pasar el card del estado “en curso” al estado “Esperando por el cliente”, el cliente deberá responder. Si la incidencia permanece durante 6 días en estado “Esperando por el cliente” sin presentar actividad, el sistema enviará un mensaje de forma automática recordando que la incidencia está pendiente de respuesta. Si luego del recordatorio, la incidencia continúa en el mismo estado por 5 días más, el sistema notificará de forma automática el cierre del card en las siguientes 72 horas. Si a las 72 horas del último recordatorio el card sigue en estado “Esperando por el Cliente” el sistema interpreta que el card está Cancelado por inactividad y automáticamente lo pasa a estado “Cerrado”. Una vez cerrado el ticket, si el cliente necesita revisión, deberá generar un nuevo ticket.

EVALUACIÓN DE LA RESOLUCIÓN DE REQUERIMIENTOS

Una vez que el requerimiento pasa al estado “Cerrado”, el sistema envía un mail de notificación. En el mismo, se incluye una pregunta de satisfacción para evaluar el servicio de resolución. Solicitamos por favor  completarla dado que para nosotros es el feedback que nos ayuda a mejorar el servicio. 

Una vez recibida la respuesta de satisfacción, se da por cerrado el circuito de resolución de requerimientos.

Cordialmente, 

El equipo de Dos al Cubo.