Nuestra experiencia tras 1000 tickets de soporte
Llámalo SRE/Operaciones, llámalo el pegamento de los proyectos, llámalo equipo marronero: el departamento de SRE y operaciones es una parte fundamental del servicio de incidencias y tareas, y recientemente el equipo de Operaciones de Geko llegamos a nuestro ticket de Service Desk número 1000! Y como es costumbre en un medio que cambia a un ritmo tan acelerado, de mil tareas se sacan mil lecciones. En este artículo sobre «Nuestra experiencia tras 1000 tickets de soporte» te daremos algunos detalles.
¿Qué lecciones se pueden aplicar al crear tickets?
Hablemos de los detalles que puedes tener con el equipo que atiende tus tickets para que tus problemas salgan de la forma más ágil posible. Estas son los detalles que nos alegran el día cuando abrimos una cola de tareas.
¿Realmente este cambio es prioritario?
En este artículo sobre nuestra experiencia tras 1000 tickets de soporte te lo contamos.
El equipo de operaciones que hay detrás del panel de crear tickets se enfrenta cada día a una gran cantidad de cambios de contexto y debe ser capaz de priorizar rápidamente los problemas. Este tiempo de repriorización y de ajuste es algo que conlleva un tiempo de trabajo, e implica que quizá alguna de las tareas abiertas tarde más de lo necesario.
Si desde tu lado puedes priorizar esta tarea de forma realista, ese peso saliendo del equipo de soporte les permitirá trabajar y ayudar en tus problemas e incidencias de forma mucho más rápida y eficiente.
Producción caído no tiene la misma prioridad que crear un bucket de s3 para pre-producción, y si tú aplicas ese filtro antes de enviar el ticket del bucket, producción se podrá levantar antes. Eliminar overhead en un entorno tan cambiante es algo vital y hará tu trabajo mucho más ágil. Palabras de Picard:
¿Qué se necesita?
Cada vez que se cierra un ticket y se pasa a otro, debe ocurrir un switch mental para centrarse en la nueva tarea o incidente que se tiene delante. Esto tiene un coste de tiempo de comprender el problema que se presenta para averiguar la forma correcta de resolverlo. Aquí es donde entra cómo creas el ticket.
Volvamos al ejemplo anterior del ticket de prioridad baja. Imagina que quieres crear un bucket de s3 en aws, y que entráis 2 tickets iguales al mismo tiempo. El tuyo dice «necesito un bucket de s3». Sin más. Y el otro ticket ha especificado que quiere un bucket de s3, con qué objetivo, qué permisos entiende que necesita, con qué nombre y la política de retención de versionado.
¿Tu ticket parece mucho más sencillo, verdad? Si simplemente necesitas un bucket! Bueno, pues te garantizo que el equipo de operaciones se pegará por el segundo ticket y el primero se moverá un puesto abajo en la prioridad. La persona que llegue a atenderlo te pedirá todos los detalles que ha dado el segundo ticket y automáticamente saldrá de tu contexto para ponerse con otra tarea mientras respondes de manera asíncrona, y ya has perdido un tiempo de reacción.
Desde operaciones queremos mucho al que suelta un bloque de documentación en la descripción de tarea. Documentación, documentación, documentación. Nos facilita la vida!
¿Qué has tocado?
Si algo entiende el equipo de operaciones es que todo el mundo comete errores de vez en cuando. Arreglar liadas, sean nuestras o de otros, es el pan de cada día. Pero no podemos ayudar a solucionar un problema si no sabemos cómo se ha originado, por eso se debe dar toda la información posible sobre qué se ha intentado ya, o qué se modificó para que se rompiera, para que el equipo marronero pueda enfrentarse al marrón de la forma más eficiente posible.
Sin esa información, tras priorizar el incidente se irán dando más palos de ciego de los necesarios, y el entorno estará roto más tiempo. Mentirle a tu equipo de Operaciones es como mentirle a tu enfermera: sólo te traerá más desgracias, y puedes tener por seguro que no les va a sorprender. Ya hemos visto de todo.
¿Y del lado de operaciones?
No todo es aprendizaje de lo que pedimos a quien crea un ticket. Acordarse de un ticket que sólo has llevado tú funciona cuando sois 2 personas en operaciones (en el caso de Geko, los @ivanes que fuimos el inicio del departamento), pero esta práctica no escala con el crecimiento de volumen de tareas o clientes.
Si el service manager identifica que se debe reestructurar carga y se debe pasar la ownership de un ticket a medio hacer, ese ticket debe estar bien documentado en cuanto a acciones realizadas, bloqueadores y estado actual. No hay nada peor que un ticket vacío a medio hacer, y el receptor de la tarea lanzará deshonra sobre ti, y deshonra sobre tu vaca. Además tendrás que explicárselo todo.
Un equipo de operaciones ágil y eficiente suena genial!
Si tienes un equipo de operaciones interno, una de dos: o debes aplicarte este blog sobre «Nuestra experiencia tras 1000 tickets de soporte» para mejorarles la vida diaria y que te lo agradezcan, o te lo han enviado como indirecta muy directa. En ambos casos, estos consejos mejorarán el funcionamiento del equipo, y es algo que tras (ya más de) 1000 tickets de soporte tenemos más que comprobado.
Si por lo contrario aún no tienes equipo de operaciones y ves que esta agilidad te sería útil en tu día a día, sentémonos a charlar y te ayudaremos a liberarte de los problemas frecuentes y que te centres en lo importante.
