Muchos expertos en el campo del desarrollo de software creen que es imposible combinar el desarrollo y la asistencia al usuario en un equipo. Uno u otro. En general, se debe brindar apoyo a las personas.
Hoy quiero contarles cómo en Odobrim.ru logramos combinar lo incompatible, o más bien, cómo el equipo de desarrollo puede apoyar los productos. Esa será una línea de soporte 2-3 al mismo tiempo.
Odobrim.ru es un servicio gratuito en línea para seleccionar tarjetas de crédito, préstamos y préstamos para particulares, independientemente de los bancos.
Nuestra tarea : ayudar al cliente a obtener y mantener el producto de préstamo óptimo que resuelva las tareas del cliente.
El proceso de manejo de llamadas se estructura de la siguiente manera
1. El “Servicio de atención al cliente” se encarga de nuestros clientes, la primera línea de soporte. Sí, sí, en buenos lugares existe :))
El "Servicio de atención al cliente" ayuda a los usuarios con todas las preguntas que surgen al trabajar con el servicio. Cualquier empresa que se preocupe por sus clientes debe tener una primera línea de soporte, con la que puede contactar para obtener asistencia las 24 horas.
Si el "Servicio de Atención al Cliente" pudo ayudar al cliente, la siguiente línea no comenzará. De lo contrario, la apelación se inicia y se transmite a la siguiente línea. Nada sobrenatural hasta ahora.
Y después de eso, generalmente hay dos líneas de soporte más, pero tenemos una: combinamos las líneas de soporte segunda y tercera. Esto sucedió después de que el producto ingresó al mercado, por lo que hemos estado viviendo durante aproximadamente dos años. ¡Y vivimos perfectamente!
2. El seguimiento de las solicitudes de los usuarios se realiza periódicamente.
El ingeniero de turno es llamado voluntariamente para una llamada de servicio semanal.
Un tablero de referencia es similar a un tablero Kanban.
Todo está muy convenientemente configurado en él:
3. La clasificación inicial de la apelación la realiza el ingeniero de servicio y, en función de sus resultados, se crea por separado Bug (error con referencia a la documentación / requisitos) o Story (tarea). Están unidos a la circulación. Tenemos los plazos para corregir errores y el asistente está tratando de atraparlos.
4. En la siguiente etapa, los desarrolladores corrigen el error corregido (bloqueador, crítico). Luego, la verificación y la confirmación de la corrección son realizadas por el ingeniero de servicio
5. La historia (tarea) se transfiere a PO (propietario del producto) para priorizar.
Durante 2 años, el equipo de desarrollo ha procesado más de 270 llamadas de diferentes prioridades de nuestra unidad de negocios y usuarios entre aquellos que la primera línea de soporte no pudo manejar.
Pros de este enfoque
- Las apelaciones de clientes y unidades de negocios no se pierden y se recopilan en una junta.
- El equipo ve todos los problemas principales del producto y está interesado en resolverlos, es decir, se está acercando a los usuarios de su servicio, lo que afecta positivamente la calidad del servicio y el producto en su conjunto.
- Cada desarrollador, al darse cuenta de que tendrá que estar de guardia en las llamadas, intenta escribir mejor el código para no crear problemas adicionales para él y sus colegas.
- Siempre hay un ingeniero responsable.
- La participación del equipo en la resolución de problemas comunes de productos está creciendo.
- Monitoreo constante sin regulaciones adicionales.
Contras de este enfoque
Los miembros del equipo requieren un alto nivel de profesionalismo, responsabilidad e interés. Y el coraje de ser llamado de guardia.
Si ha encontrado esquemas de organización de soporte similares, comparta su experiencia en los comentarios.