Associer vos utilisateurs à votre bugtracker

J'ai un tracker de bogue mantis entièrement configuré pour suivre les problèmes dans les applications que je crée. Lorsqu'un utilisateur est discipliné et va directement à mantis pour rédiger un rapport de problème, il / elle aura la réponse la plus rapide et tout ce qui concerne le problème sera très facile à suivre.

Cependant, tout le monde ne souhaite pas le faire. Ils signalent leurs problèmes par téléphone, e-mail, ne les signalent pas du tout.

Quelle serait la meilleure façon de les pousser à utiliser un système de bugtracker? De toute évidence, ils DOIVENT voir des avantages immédiats pour pouvoir revenir et chercher d'autres avantages.

ÉDITER:

Je parle de support pour les produits que je vends en tant qu'ISV.

Votre traqueur de bogues est pour votre commodité, pas celui de vos clients. Si vous ne pouvez pas prendre la peine de prendre leur problème de téléphone ou de courrier électronique et de le saisir vous-même, comment pensez-vous qu'ils se sentent?

Vous devez pouvoir saisir les problèmes et les affecter manuellement à un client. Ensuite, quand ils appellent avec un problème, vous pouvez dire: «Merci d'avoir signalé cela! Je vais le saisir dans notre système de gestion des problèmes, et vous commencerez à recevoir des e-mails (ou autre) pendant que nous traitons. l'avenir, si c'est facile pour vous, vous pouvez entrer ce genre de chose ici. Ou n'hésitez pas à m'appeler, c'est bien aussi. "

L'un des meilleurs systèmes avec lesquels j'ai travaillé en tant que client est celui du fournisseur d'hébergement que je revend. L'e-mail à support @ est analysé pour un nom de domaine dans la ligne d'objet, attribué à un compte client en fonction de l'adresse de l'expéditeur et entré automatiquement dans son système de ticket. Assez lisse.

Un utilisateur qui se plaint est meilleur que celui qui ne le fait pas, abandonne et appelle votre concurrent. Pour cette raison, je faciliterais le plus possible l'envoi d'une plainte. Je les laisserais continuer à appeler et / ou envoyer des e-mails et ne pas leur demander de signaler des bugs.

Regardez-le de leur point de vue - si vous ne deviez pas seulement prendre le temps d'appeler / écrire un e-mail, mais aussi être forcé d'apprendre le système de suivi des bugs de quelqu'un - il y a de fortes chances que vous n'allez pas vous plaindre.

Si besoin est, embauchez un technicien pour que les développeurs ne soient pas interrompus. Ils peuvent prendre les plaintes des clients et faire des bugs pour l'équipe de développement.

Je ne connais pas Mantis en particulier, mais peut-il être configuré pour surveiller une adresse e-mail et en générer automatiquement des rapports? Je connais d'autres systèmes (comme JIRA par exemple).

Le problème devient alors de les amener à utiliser la bonne adresse e-mail!

"Veuillez signaler cela sur le suivi des bogues à http: // votre / url / . Je ne peux pas garder une trace des bogues si vous ne les signalez pas là-bas."

Il est peut-être possible pour vous d'écrire un plugin pour votre client de messagerie pour transformer un e-mail en rapport de bogue, ou d'utiliser une boîte aux lettres dédiée - bugs @ foo - pour prendre des rapports de bogue. (Mais ce dernier nécessite bien sûr de former vos utilisateurs ...)

En interne, nous avons un modèle de site pour les applications Web qui comprend un lien de rétroaction dans le coin. Ce lien de rétroaction fournit à l'utilisateur une boîte de dialogue d'interface utilisateur jQuery qui lui demande une description du bogue, de la nouvelle fonctionnalité ou de tout autre problème rencontré et capture également des détails sur la page et l'heure à laquelle il fait rapport. Tout cela est directement poussé dans JIRA dans les coulisses et l'utilisateur peut obtenir des mises à jour avec l'état du problème.

En quelque sorte, la meilleure façon de faire est généralement de la rendre aussi simple que possible pour les utilisateurs.S'il existe un lien de rétroaction dans un menu qui gère l'envoi des informations là où elles doivent aller, ils sont beaucoup plus susceptibles de les utiliser.

Eh bien, si vous souhaitez utiliser un gestionnaire d'exceptions global, vous disposez de nombreuses options. Pour Delphi, nous utilisons MadExcept, mais nous avons également utilisé Eureka Log, qui tous les deux (avec l'autorisation de l'utilisateur) enverront par e-mail ou téléchargeront via HTTP, un rapport de bogue pour vous.

Vous pourriez avoir un bouton dans votre application qui lève juste une exception et lance ce truc de suivi des bogues. MadExcept est assez cool car il prend une capture d'écran de l'application et la télécharge avec le bogue, de cette façon, même si l'utilisateur ne peut pas expliquer correctement ce qu'il faisait, vous pouvez avoir un assez bon penchant.

Quelque chose d'autre à penser est le codage pour rendre évident d'où viennent les bogues. Si vous avez des utilisateurs bêta, incluez peut-être des informations de débogage avec leur application afin que vous puissiez obtenir des données supplémentaires d'eux lorsque des plantages se produisent.

Rien de tout cela n'aide pour les bogues d'implémentation (c'est-à-dire que le bouton est au mauvais endroit), alors j'espère que vous n'en avez aucun.

Nous avons obtenu la plus forte augmentation de l'utilisation en configurant un service pour récupérer les e-mails à partir d'une adresse et les enregistrer automatiquement en tant que problème. L'effet secondaire agréable de ce système est que vous pouvez également facilement ajouter des conversations à un problème en incluant une syntaxe spéciale dans le sujet (par exemple, TeamITNo: 12345). De plus, si vous envoyez toutes vos communications par e-mail via ce système, et qu'ils ont répondu, vous obtiendrez la réponse directement dans le suivi des bogues, avec le problème mis à jour.

Cela a eu le plus grand effet positif, car il utilise une technologie avec laquelle les utilisateurs sont à l'aise, et signifie également que vous obtenez tous vos problèmes en un seul endroit.