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

16

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.

ccellar
fuente
24
No lo hace, diseña su software para enviarle registros / mensajes de error.
Mahmoud Hossam
8
Esto, desafortunadamente, no siempre es posible sobre todo si estás de software que no se desarrolló de apoyo, pero que se compró en.
temptar
1
@Mahmoud: Ese es un buen consejo, pero en realidad solo es relevante si está en la etapa de diseño de una nueva aplicación, o si tiene el lujo (tiempo y presupuesto) de incorporar una función en una aplicación existente.
FrustratedWithFormsDesigner
1
¿"más fácil para ambos lados"? ¿Ambos lados? Ya están haciendo lo que es más fácil para ellos.
S.Lott
1
No puede controlar la aplicación, pero ¿cree que puede controlar a los usuarios? Estás en el campo equivocado.
JeffO

Respuestas:

5

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.

perdian
fuente
2
Castíguelos por malos informes: responda con una lista de preguntas que deben responder y dígales que vuelvan a enviar su solicitud de soporte cuando tengan la información. Detrás de la cola!
Kirk Broadhurst el
A veces es suficiente tener una captura de pantalla anotada adecuada del error / error junto con la metainformación. Usersnap es un pequeño botón que puede agregar a su proyecto web para permitir la notificación fácil de errores.
Gregor
17

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.

Fritas
fuente
1
+1: Cuando se enfrentan a una plantilla, las personas generalmente intentan completarla. Y si no lo hacen, no les tomará mucho tiempo simplemente pedirles que completen el informe. Además, guiándolos cuidadosamente, puede evitar el típico "¡No funciona!"
Matthieu M.
55
Implementamos este patrón en el trabajo. El 75% de todos los informes de errores tienen una variación de "esperaba que funcionara" en el campo "esperado" y "No funcionó" en el campo "real". Suspiro.
Charles
1
@Charles: luego cierre el informe con un comentario de "Resuelto: sin acción".
Donal Fellows
@Donal Fellows: en cambio, lo rechazaría como "Duplicar".
Mouviciel
7

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.

Rachel
fuente
1
Nunca ha tenido el caso en el que obtiene una captura de pantalla de un cuadro de diálogo o algo pequeño que el usuario cree que es relevante pero en realidad no lo es. Me sale esto todo el tiempo ...
sevenseacat
De hecho, lo obtengo de vez en cuando, pero cuando lo hago, generalmente les pido una captura de pantalla del error real. Después de un tiempo se acostumbran a enviarme el error real
Rachel
5

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).

Ingo
fuente
5

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.

Alba
fuente
3

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.

FrustratedWithFormsDesigner
fuente
2

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.

l0b0
fuente
2

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.

Carra
fuente
1

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.

Brian
fuente
1

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.

ZeusTheTrueDios
fuente
-2

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í.

Bogo
fuente
1
Esto es poco más que una respuesta de solo enlace. Su respuesta sería más fuerte y más valiosa si explicara por qué la herramienta responde a la pregunta del OP.