Blog

Si bien es obvio, considero importante aclarar que la primera acción luego de haber detectado/identificado una incidencia, es registrarla y hacerla pública entre los miembros del equipo de proyecto asignados para su análisis, resolución y seguimiento.

Ahora bien, reportar en sí mismo la incidencia encontrada no es una tarea sencilla muchas veces, ésto es debido a una cierta cantidad de factores que pueden «jugar» en contra.

Entiéndase por «incidencia» a toda:
– anomalía;
– consulta;
– mejora;
– inconsistencia;

Ahora bien, a partir de la forma en que se reporta la incidencia identificada, y cuanta mayor información (y de calidad/valor) se ofrezca , mayores posibilidades de que sea resuelta en tiempo y en forma habrá, ya que hay que ponerse a pensar que antes de que nos llegue a nosotros la corrección puede «estar pasando por muchas manos»!.

Este último comentario refiere a los casos en los cuales, y dependiendo de la organización definida, el primer filtro lo haga el Analista Funcional para determinar si la incidencia tiene que ver con el requerimiento para ese momento «en juego» o se encuentra fuera del alcance para la entrega comprometida y planificada.

En caso de no corresponder para esa entrega y ser verdaderamente una incidencia, se la tratará de acuerdo con lo que se haya definido dentro del proyecto.

Si se trata de una incidencia y corresponde a esa entrega, pasará al Desarrollador quien efectuará una nueva evaluación de la misma, y aquí se podrá estar generando otro filtro ya que el análisis será también distinto.

Hay que saber/reconocer que la mayoría de los Desarrolladores (entiéndase Programador) nos pueden rechazar un reporte por estar mal escritos, con poca información, con insuficientes evidencias, etc etc etc

Por tanto, cuánto mejor analicemos la incidencia identificada y cuánto mejor sea la descripción que hagamos de la misma acompañada con la suficiente evidencia como para permitir que el Analista Funcional y/o Desarrollador puede entender que aplica para la entrega comprometida y se pueda reproducir, nuestro trabajo habrá sido eficiente y eficaz.

El tema aquí es explicar qué se estaba haciendo y cómo llegar al punto. Tarea a veces, no tan sencilla!, y si nos ponemos a pensar en forma global, el Desarrollador debe encontrar la «causa raíz», foco del problema dentro del código, debuggearlo para después corregirlo.

Hasta aquí, esta presentado el contexto general, ahora hay que pensar cómo reportarlo.

Bien.

Hay organizaciones que poseen herramientas colaborativas (open source o aranceladas) para la registración de las tareas, mientras que otras carentes de ellas, utilizan productos por todos conocidos como planillas de cálculos y/o procesadores de texto.

Para este último caso, obviamente la gestión de la información será mucho más dificultosa (actualización y versionado, entre otros temas).

No obstante, los aspectos importantes a considerar deberán ser:
– la incidencia debe tener un número identificativo;
– escribir un título del tipo 3C (claro, concreto y corto)
– explicar de manera clara cuál es el problema
– explicitar en qué entorno se origina
– centrarse en el problema y evitar dispersarse
– utilizar el mismo formato de reporte en todos los casos
– incluir evidencia con el estado de los elementos antes y después de la ocurrencia
– detallar los datos con los que se probó
– describir el paso a paso de forma detallada

además de estos aspectos globales, de más esta decir que habrá que comunicar:
– el usuario informador
– el usuario asignado
– el sistema/módulo
– la versión afectada y la fixeada
– la plataforma
– la prioridad
– la criticidad
– el estado
entre otros

Hay experiencias en donde he tenido que producir evidencias como:
– captura de pantallas;
– video explicando el camino para llegar a la ocurrencia;
– audio explicando qué ocurrió y cómo reproducirlo;
– logs en sus distintos formatos;
– registros de la base de datos exportada;

en fin, no debe haber «techo» para nuestra imaginación en lo que concierne a producir la «evidencia» suficiente que le permita a las otras partes del equipo, analizar la incidencia, reproducirla, y corregirla.

No hay que olvidarse que después, debemos «re probarla» y puede ser que la recibamos nosotros u otro miembro del equipo, totalmente alejado del tema.

Y así, finalmente cuando se logra reproducir y corregir la incidencia, lo festejamos!!!!

¿Tu gestión es algo parecido a lo descripto?

¿Tienes para manejar este tipo de situaciones herramientas colaborativas?

¿Es suficiente esta información o a tu entender, habría que incorporar algo más?