Llevando a tus usuarios a tu rastreador de errores

17

Tengo un rastreador de errores de mantis totalmente configurado para rastrear problemas en las aplicaciones que creo. Cuando un usuario es disciplinado y va directamente a Mantis para escribir un informe de problema, tendrá una respuesta más rápida y todo lo relacionado con el problema será muy fácil de rastrear.

Sin embargo, no todos están interesados en hacerlo. Informan sus problemas por teléfono, correo electrónico, no los informan en absoluto.

¿Cuál sería la mejor manera de empujarlos hacia el uso de un sistema de seguimiento de errores? Claramente, TIENEN que ver algunos beneficios inmediatos para que puedan regresar y buscar más beneficios.

EDITAR:

Estoy hablando de soporte para los productos que vendo como ISV.

issue-tracking

— Daniel Mošmondor
fuente

2

¿Qué pasa con la integración de informes de errores directamente en su producto?

— JoelFan

22

Su rastreador de errores es para su conveniencia, no para sus clientes. Si no puede molestarse en tomar su problema de teléfono o correo electrónico e ingresarlo usted mismo, ¿cómo cree que se sienten?

Debe poder ingresar problemas y asignarlos manualmente a un cliente. Luego, cuando llamen con un problema, pueden decir: "¡Gracias por informarnos sobre eso! Voy a ingresarlo en nuestro sistema de administración de problemas y comenzarán a recibir correos electrónicos (o lo que sea) mientras lo tratamos. futuro, si es fácil para usted, puede ingresar ese tipo de cosas allí mismo. O siéntase libre de llamarme, también está bien ".

Uno de los mejores sistemas de este tipo con los que he trabajado como cliente es el del proveedor de alojamiento que revendo. El correo electrónico a support @ se analiza para un nombre de dominio en la línea de asunto, se asigna a una cuenta de cliente en función de la dirección de origen y se ingresa automáticamente en su sistema de tickets. Bastante hábil.

— Dan Ray
fuente

2

De acuerdo: no esperaría que los clientes utilicen un sistema de seguimiento de errores.

— tcrosley

44

@tcrosley: entonces necesita un mejor sistema de seguimiento de errores. La clave aquí no es si los usuarios tienen que usar el sistema de seguimiento, sino cómo convencerlos de que es mejor (más fácil, más rápido, más probable lograr el resultado deseado) usar el sistema de seguimiento.

— Murph

1

Realmente no puedo estar de acuerdo con esto. Los programadores nunca deberían recibir informes de errores directamente de los usuarios por teléfono, correo electrónico o cualquier otro lugar para el caso. Si los usuarios quieren reportar errores "personalmente", deberían hacerlo a través del personal de soporte. Si se niegan a hacer eso, entonces su única opción debería ser enviar un informe de error real, ya sea directamente a través de la interfaz de usuario o mediante una bandeja de entrada de correo electrónico dedicada que se reenvía al rastreador. Y si usted es un ISV y no tiene personal de soporte, bueno, ese es otro problema completamente.

— Aaronaught

1

Como startup de ISV, realmente no puedo tener personal de soporte. Y no por la razón obvia: ese es el gasto, sino la razón por la que quiero estar lo más cerca posible del usuario para dirigir el producto en la dirección correcta de acuerdo con las necesidades y deseos. El intermediario lo diluiría hasta cierto punto.

— Daniel Mošmondor

Esta respuesta no es del todo cierta. Como se discutió en programmers.stackexchange.com/questions/191961/… , al menos en el contexto del desarrollo de código abierto, un rastreador de errores puede ser bastante beneficioso para los usuarios: actúa como una base de datos de conocimiento de soporte de problemas conocidos y puede proporcionar soluciones alternativas , si existen Le permite al usuario evaluar qué tan rápido se está abordando su problema, ayudándole a decidir si cambia a una solución diferente. También ayuda a los contribuyentes potenciales cómo funciona el equipo y dónde se necesita ayuda.

— naught101

8

Un usuario que se queja es mejor que uno que no lo hace, se da por vencido y llama a su competidor. Por esta razón, haría lo más fácil posible enviar una queja. Les dejaría continuar llamando y / o enviando correos electrónicos y no pedirles que presenten errores.

Míralo desde su punto de vista: si no solo tienes que tomarte el tiempo de llamar / escribir un correo electrónico, sino también obligarte a aprender el sistema de seguimiento de errores de alguien, es probable que no te quejes.

Si es necesario, contrate a una persona de servicio al cliente para que los desarrolladores no se vean interrumpidos. Pueden tomar las quejas de los clientes y hacer errores para el equipo de desarrollo.

— Doug T.
fuente

Daniel no menciona si es un desarrollador interno cuyos usuarios son sus compañeros de trabajo (que fue la táctica que tomé en mi respuesta), o si apoya a los clientes que pagan.

— Frank Shearar

Estoy apoyando a los clientes que pagan por mis productos,

— aclararé

