Comment gérez-vous le suivi des bogues d'une manière conviviale pour les programmeurs et le personnel non technique? [fermé]

Nous utilisons actuellement Mantis pour nos projets. Ou devrais-je dire "nous essayons d'utiliser". Le problème avec tous les trackers de bugs que je connais est qu'ils sont faits par des programmeurs, pour des programmeurs. Le design est donc inexistant ou totalement absurde.

Bien sûr, en tant que programmeur, je peux utiliser mantis sans problème, mais à quel point un bug tracker est-il utile lorsque toutes les personnes impliquées ** dans un projet les trouvent si mal conçues et si difficiles à utiliser qu'elles préfèrent créer un document Google avec une liste à puces des bogues qu'ils ont trouvés ou des suggestions qu'ils pourraient avoir.

Je suis sur le point d'installer un forum, cela me semble être une solution "au milieu" entre un tracker de bug et une simple liste à puces. Au moins un forum permet de suivre et de centraliser une discussion sur une suggestion.

Si ma préoccupation n'est pas claire, ma question peut être résumée comme suit:

Comment gérez-vous votre rapport de bug et de suggestion envers l'utilisateur non technique?

** Par impliqué, je ne veux pas dire le client réel ou l'utilisateur final. Je pense à notre intégrateur, aux chefs de projet et à ceux qui sont impliqués dans l'AQ.

Nous sommes passés de Mantis à FogBugz (et Kiln) plus tôt cette année, mais la seule chose que nous n'avons pas modifiée est que nous ne permettons pas aux "utilisateurs" d'avoir accès au traqueur de bogues. Certains des autres chefs de département ont un accès en lecture seule, mais honnêtement, ils sont des gestionnaires et ils l'oublient généralement en quelques semaines. Les utilisateurs de notre logiciel traitent tous avec un seul gars de dépannage qui détermine s'il s'agit d'un problème de configuration, d'une erreur utilisateur ou d'un bug logiciel. Cette personne agit alors en tant que gardien pour saisir les vrais problèmes dans FogBugz. Cela empêche notre système d'être encombré de problèmes qui ne sont pas vraiment pertinents.

Donc, pour répondre à votre vraie question ... ce n'est pas vraiment un problème pour nous que le logiciel de suivi des bogues soit "par les programmeurs", "pour les programmeurs" car seuls les "programmeurs" l'utilisent. Tous les autres traitent directement avec un humain.

(Remarque: notre produit n'est pas de type rétractable et tous nos utilisateurs sont des employés directs ou travaillent avec un employé du service après-vente.)

Nous utilisons redmine pour ce genre de chose. L'astuce clé est que la plupart des utilisateurs ne voient jamais Redmine - ils envoient simplement un e-mail à support@example.com. En utilisant quelques astuces plus avancées - principalement BCCing notre compte redmine et en incluant le problème # - nous pouvons garder les mises à jour dans redmine. Pour les personnes plus avancées, nous les laissons utiliser directement Redmine, car il est un peu plus moderne et convivial que MANTIS ne l'a jamais été.

Actuellement, nous utilisons MKS. Pour les non-programmeurs, j'ai mis en place des rapports et un tableau de bord avec des résumés qui les intéressent. Cela signifie que je dois faire la configuration initiale, mais ils sont capables de suivre la progression des défauts et un résumé global données seules, une fois que je leur ai montré comment accéder aux rapports et aux tableaux de bord. Ils ont également besoin d' une formation pour modifier leurs billets, mais il y aura toujours être un peu les frais généraux de formation. Heureusement, il était proportionné aux caractéristiques impliquées.

J'appuie Redmine et utilise personnellement The Bug Genie (oui, nom ringard, mais bien conçu; si vous êtes dans un environnement PHP et / ou ne pouvez pas exécuter Ruby pour une raison quelconque) pour le suivi des problèmes qui est convivial pour les non utilisateurs de technologie.

En plus de cela, l'une des clés est que les utilisateurs finaux n'ont jamais besoin de voir plus de problèmes que ceux qu'ils posent, par défaut (vous pouvez éventuellement avoir la capacité de recherche pour éviter les tickets en double, mais cela dépend de vos besoins et de votre configuration). Voir tous les problèmes ne fera qu'encombrer l'interface et confondra l'utilisateur final. Les utilisateurs en général ne devraient voir que ce dont ils ont besoin, donc les chefs de projet ne verront que les problèmes des projets qu'ils contrôlent, par exemple. Comme d'autres l'ont mentionné, pour les utilisateurs finaux, plus vous pouvez simplifier la soumission des billets, mieux c'est. Points bonus si vous pouvez avoir une soumission de ticket qui ne nécessite même pas l'interface utilisateur du tracker (soit par e-mail, soit via un simple formulaire qui ne contient que les champs requis pour soumettre le ticket).

Nous utilisons «les fonctionnalités de gestion du cycle de vie des applications de Visual Studio», anciennement appelées Team Systems. Un grand avantage pour nous est que vous pouvez exporter un résultat de requête (comme "toutes les exigences" ou "tous les bogues avec un pri 2 ou inférieur qui ne seront pas dans la prochaine version") dans une feuille de calcul ou un document de projet. Les chefs de projet, les représentants des utilisateurs finaux, les parties prenantes, etc. peuvent modifier ces fichiers - changer la priorité, mettre à jour les descriptions, attribuer à quelqu'un d'autre, peu importe - et puis, lorsque le fichier revient sur une machine connectée à TFS, vous pouvez appuyer sur Publier et les modifications retournent dans le référentiel. Les programmeurs travaillent avec des éléments de travail directement à partir de Visual Studio, mais les non-programmeurs ne s'approchent jamais de VS. Il y a aussi un site sharepoint pour chaque projet TFS, donc vous ne

Peut-être pas une option si vous n'êtes pas un magasin VS, mais cela vaut la peine de réfléchir si vous l'êtes.

Si vous parlez de personnel QA / PM, vous devez évaluer divers outils de suivi de source ouverte et fermée. Ceux qui ont la possibilité de définir des builds, etc. sont bons, de sorte que les personnes QA / PM puissent mettre des tickets contre une build spécifique et quand vous résolvez un problème, ils peuvent savoir dans quelle build le tester.

La plupart des outils de propriété que j'ai utilisés sont en fait plus adaptés aux non-programmeurs qu'aux programmeurs. StarTeam était celui qui fonctionnait assez bien pour moi, mais je ne sais pas s'il est toujours là. Vous pouvez personnaliser les champs et autres si vous le souhaitez. Assurez-vous simplement qu'ils ne vont pas trop loin avec ça.

Si vous parlez d'utilisateurs finaux, vous devez consulter le logiciel d'assistance et demander au personnel du service d'assistance de passer à l'outil de correction des bogues selon les besoins.