El Ticket

Pensando en una herramienta que defina de modo celular la interacción entre las partes de la empresa me encuentro con “el ticket”, generalmente un amigo del alma muy mal comprendido. En su punto más básico, podríamos interpretarlo como una orden de trabajo, un lugar en el que pongo lo que necesito que alguien más haga, donde describo lo que deseo, para que quién lo lea pueda tomar mi requerimiento y realizarlo.

Vamos a ponernos sinceros, todos quisiéramos que la gente entienda las cosas que pedimos, simplemente pidiéndolas y en un mundo idílico, no debería hacer falta más que eso a modo de definición, pero necesitamos comprender los cambios en el tiempo que puede sufrir un documento tan fiel. Así que quizás haga falta un tanto de esfuerzo para unir puntos a y b, donde “A” es lo requerido y “B” es la satisfacción de todos los actores del juego, quién lo pidió, quién lo realizó y quién lo midió. Así lo que tenemos entre esos dos puntos son acciones que debemos realizar y que harán de nuestra experiencia algo mucho más positivo y completo que si tan sólo completaramos la tarea sin más.

PUNTO A

La “Creación” del Ticket

1. Identificar el problema o tener clara la sugerencia. (Pensar mucho para poder escribir menos)
2. Escribir un texto claro y lo más detallado posible, dividirlo en puntos si se prefiere.

El cosito del coso

Si nosotros no sabemos cómo pedir lo que queremos, difícilmente podamos quedar complacidos con lo que otro interprete.

Releer

Puede parecer simple sentido común, pero tendríamos que releer apuntando a ponernos en el lugar de la persona que va a recibir nuestros tickets, evitando asumir que quién lo va a leer, cuenta con otra información que no les brindamos.

El dónde, el cómo, el cuándo y el quién son siempre grandes puntales en un buen ticket

Mientras el “qué” estará siempre presente, es muy importante que los demás también aparezcan.

dónde

Dónde sucedió, el indicador de lugar es tremendamente importante, porque ubica el problema, la sugerencia o la idea en un contexto de lugar, físico o no.

cómo

Si tenemos información sobre cómo sucedió, o cómo podría lograrse algo, es de vital importancia que aparezca en el ticket a modo de sugerencia.

cuándo

• El time frame, ya sea el cuándo, el cuantas veces, o con qué periodicidad, permitirán siempre afinar la búsqueda de una solución.
• Asignar el ticket a alguien, en caso de desconocer a quién, buscar a alguien en la cadena de manera tal que si esa persona no nos lo resuelve, pueda derivarnos a quien sí puede. (Muchas veces en este caso nos podemos llegar a dar cuenta que a ese quién lo vemos cada día en el espejo)
• Acompañar de imágenes, archivos, notas, dibujos.

Fecha de vencimiento (Due date)

Muchas tareas necesitan de un time frame en particular. Cuando una tarea tiene que estar terminada en un tiempo determinado, ya sea porque hace falta para que otras tareas puedan desarrollarse o por alguna necesidad puntual, se debe llenar el campo Due Date, esto nos indica que este ticket debe ser completado antes de esa fecha.

El ticket vivo

El ticket está “durmiendo” hasta tanto encuentra su destinatario. Es activado, “despierta”, en el momento que se le asigna a alguien y este lo estima. Acto seguido, el mismo se incluye dentro de algún tipo de plan, ya sea personal, grupal o global. A partir de este momento, nuestro querido ticket sufrirá cambios.

Lectura del Ticket (si la creación fue adecuada)

1. Leer el ticket de punta a punta.
2. Determinar si el ticket está en la persona correcta.
3. Determinar si se está autorizado para recibir y hacerse cargo de ese ticket.
4. Observar/leer/interpretar la documentación.
5. Estimar el ticket en tiempo.
6. Priorizar la tarea, de ser necesario, en conjunto con líderes o pares.
7. Comenzar con los pases de estado de la misma.

Estimación

Se puede estimar una tarea bajo metodologías distintas, pero es importante tener en cuenta muchos factores, de los cuales, uno será el tiempo, pero otros tendrán que ver con recursos, equipos, interrelación con otros, los tiempos de demora posibles, etc...

El resultante de la suma de todos estos parámetros nos acercaran a la estimación más acertada posible.

No siempre nuestros planes se desarrollarán como esperamos, unas veces por propia impericia y otras cuando ciertas partes dependan de otros o de eventos fuera de nuestros control. Cuando esto suceda es de vital importancia volver a estimar y corregir el tiempo dado.

REestimación

Factores antes mencionados, ya sean o no ajenos a nosotros, deberían estar informados en el mismo ticket, así como todos los comentarios del mismo. Pero si sucede que nuestro time frame cambia, es nuestra responsabilidad como owners de ese ticket el re-estimar, ya sea para que otros que esperan sepan a que se atienen, o simplemente para poder llevar bien nuestras agendas. Pero si el tiempo en que tardaremos en completar esta tarea supera en un 20% lo estimado en un principio, debemos cambiar la estimación en el ticket.

En Proceso, on hold, blocked

Cuando comenzamos a realizar las tareas de un ticket lo pasamos a “En proceso”, de manera que otros sepan que nosotros estamos trabajando en él. Si algo lo detiene, por ejemplo una decisión que debe tomar otro, u otro ticket que debe estar terminado para poder seguir (acá vemos cuán importante es estimar y reestimar) lo vamos a pasar a “on hold” y si algo externo hace que sea imposible continuar, lo pondremos en “blocked” y otros sabrán que deben hacer lo mismo si esperaban a nuestro ticket para seguir con el de ellos.

Idas y vueltas

Todas las posibles idas y vueltas de información, decisiones, deben quedar apropiadamente referenciadas en nuestros tickets, aun si suceden en una conversación externa, ya que de esa manera producimos documentación viva. Y en el caso que mañana nuestro ticket deba ser tomado por alguien más, este tendrá todo el camino previo allanado.

Lista para ser testeada (Ready To Test)

Una vez terminadas las tareas lo dejaremos en Ready to test, de esta manera, alguien más vendrá a testear lo realizado, también podemos avisar a quién le “dió vida!” a nuestro adorado ticket, por pura cortesía. Si la tarea requiriera de un entorno o una condición necesaria para ser testeada, deberíamos dejar ese dato en el mismo ticket.

Lista para ser deployada (Ready to deploy)

Una vez que el fix o la feature fueron probados y aprobados se colocará la mejora en este estado, donde esperará a ser deployada, una vez más que fin mas loable que el de dar buenas noticias! un mail a quién creó el ticket es de muy buena educación.

En producción

Completaremos la fecha de “en producción” en el momento en que el ticket ha sido aprobado, deployado y cerrado.

Y así llegamos al PUNTO B en el qué, quién solicitó la tarea queda complacido con el resultado final, el que la realizó queda complacido con su trabajo y claro está el que lo mide queda complacido con los datos suministrados a la tarea, porque puede medir y calcular tiempos para la próxima vez. Y todos inconscientemente son más felices, porque ese ticket ahora es un proceso que puede contarnos cómo realizar esta tarea de forma simple. Pero aún más contento queda nuestro ticket que ahora es mucho más de lo que fue, ya que nació como incógnita y perdurará como una historia.

Autor: F. Mesaglio

#Liderazgo #Teamplayers #IT #CTO #Octopus #dirección #comunicación #coaching