3

Me gustaría que el usuario que se queja sea mejor que el que no PERIODA. Si hay algo que no me gusta es el usuario que usa el software de manera defectuosa, no informa nada y acumula dolor.

— Daniel Mošmondor

6

No conozco Mantis específicamente, pero ¿se puede configurar para monitorear una dirección de correo electrónico y generar automáticamente informes a partir de ellos? Conozco otros sistemas (como JIRA, por ejemplo, can).

¡Entonces el problema es conseguir que usen la dirección de correo electrónico correcta!

— ChrisF
fuente

1

+1: el correo electrónico es la única forma en que quiero que mis clientes interactúen con mi rastreador de errores. La interfaz de usuario Mantis está lejos de ser fácil de usar, pero incluso con una solución más elegante, los clientes sentirán que están haciendo su trabajo por usted.

— grossvogel

El mismo sistema en mi casa, usando FogBugz.

— FinnNk

1

"Informe sobre esto en el rastreador de errores en http: // your / url / . No puedo hacer un seguimiento de los errores si no los informa allí".

Tal vez sea posible que escriba un complemento para su cliente de correo para convertir un correo electrónico en un informe de error, o utilizar un buzón dedicado - bugs @ foo - para tomar informes de errores. (Pero esto último, por supuesto, requiere entrenar a sus usuarios ...)

— Frank Shearar
fuente

1

Hay un complemento para mantis para recopilar informes de errores del correo electrónico.

— Daniel Mošmondor

1

+ 1 ... porque hablar por teléfono es una distracción, improductivo y no oficial. Tampoco deja rastro sobre quién dijo qué y por qué. Más tarde, cuando la gente pregunta por qué hiciste algo, debes explicarte a ti mismo en lugar de señalarles que emitan #xxxxxx. El teléfono debe estar prohibido. Si sus usuarios no saben cómo usar su rastreador de errores, puede educarlos.

— Dr. Hannibal Lecter

1

Internamente tenemos una plantilla de sitio para aplicaciones web que incluye un enlace de comentarios en la esquina. Este enlace de comentarios proporciona al usuario un cuadro de diálogo de jQuery UI que le solicita una descripción del error, la nueva función u otra que encontraron y también captura algunos detalles sobre la página y el tiempo desde el que informa. Todo esto se introduce directamente en JIRA detrás de escena y el usuario puede obtener actualizaciones sobre el estado del problema.

En general, la mejor manera de hacer las cosas es hacerlo lo más simple posible para los usuarios, si hay un enlace de comentarios en un menú que maneja el envío de la información a donde necesita ir, es mucho más probable que lo usen.

— rjzii
fuente

1

Bueno, si quieres usar un controlador de excepciones global, entonces tienes muchas opciones. Para Delphi usamos MadExcept, pero también hemos usado Eureka Log, que enviará (con el permiso del usuario) un correo electrónico o subirá a través de HTTP un informe de error.

Podría tener un botón en su aplicación que solo arroje una excepción y lance este material de seguimiento de errores. MadExcept es bastante bueno porque toma una captura de pantalla de la aplicación y la carga junto con el error, de esa manera, incluso si el usuario no puede explicar adecuadamente lo que estaban haciendo, puede tener un buen anhelo.

Algo más en lo que pensar es en la codificación para que sea obvio de dónde provienen los errores. Si tiene usuarios beta, tal vez incluya información de depuración con su aplicación para que pueda obtener datos adicionales de ellos cuando ocurran fallas.

Nada de esto ayuda a los errores de implementación (es decir, el botón está en el lugar equivocado), aunque espero que no tenga ninguno de esos.

— Peter Turner
fuente

Por supuesto que tengo un controlador de excepciones de correo electrónico, pero ese es realmente el último recurso. Más cosas que me gustaría capturar provienen de los deseos del usuario de nuevas funciones y mejoras en el sistema.

— Daniel Mošmondor

Bien, tengo una línea de base entonces. ¡Entonces comenzaría por no llamarlo "Rastreador de errores" si desea un foro más de voz de usuario! Si su rastreador de errores actual captura capturas de pantalla, tal vez podría abrir MS paint y dejar que le sugieran mejoras antes de enviar el mensaje.

— Peter Turner

1

Obtuvimos el mayor aumento en la captación al configurar un servicio para recoger el correo electrónico de una dirección y registrarlo automáticamente como un problema. El buen efecto secundario de este sistema es que también puede agregar fácilmente conversaciones a un problema al incluir una sintaxis especial en el tema (por ejemplo, TeamITNo: 12345). Además, si envía toda su comunicación por correo electrónico a través de este sistema, y presionan responder, obtendrá la respuesta nuevamente en el rastreador de errores, con el problema actualizado.

Esto tuvo el mayor efecto positivo, ya que utiliza tecnología con la que los usuarios se sienten cómodos, y también significa que obtiene todos sus problemas en un solo lugar.

— Tom Morgan
fuente