\u00bfQu\u00e9 lecciones se pueden aplicar al crear tickets?<\/strong><\/h2>\nHablemos de los detalles que puedes tener con el equipo que atiende tus tickets para que tus problemas salgan de la forma m\u00e1s \u00e1gil posible. Estas son los detalles que nos alegran el d\u00eda<\/strong> cuando abrimos una cola de tareas.<\/p>\n\u00bfRealmente este cambio es prioritario?<\/strong><\/h2>\nEn este art\u00edculo sobre nuestra experiencia tras 1000 tickets de soporte te lo contamos.<\/p>\n
El equipo de operaciones que hay detr\u00e1s del panel de crear tickets se enfrenta cada d\u00eda a una gran cantidad de cambios de contexto<\/strong> y debe ser capaz de priorizar r\u00e1pidamente los problemas. Este tiempo de repriorizaci\u00f3n<\/strong> y de ajuste<\/strong> es algo que conlleva un tiempo de trabajo, e implica que quiz\u00e1 alguna de las tareas abiertas tarde m\u00e1s de lo necesario.<\/p>\nSi desde tu lado puedes priorizar esta tarea de forma realista<\/strong>, ese peso saliendo del equipo de soporte les permitir\u00e1 trabajar y ayudar en tus problemas e incidencias de forma mucho m\u00e1s r\u00e1pida y eficiente.<\/p>\nProducci\u00f3n ca\u00eddo no tiene la misma prioridad que crear un bucket de s3 para pre-producci\u00f3n, y si t\u00fa aplicas ese filtro antes de enviar el ticket del bucket, producci\u00f3n se podr\u00e1 levantar antes. Eliminar overhead<\/strong> en un entorno tan cambiante es algo vital y har\u00e1 tu trabajo mucho m\u00e1s \u00e1gil. Palabras de Picard:<\/p>\n![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2022\/07\/picard-priorities-300x106.png\")
<\/p>\n
\u00bfQu\u00e9 se necesita?<\/strong><\/h2>\nCada 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<\/strong> que se presenta para averiguar la forma correcta de resolverlo. Aqu\u00ed es donde entra c\u00f3mo creas el ticket.<\/p>\nVolvamos al ejemplo anterior del ticket de prioridad baja. Imagina que quieres crear un bucket de s3 en aws, y que entr\u00e1is 2 tickets iguales al mismo tiempo. El tuyo dice \u00abnecesito un bucket de s3\u00bb. Sin m\u00e1s<\/strong>. Y el otro ticket ha especificado<\/strong> que quiere un bucket de s3, con qu\u00e9 objetivo, qu\u00e9 permisos entiende que necesita, con qu\u00e9 nombre y la pol\u00edtica de retenci\u00f3n de versionado.<\/p>\n\u00bfTu ticket parece mucho m\u00e1s sencillo, verdad? Si simplemente necesitas un bucket! Bueno, pues te garantizo que el equipo de operaciones se pegar\u00e1 por el segundo ticket y el primero se mover\u00e1 un puesto abajo en la prioridad. La persona que llegue a atenderlo te pedir\u00e1 todos los detalles que ha dado el segundo ticket y autom\u00e1ticamente saldr\u00e1 de tu contexto para ponerse con otra tarea mientras respondes de manera as\u00edncrona, y ya has perdido un tiempo de reacci\u00f3n<\/strong>.<\/p>\nDesde operaciones queremos mucho al que suelta un bloque de documentaci\u00f3n en la descripci\u00f3n de tarea. Documentaci\u00f3n<\/strong>, documentaci\u00f3n<\/strong>, documentaci\u00f3n<\/strong>. Nos facilita la vida!<\/p>\n\u00bfQu\u00e9 has tocado?<\/strong><\/h2>\nSi 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\u00eda. Pero no podemos ayudar a solucionar un problema si no sabemos c\u00f3mo se ha originado, por eso se debe dar toda la informaci\u00f3n posible<\/strong> sobre qu\u00e9 se ha intentado ya, o qu\u00e9 se modific\u00f3 para que se rompiera, para que el equipo marronero pueda enfrentarse al marr\u00f3n de la forma m\u00e1s eficiente posible.<\/p>\nSin esa informaci\u00f3n, tras priorizar el incidente se ir\u00e1n dando m\u00e1s palos de ciego de los necesarios<\/strong>, y el entorno estar\u00e1 roto m\u00e1s tiempo. Mentirle a tu equipo de Operaciones es como mentirle a tu enfermera: s\u00f3lo te traer\u00e1 m\u00e1s desgracias, y puedes tener por seguro que no les va a sorprender. Ya hemos visto de todo<\/strong>.<\/p>\n\u00bfY del lado de operaciones?<\/strong><\/h2>\nNo todo es aprendizaje de lo que pedimos a quien crea un ticket. Acordarse de un ticket que s\u00f3lo has llevado t\u00fa funciona cuando sois 2 personas<\/strong> en operaciones (en el caso de Geko, los @ivanes que fuimos el inicio del departamento), pero esta pr\u00e1ctica no escala<\/strong> con el crecimiento de volumen de tareas o clientes.<\/p>\n
\u00bfRealmente este cambio es prioritario?<\/strong><\/h2>\nEn este art\u00edculo sobre nuestra experiencia tras 1000 tickets de soporte te lo contamos.<\/p>\n
El equipo de operaciones que hay detr\u00e1s del panel de crear tickets se enfrenta cada d\u00eda a una gran cantidad de cambios de contexto<\/strong> y debe ser capaz de priorizar r\u00e1pidamente los problemas. Este tiempo de repriorizaci\u00f3n<\/strong> y de ajuste<\/strong> es algo que conlleva un tiempo de trabajo, e implica que quiz\u00e1 alguna de las tareas abiertas tarde m\u00e1s de lo necesario.<\/p>\nSi desde tu lado puedes priorizar esta tarea de forma realista<\/strong>, ese peso saliendo del equipo de soporte les permitir\u00e1 trabajar y ayudar en tus problemas e incidencias de forma mucho m\u00e1s r\u00e1pida y eficiente.<\/p>\nProducci\u00f3n ca\u00eddo no tiene la misma prioridad que crear un bucket de s3 para pre-producci\u00f3n, y si t\u00fa aplicas ese filtro antes de enviar el ticket del bucket, producci\u00f3n se podr\u00e1 levantar antes. Eliminar overhead<\/strong> en un entorno tan cambiante es algo vital y har\u00e1 tu trabajo mucho m\u00e1s \u00e1gil. Palabras de Picard:<\/p>\n<\/p>\n
\u00bfQu\u00e9 se necesita?<\/strong><\/h2>\nCada 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<\/strong> que se presenta para averiguar la forma correcta de resolverlo. Aqu\u00ed es donde entra c\u00f3mo creas el ticket.<\/p>\nVolvamos al ejemplo anterior del ticket de prioridad baja. Imagina que quieres crear un bucket de s3 en aws, y que entr\u00e1is 2 tickets iguales al mismo tiempo. El tuyo dice \u00abnecesito un bucket de s3\u00bb. Sin m\u00e1s<\/strong>. Y el otro ticket ha especificado<\/strong> que quiere un bucket de s3, con qu\u00e9 objetivo, qu\u00e9 permisos entiende que necesita, con qu\u00e9 nombre y la pol\u00edtica de retenci\u00f3n de versionado.<\/p>\n\u00bfTu ticket parece mucho m\u00e1s sencillo, verdad? Si simplemente necesitas un bucket! Bueno, pues te garantizo que el equipo de operaciones se pegar\u00e1 por el segundo ticket y el primero se mover\u00e1 un puesto abajo en la prioridad. La persona que llegue a atenderlo te pedir\u00e1 todos los detalles que ha dado el segundo ticket y autom\u00e1ticamente saldr\u00e1 de tu contexto para ponerse con otra tarea mientras respondes de manera as\u00edncrona, y ya has perdido un tiempo de reacci\u00f3n<\/strong>.<\/p>\nDesde operaciones queremos mucho al que suelta un bloque de documentaci\u00f3n en la descripci\u00f3n de tarea. Documentaci\u00f3n<\/strong>, documentaci\u00f3n<\/strong>, documentaci\u00f3n<\/strong>. Nos facilita la vida!<\/p>\n\u00bfQu\u00e9 has tocado?<\/strong><\/h2>\nSi 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\u00eda. Pero no podemos ayudar a solucionar un problema si no sabemos c\u00f3mo se ha originado, por eso se debe dar toda la informaci\u00f3n posible<\/strong> sobre qu\u00e9 se ha intentado ya, o qu\u00e9 se modific\u00f3 para que se rompiera, para que el equipo marronero pueda enfrentarse al marr\u00f3n de la forma m\u00e1s eficiente posible.<\/p>\nSin esa informaci\u00f3n, tras priorizar el incidente se ir\u00e1n dando m\u00e1s palos de ciego de los necesarios<\/strong>, y el entorno estar\u00e1 roto m\u00e1s tiempo. Mentirle a tu equipo de Operaciones es como mentirle a tu enfermera: s\u00f3lo te traer\u00e1 m\u00e1s desgracias, y puedes tener por seguro que no les va a sorprender. Ya hemos visto de todo<\/strong>.<\/p>\n\u00bfY del lado de operaciones?<\/strong><\/h2>\nNo todo es aprendizaje de lo que pedimos a quien crea un ticket. Acordarse de un ticket que s\u00f3lo has llevado t\u00fa funciona cuando sois 2 personas<\/strong> en operaciones (en el caso de Geko, los @ivanes que fuimos el inicio del departamento), pero esta pr\u00e1ctica no escala<\/strong> con el crecimiento de volumen de tareas o clientes.<\/p>\n
Si desde tu lado puedes priorizar esta tarea de forma realista<\/strong>, ese peso saliendo del equipo de soporte les permitir\u00e1 trabajar y ayudar en tus problemas e incidencias de forma mucho m\u00e1s r\u00e1pida y eficiente.<\/p>\n Producci\u00f3n ca\u00eddo no tiene la misma prioridad que crear un bucket de s3 para pre-producci\u00f3n, y si t\u00fa aplicas ese filtro antes de enviar el ticket del bucket, producci\u00f3n se podr\u00e1 levantar antes. Eliminar overhead<\/strong> en un entorno tan cambiante es algo vital y har\u00e1 tu trabajo mucho m\u00e1s \u00e1gil. Palabras de Picard:<\/p>\n 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<\/strong> que se presenta para averiguar la forma correcta de resolverlo. Aqu\u00ed es donde entra c\u00f3mo creas el ticket.<\/p>\n Volvamos al ejemplo anterior del ticket de prioridad baja. Imagina que quieres crear un bucket de s3 en aws, y que entr\u00e1is 2 tickets iguales al mismo tiempo. El tuyo dice \u00abnecesito un bucket de s3\u00bb. Sin m\u00e1s<\/strong>. Y el otro ticket ha especificado<\/strong> que quiere un bucket de s3, con qu\u00e9 objetivo, qu\u00e9 permisos entiende que necesita, con qu\u00e9 nombre y la pol\u00edtica de retenci\u00f3n de versionado.<\/p>\n \u00bfTu ticket parece mucho m\u00e1s sencillo, verdad? Si simplemente necesitas un bucket! Bueno, pues te garantizo que el equipo de operaciones se pegar\u00e1 por el segundo ticket y el primero se mover\u00e1 un puesto abajo en la prioridad. La persona que llegue a atenderlo te pedir\u00e1 todos los detalles que ha dado el segundo ticket y autom\u00e1ticamente saldr\u00e1 de tu contexto para ponerse con otra tarea mientras respondes de manera as\u00edncrona, y ya has perdido un tiempo de reacci\u00f3n<\/strong>.<\/p>\n Desde operaciones queremos mucho al que suelta un bloque de documentaci\u00f3n en la descripci\u00f3n de tarea. Documentaci\u00f3n<\/strong>, documentaci\u00f3n<\/strong>, documentaci\u00f3n<\/strong>. Nos facilita la vida!<\/p>\n 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\u00eda. Pero no podemos ayudar a solucionar un problema si no sabemos c\u00f3mo se ha originado, por eso se debe dar toda la informaci\u00f3n posible<\/strong> sobre qu\u00e9 se ha intentado ya, o qu\u00e9 se modific\u00f3 para que se rompiera, para que el equipo marronero pueda enfrentarse al marr\u00f3n de la forma m\u00e1s eficiente posible.<\/p>\n Sin esa informaci\u00f3n, tras priorizar el incidente se ir\u00e1n dando m\u00e1s palos de ciego de los necesarios<\/strong>, y el entorno estar\u00e1 roto m\u00e1s tiempo. Mentirle a tu equipo de Operaciones es como mentirle a tu enfermera: s\u00f3lo te traer\u00e1 m\u00e1s desgracias, y puedes tener por seguro que no les va a sorprender. Ya hemos visto de todo<\/strong>.<\/p>\n No todo es aprendizaje de lo que pedimos a quien crea un ticket. Acordarse de un ticket que s\u00f3lo has llevado t\u00fa funciona cuando sois 2 personas<\/strong> en operaciones (en el caso de Geko, los @ivanes que fuimos el inicio del departamento), pero esta pr\u00e1ctica no escala<\/strong> con el crecimiento de volumen de tareas o clientes.<\/p>\n<\/p>\n\u00bfQu\u00e9 se necesita?<\/strong><\/h2>\n
\u00bfQu\u00e9 has tocado?<\/strong><\/h2>\n
\u00bfY del lado de operaciones?<\/strong><\/h2>\n