Cómo enseñar a sus usuarios / clientes a enviar mejores descripciones de errores

A menudo tengo que tratar con clientes o usuarios que informan errores en las aplicaciones. La mayoría de las veces su contenido es algo inútil como

• ¡¡¡ERROR!!!
• x no funciona

Sin mucha más información.

Para resolver el problema, tengo que solicitar cada detalle de ellos, lo que a menudo lleva más tiempo que solucionar el problema en sí. Otros envían información en formatos que no son ideales, como capturas de pantalla (de registros de datos, no de errores) aunque podrían enviar un enlace (tenemos acceso a los sistemas), etc.

¿Cómo les dice a sus usuarios / clientes que describan los problemas con más detalles para que todo el proceso sea más fácil para ambas partes?

editar

Esta pregunta trata más sobre las habilidades sociales que sobre cómo lograr la recopilación programática de registros e información de errores. Soy consciente del hecho de que esto debería ser parte de un buen diseño de software.

Recompense a sus usuarios por los buenos informes de errores, castíguelos por los malos (bueno, al menos un poco).

El usuario debe comprender que un buen informe de errores es esencial para que pueda solucionar el problema rápidamente y, por lo tanto, también es bueno para él, ya que obtendrá la solución mucho más rápido.

Entonces, la primera respuesta podría ser algo así como "Está bien, he leído su informe pero no sé por dónde empezar. ¿Puede decirme: ¿Ha sucedido esto una vez? ¿Es un fenómeno recurrente? ¿Podría probar X y decirme qué? ¿Y parece después de eso? y así.

Muy a menudo, cuando las personas reciben este tipo de comentarios diciéndoles qué hacer y diciéndoles (directa o indirectamente) lo que no hicieron en primer lugar, aprenderán. Tal vez no de inmediato, pero cuantos más informes estén presentando, más anticiparán (a menudo inconscientemente) lo que les preguntará y proporcionarán la respuesta directamente.

Sí, este es un proceso paso a paso y no solucionará todos los problemas de comunicación hasta mañana por la mañana, pero de todos modos es un comienzo.

Una cosa que he visto hacer en varios proyectos de código abierto es escribir un "formulario" estándar para los informes de errores, con secciones para la información comúnmente necesaria.

Si tiene un sitio o aplicación de informes de errores a los que sus clientes tienen acceso, vea si puede hacer que una versión en blanco sea el texto predeterminado del campo de descripción del error. De lo contrario, colóquelo en un lugar donde puedan encontrarlo (o donde pueda señalarlos), por ejemplo, en su sitio o en el directorio de instalación de su producto.

Para su caso, esto podría ser algo como:

URL where the error occurred:

What you did:

What you expected to happen:

What actually happened:

<Some other information you (ckeller & colleagues) often find useful>:

Any extra information you think might be relevant:

("Usted" aquí se refiere a los clientes)

La idea es alentarlos a proporcionar información útil al proporcionar una lista del tipo de información que con mayor frecuencia es útil.

Por lo general, les pido una captura de pantalla del error cada vez, y eventualmente comienzan a enviarme la captura de pantalla con su solicitud de error porque saben que lo pediré.

Todavía tengo que llamarlos para obtener más información en ocasiones, pero a menudo puedo ver el problema solo mirando la captura de pantalla

Pero estoy de acuerdo con el comentario de @ Mahmoud de que la mejor manera es hacer que la aplicación le envíe errores en lugar de depender de los usuarios.

La toma pesimista: no puedes. Es la misma situación que hace 40 años, excepto que hay más usuarios, más sistemas, más aplicaciones.

(Tenga en cuenta que un pesimista es solo un optimista con experiencia).

Haz que sea fácil para ellos hacerlo o no lo harán.

Preferiblemente, haga la forma más fácil de informar un error de la manera que le brinde la información que necesita. Esto casi seguro significa automatizar el proceso de informe de errores en el software.

Mantener un archivo de registro detallado y adjuntarlo al informe de error es un comienzo.

Cuando termine la conversación con el cliente, dígales "La próxima vez que esto suceda, tenga los elementos de datos A, B, C, etc. listos para mí". Por supuesto, esto solo funciona si estos son los mismos clientes que llaman repetidamente. He tenido éxito con este enfoque, donde los usuarios aprendieron ciertas cosas clave que podrían a) acelerar la llamada, b) hacer que la resolución general sea mucho más rápida.

Si la mayoría de ellos son personas que llaman por única vez, sería mejor actualizar el "ERROR". pantalla con texto que dice "Debe reunir los elementos de datos A, B, C, ... antes de hablar con nuestros representantes". Esto realmente dependerá de cuánto control tenga sobre la aplicación, por lo que es posible que no sea factible. Esta tampoco es una forma segura, pero espero que se le ocurra a la idea del cliente gritar "¡ERRORZ PLZ HLP!" no es suficiente.

El problema con los mensajes de error en las aplicaciones modernas es que es prácticamente imposible incluir todo el contexto que pueda ser relevante. Cualquier cosa, desde la arquitectura del procesador hasta la hora del día, puede ser relevante, por lo que tanto el informe de errores como el manejo de errores son más arte que ciencia. Los sistemas como apport-bugson útiles porque recopilan información relevante y se la envían. Desafortunadamente, hasta los días de los replicadores de materia, los viajes en el tiempo y los compensadores de Heisenberg, no hay forma de estar seguros de que la información que obtengan de los usuarios será suficiente para depurar o incluso reproducir el problema.

Registra todo lo que necesitas . Tenemos un archivo de registro continuo de x mb. Si sucede algo malo, el usuario envía el archivo de registro y, a menudo, es suficiente para solucionar un problema.

Otra opción es usar un cliente de escritorio remoto para ver por usted mismo qué está mal. En estos días eso es tan fácil como dejar que el cliente descargue un exe.

Tendrás que hacer preguntas puntuales y ser muy exigente con ellos para darte todas las respuestas. A veces su queja del problema se intercala con sus planes para el fin de semana, las quejas sobre su pareja o el clima. Trate de mantenerlos en la tarea y pregúnteles: "Ok, cuando haces X pero no haces Y, ¿qué pasa?" Anote sus respuestas para que comience a construir un diagrama de secuencia de eventos que luego pueda volver y depurar.

Puede invertir algo de tiempo y agregar un botón rojo 'Informar un error' en la esquina superior derecha de su aplicación. Cuando un usuario presiona el botón, intente tomar una captura de pantalla, recopile todos los registros disponibles para la sesión, (puede valer la pena), abra el uso compartido directo de la pantalla en la pantalla del usuario, muéstrele el formulario simple y envíe datos automáticamente a su servidor.

- Intenta preguntarle a un usuario lo menos posible si tu aplicación puede obtener datos por sí misma. Resolución de pantalla, versión del sistema operativo, nombre de usuario, inicio de sesión, últimas acciones y registros

- Asigne un ticket a un usuario y bríndele un enlace, para que sepa que tiene el número de error 1234 en www.yoursite.issues / 1234

-Pregunte a un usuario lo que trató de lograr.

Creo que todo esto, o incluso parcialmente, puede ayudarlo a recibir suficientes datos y mostrarle al usuario que puede ayudarlo a mejorar su software.

La forma más fácil es utilizar una herramienta que pueda "comprender" lo que realmente quiere el cliente. Hay muchas herramientas, pero quizás la mejor es Usersnap. Mira esta historia aquí.