¿Le gusta distraerse resolviendo problemas urgentes en los chats de trabajo mientras realiza las tareas actuales? Nosotros pensamos que no!
Imagine una situación: está comenzando una tarea, pero se distrae con una notificación en el chat, en la que se le pide con urgencia que ayude con una pregunta del usuario. Y ahora ya estás participando en una discusión activa y entiendes si esto es un error o una característica.
Ahora imagine que además de usted, esta sala de chat tiene todo el departamento de desarrollo, compuesto por más de 80 personas, y cada uno de los participantes está involucrado en estas discusiones.
En nuestro SuperJob, el soporte técnico en cualquier situación incomprensible conversó inmediatamente en Slack y, por lo tanto, distrajo a todos los participantes de las actividades actuales. Por lo tanto, nosotros, el departamento de pruebas, intentamos cambiar el proceso de trabajar con errores de los usuarios.
Anteriormente, el proceso de trabajar con errores de los usuarios era el siguiente:
- Comentarios recibidos del usuario y transmitidos al especialista de soporte técnico;
- un especialista en soporte técnico descubrió los detalles, pero no reprodujo el problema, pero inmediatamente comenzó una tarea en Jira en el proyecto de soporte técnico;
- la tarea fue lanzada a una sala de chat separada en Slack (y había 6 de ellos, por cierto, sobre los problemas de los solicitantes, empleadores y para cada plataforma en las aplicaciones);
- En el chat, el probador tomó esta tarea y comenzó a comprender, localizar el problema y descubrir cómo debería funcionar;
- Además del probador, los desarrolladores también participaron en el chat y participaron activamente en la discusión;
- Después de todas las aclaraciones, el probador transfirió la tarea al proyecto de desarrollo deseado, cambió el nombre y corrigió la descripción.
Al final, resultó que varios expertos dedicaron mucho tiempo a discutir y verificar dos veces un problema a la vez. Además, la descripción de la tarea no siempre le permitió comprender rápidamente la esencia del problema, por lo que tuvo que abrir la correspondencia de soporte técnico con el usuario y luego pasar más tiempo editando esta tarea.
Muchos problemas no fueron errores y generalmente no deberían llegar a los desarrolladores. Pero al mismo tiempo, los desarrolladores ya estaban involucrados en el proceso de discusión, distrayéndose de sus tareas.
Decidimos que necesitamos cambiar este proceso y hacer que el soporte técnico sea más independiente.
Lo primero que queríamos cambiar era
deshacernos de la doble verificación del error por parte del probador.La solución fue esta: describimos el flujo de trabajo en el que trabajan los probadores, lo transformamos ligeramente y se lo entregamos a especialistas de soporte técnico. Ahora tenían que pasar por eso cuando trabajaban con un problema del usuario.
Describa brevemente este flujo de trabajo, ahora el especialista en soporte técnico verifica de forma independiente los requisitos antes de iniciar el error, necesariamente reproduce el error y coloca la tarea en el proyecto de desarrollo.
Si la situación no se reproduce, la tarea se inicia en el proyecto de soporte técnico y se "suspende" hasta el siguiente contacto del usuario. Si hay nuevas solicitudes de los usuarios, el centro técnico debe intentar nuevamente reproducir el problema y, si se reproduce, transferir la tarea al proyecto de desarrollo.
Si la queja reiterada tampoco se reproduce, la tarea aún se transfiere al proyecto de desarrollo con el comentario obligatorio de que el problema no se puede reproducir. Quizás en esta situación, los desarrolladores, por su parte, podrán resolver y resolver el problema.
Por lo tanto, no pasamos mucho tiempo en llamadas individuales y solo en caso de llamadas repetidas conectamos a los desarrolladores.
Pros: ahorramos el tiempo del especialista en pruebas y, a menudo, también de los desarrolladores que vieron la pregunta en el chat y se conectaron a las aclaraciones.
Nuestro segundo problema fue el
diseño de los propios errores , que tenían
nombre poco informativo, caótico y, a veces, solo una descripción misteriosa.
Por ejemplo:
Solución: a través de ejemplos, contamos y mostramos cómo componimos un nombre para un error utilizando el principio de "¿Qué? Donde ¿Cuándo?
Por ejemplo, el nombre de la tarea "Problemas de" Trabajos en su sitio "después del procesamiento se ha vuelto más transparente:" Los trabajos en el bloque "Trabajos en su sitio" no se muestran cuando va a la sección de difusión ". Qué tipo de "problema" ocurrió, quedó claro para todos solo por el nombre.
Acordamos usar plantillas para la descripción. Los hemos agregado a Jira. Al crear un error, debe seleccionar la plantilla deseada según la plataforma y completarla.
Toda la información se registra en las instrucciones de Confluence, a las que siempre se puede acceder.
Pros: se hizo más fácil buscar errores en Jira, y por el nombre puedes determinar inmediatamente cuál es la esencia sin entrar en la tarea. La descripción se ha estructurado y es más comprensible para los desarrolladores.
La tercera distracción de todos es la
presencia de varias salas de chat con soporte técnico.
Solución: "¡Más salas de chat!"Decidimos hacer solo un chat de #support y cerrar el resto. Ahora todos los empleados internos se ven afectados por los problemas encontrados, y solo los técnicos de soporte responden allí. Realizan revisiones y comienzan tareas.
Pros: ahora hay un punto de entrada donde puede informar un problema encontrado.
Anteriormente, los desarrolladores podían ver algún tipo de error, pero simplemente no sabían dónde informarlo. Primero tenías que averiguar qué chat lanzar. Es difícil ... Por lo tanto, algunos simplemente no se molestaron y dejaron todo como está (bueno, o las personas especialmente conscientes arrojaron a los probadores).
Pero, por supuesto, hubo algunas dificultades para implementar este enfoque. Por ejemplo, un especialista en soporte técnico no siempre puede localizar correctamente un problema, determinar si se trata de un back-end o frontend. Y debido a esto, existe el riesgo de que se produzca un error en el proyecto incorrecto o en el equipo equivocado, y luego nuevamente perder tiempo en la transferencia de tareas de una sección a otra.
Todavía hay errores en las descripciones y nombres de errores. Por lo tanto, si bien es necesario analizar las tareas para eliminar estas deficiencias, su número no es tan crítico.
Después de todas las innovaciones, nuestro flujo de trabajo se ve así:
- los especialistas de soporte técnico se han vuelto más independientes, no necesitan esperar a que los evaluadores verifiquen dos veces el error;
- un error del usuario se inicia en Jira más rápido y se puede implementar antes;
- los evaluadores y desarrolladores no se distraen de sus tareas;
- los desarrolladores ahora pueden
organizar holivar para chatear en salas de chat sobre temas más interesantes.
¿Y cómo se organiza el proceso de trabajar con errores de los usuarios en su empresa? Comparte tus ejemplos :)