Comment obtenir les commentaires de l'utilisateur final (client) sur des projets de développement personnalisés

Question

Mon entreprise est un atelier de développement personnalisé pour un certain nombre de projets, certains plus grands et d'autres plus petits. Actuellement, nous traitons toutes les communications de nos clients par courrier électronique. Nous envoyons donc un document de conception par courrier électronique. Ils le balisent et le renvoient. Ensuite, nous déployons une version bêta de leur produit et ils nous envoient des bugs, de nouvelles fonctionnalités, etc., etc. Et ainsi de suite ....

Alors que je travaillais sur la mise en place d'un nouveau système de suivi des bogues (il semble que ce soit désormais Mantis), je me suis demandé comment nous pourrions mieux permettre à nos clients une interface avec notre processus de développement qui fournirait un meilleur suivi des fonctionnalités. requêtes et les bogues soumis par le client, ainsi que de communiquer nos réponses au client.

Si quelqu'un est au courant d'un système de suivi de bogues qui le fait exceptionnellement bien, cela m'intéresserait. Sinon, je cherche simplement des directives générales ou de bonnes pratiques commerciales qui ont permis à vos entreprises d’interfacer efficacement avec leurs clients.

MISE À JOUR: Ma société utilise une pile LAMPP et, en tant que petit magasin doté d'un budget limité, nous avons tendance à nous en tenir aux outils open-source et gratuits.

Est-ce que la plupart des gens utilisent Team Foundation Server pour gérer cela ou envoient des courriels?

Answer 1

Bien que je ne connaisse aucun outil spécifique (du moins aucun logiciel open source), je vous suggère de configurer un système couvrant l'ensemble de votre processus de collecte et de mise en œuvre des exigences. Les exigences pourraient être suivies dans le système, qui contiendrait également les documents de conception (qui pourraient être "extraits de" et "engagés dans" le système). De cette manière, vous pourrez résoudre le problème des révisions multiples des documents de conception. De plus, les documents de conception et les exigences pourraient être suivis facilement. Si ce système était lié à votre système de gestion de code source, vous simplifieriez également le suivi de votre processus de développement et de vos exigences.

Answer 2

Je pense que l’essentiel est d’avoir un système de suivi dédié pour les bogues / requêtes et d’établir un processus défini pour la communication. Avec cela au minimum, vous commencerez à recevoir des commentaires cohérents. À partir de là, vous pouvez le modifier pour répondre à vos besoins spécifiques.

En passant, plutôt que d'utiliser simplement le courrier électronique pour votre communication, je vous recommande fortement de vous rendre sur un site comme BaseCamp pour un outil de gestion de projet. Je trouve que cela aide beaucoup à garder les messages, la documentation et les délais communiqués au client.

Answer 3

Si vous utilisez Team Foundation Server, je vous recommande d'installer Accès Web TeamPlain . Ils vous permettent d’exposer une interface Web à votre projet TFS. Il ne reste plus qu’à donner des droits à votre client, un nom d’utilisateur et un mot de passe.

Sinon, il existe des outils payants tels que FogBugz . Bien entendu, le principal est de devoir boguer des outils de reporting directement liés à votre contrôle de code source afin que les développeurs puissent facilement les réparer.

Answer 4

Une autre possibilité consiste à utiliser deux produits de concert. Voici notre configuration actuelle avec une équipe de 12 personnes:

osTicket pour les demandes entrantes des clients

• Permet aux membres du support technique de gérer les problèmes et de vérifier les bogues
• Le statut peut être vérifié avec uniquement une adresse e-mail et un ID de ticket
• Généralement, les utilisateurs ne soumettent pas suffisamment de rapports de bogues détaillés. C’est donc une bonne première étape

redmine pour les tickets de développement

• Ticket créé par le contrôle de la qualité ou un développeur si le problème est un vrai bogue
• Fournit une gestion de projet et de publication suffisamment solide
• constitue une solide avancée par rapport au trac et au mantis (et fournit migration outils)