¿Cómo maneja el seguimiento de errores de manera amigable para los programadores y el personal no técnico? [cerrado]

En realidad estamos usando Mantis para nuestros proyectos. O debería decir "tratamos de usar". El problema con todos los rastreadores de errores que conozco es que están hechos por programadores, para programadores. Entonces el diseño es inexistente o totalmente absurdo.

Por supuesto, como programador, puedo usar mantis sin problemas, pero cuán útil es un rastreador de errores cuando todas las personas involucradas ** en un proyecto los encuentran tan mal diseñados y tan difíciles de usar que prefieren hacer documentos de Google con una lista de viñetas de los errores que encontraron o sugerencia que podrían tener.

Estoy a punto de instalar un foro, me parece una solución "intermedia" entre un rastreador de errores y una lista simple de viñetas. Al menos un foro permite monitorear y centralizar una discusión sobre una sugerencia.

En caso de que mi preocupación no sea clara, mi pregunta se puede resumir en:

¿Cómo maneja su informe de errores y sugerencias para el usuario no técnico?

** Por involucrado, NO me refiero al cliente real o al usuario final. Estoy pensando en nuestro integrador, gerentes de proyecto y aquellos que están involucrados con el control de calidad.

Cambiamos de Mantis a FogBugz (y Kiln) a principios de este año, pero lo único que no cambiamos fue que no permitimos que los "usuarios" tengan acceso al rastreador de errores. Algunos de los otros jefes de departamento tienen acceso de solo lectura, pero honestamente son gerentes y generalmente lo olvidan en un par de semanas. Todos los usuarios de nuestro software tratan con un solo tipo de solución de problemas que determina si se trata de un problema de configuración, un error del usuario o un error de software. Esta persona luego actúa como el guardián para ingresar los problemas reales en FogBugz. Esto evita que nuestro sistema esté abarrotado de problemas que no son realmente relevantes.

Entonces, para responder a su pregunta real ... no es realmente un problema para nosotros que el software de seguimiento de errores sea "por programadores", "para programadores" porque solo los "programadores" lo utilizan. Todos los demás tratan directamente con un humano.

(Tenga en cuenta que nuestro producto no es retráctil y todos nuestros usuarios son empleados directos o están trabajando con un empleado en el departamento de servicio).

Usamos Redmine para este tipo de cosas. El truco clave es que la mayoría de los usuarios nunca ven Redmine: simplemente envían un correo electrónico a support@example.com. Usando algunos trucos más avanzados, principalmente BCC en nuestra cuenta de redmine e incluyendo el número de problema, podemos mantener las actualizaciones en redmine. Para las personas más avanzadas, simplemente les dejamos usar Redmine directamente dado que es un poco más moderno y fácil de usar que MANTIS.

Actualmente estamos usando MKS. Para los no programadores, he configurado algunos informes y un panel con resúmenes que les interesan. Esto significa que tengo que hacer la configuración inicial, pero pueden monitorear el progreso de los defectos y el resumen general. datos por su cuenta, una vez que les muestro cómo acceder a los informes y paneles. También necesitaban algo de entrenamiento para modificar sus boletos, pero siempre habrá algo de entrenamiento. Afortunadamente, fue proporcional a las características involucradas.

Segundo Redmine, y personalmente uso The Bug Genie (sí, nombre cursi, pero bien diseñado; si estás en un entorno PHP y / o no puedes ejecutar Ruby por cualquier razón) para el seguimiento de problemas que es amigable para usuarios tecnológicos.

Además de eso, una de las claves es que los usuarios finales nunca necesitan ver más problemas que los que ingresan, de forma predeterminada (opcionalmente, podría tener la capacidad de búsqueda para evitar tickets duplicados, pero eso depende de sus necesidades y configuración). Ver todos los problemas solo desordenará la interfaz y confundirá al usuario final. Los usuarios en general solo deberían ver lo que necesitan ver, por lo que los gerentes de proyecto solo verían los problemas de los proyectos que controlan, por ejemplo. Como otros han mencionado, para los usuarios finales, cuanto más simple sea el envío del ticket, mejor. Puntos de bonificación si puede enviar un ticket que ni siquiera requiere la IU del rastreador (ya sea por correo electrónico o mediante un formulario simple que solo tiene los campos requeridos para enviar el ticket).

Usamos "las características de Application Lifecycle Management de Visual Studio", anteriormente conocidas como Team Systems. Una gran ventaja para nosotros es que puede exportar un resultado de consulta (como "todos los requisitos" o "todos los errores con un pri 2 o inferior que no estarán en la próxima versión") en una hoja de cálculo o documento de proyecto. Los gerentes de proyecto, los representantes de usuarios finales, las partes interesadas, etc. pueden editar estos archivos (cambiando la prioridad, actualizando las descripciones, asignando a otra persona, lo que sea) y luego, cuando el archivo vuelve a una máquina que está conectada a TFS, puede presionar Publicar y los cambios vuelven al repositorio. Los programadores trabajan con elementos de trabajo directamente desde Visual Studio, pero los no programadores nunca se acercan a VS. También hay un sitio sharepoint para cada proyecto TFS, por lo que no debe

Tal vez no sea una opción si no eres una tienda de VS, pero vale la pena pensar si lo eres.

Si está hablando del personal de QA / PM, entonces debe evaluar varias herramientas de seguimiento de código abierto y cerrado. Los que tienen la capacidad de establecer compilaciones, etc. son buenos, de modo que las personas de QA / PM pueden colocar tickets en una compilación específica y cuando solucionan un problema pueden saber en qué compilación probarlo.

La mayoría de las herramientas de propiedad que he usado están más ajustadas para los no programadores que para los programadores. StarTeam fue uno que funcionó bastante bien para mí, pero no sé si todavía existe. Puede personalizar campos y demás si lo desea. Solo asegúrate de que no se excedan con eso.

Si está hablando de usuarios finales, entonces debe mirar el software de la mesa de ayuda y luego hacer que el personal de su mesa de ayuda escale a la herramienta de error según sea necesario.