Triez les demandes d’évolution de votre logiciel métier : distinguez les incidents, documentez les besoins et priorisez les changements après lancement.
Après le lancement, les demandes arrivent par email, en réunion et dans les conversations de l’équipe. Un utilisateur veut un filtre, un responsable souhaite un tableau de bord et un autre signale qu’un dossier disparaît de sa liste. Sans suivi commun, ces sujets se mélangent et les développeurs travaillent sur la dernière demande reçue.
Une organisation légère suffit pour rendre les choix visibles. Elle doit permettre de retrouver le problème d’origine, la décision prise et le résultat attendu. Le nombre de demandes conservées compte moins que la capacité à décider lesquelles méritent du travail.
Prévoir un point d’entrée commun
Utilisez un formulaire ou un espace de suivi accessible aux personnes concernées. Les demandes reçues ailleurs peuvent y être ajoutées par le support ou le responsable produit. L’utilisateur doit recevoir une référence et savoir où consulter l’avancement.
Demandez une description courte du problème, le contexte et un exemple. Dans un cas fictif, « ajouter un export Excel » peut correspondre au besoin de transmettre les commandes non affectées à un responsable chaque matin. Cette explication permet d’examiner plusieurs réponses possibles avant de construire l’export demandé.
Gardez les pièces jointes utiles avec des droits adaptés. Évitez de recopier des dossiers clients complets lorsqu’un exemple fictif ou une capture expurgée permet de comprendre le besoin. Le suivi des demandes devient lui-même un endroit où des informations sensibles peuvent s’accumuler.
Séparer l’incident de l’évolution
Un comportement qui ne respecte plus une règle validée demande d’abord une analyse d’anomalie. Une interruption du service ou une exposition de données doit suivre la procédure d’incident prévue, sans attendre la prochaine réunion de priorisation des fonctionnalités.
Une évolution modifie un comportement attendu ou ajoute un usage. Une difficulté peut aussi venir d’un manque de formation ou d’une configuration. Classez provisoirement le sujet, puis confirmez cette qualification après examen. L’étiquette initiale ne doit pas empêcher de corriger une mauvaise analyse.
Le dossier de transfert et de maintenance doit préciser les interlocuteurs et les engagements associés. L’existence d’un contrat de maintenance ne signifie pas que toute demande de nouvelle fonction entre dans son forfait.
Regrouper les demandes qui décrivent le même problème
Plusieurs utilisateurs peuvent demander des solutions différentes à une même difficulté. L’un demande un email, l’autre un badge et le troisième un rapport, alors qu’ils cherchent tous à repérer les dossiers en attente depuis trop longtemps.
Rattachez les demandes à un besoin commun en conservant leurs exemples. Notez combien de personnes sont concernées, mais vérifiez aussi la fréquence de la situation. Un problème signalé par une seule personne peut affecter une opération rare et importante.
Lorsqu’un besoin reste vague, demandez un cas récent et observez le travail effectué. Cette étape peut révéler une règle manquante ou un écran mal compris. Elle évite d’engager une modification sur la seule base du nom proposé pour la fonctionnalité.
Comparer l’effet attendu et l’effort
Atlassian présente plusieurs méthodes de priorisation qui confrontent les possibilités aux contraintes du produit. Pour une PME, une comparaison simple peut suffire si les hypothèses sont visibles et révisables.
| Critère proposé | Question à documenter |
|---|---|
| Fréquence | Combien de fois la situation apparaît-elle ? |
| Effet métier | Quel temps, quelle erreur ou quel blocage souhaite-t-on réduire ? |
| Preuves | Dispose-t-on de dossiers observés ou seulement d’une intuition ? |
| Effort | Quels composants et quelles équipes sont concernés ? |
| Dépendances | Faut-il attendre une donnée, un fournisseur ou une autre évolution ? |
| Réversibilité | Comment retirer ou désactiver le changement si nécessaire ? |
Évitez les scores trop précis lorsque les estimations restent fragiles. Un classement obtenu par multiplication de chiffres incertains conserve cette incertitude. Accompagnez chaque estimation de son origine et des vérifications qui pourraient la modifier.
Dans notre exemple fictif, un filtre sur les dossiers en attente peut être moins coûteux qu’un nouveau reporting complet. Il faut néanmoins vérifier qu’il répond au moment où le responsable prend sa décision. Une fonction facile à construire peut rester peu utile.
Décider à une fréquence adaptée à l’équipe
Prévoyez une revue régulière avec une personne habilitée à arbitrer le budget et le périmètre. La fréquence dépend du volume des demandes et de la capacité de livraison. Les incidents urgents conservent leur circuit propre.
Chaque sujet reçoit une décision compréhensible : à étudier, retenu, reporté ou refusé avec une raison. Un besoin accepté pour étude n’a pas encore de date de livraison. Évitez d’annoncer une échéance avant de connaître les dépendances et les moyens nécessaires.
Limitez les travaux commencés simultanément. Si une demande urgente remplace un élément prévu, indiquez lequel est décalé et pourquoi. Les utilisateurs peuvent alors comprendre l’effet concret du changement de priorité sur leurs propres demandes.
Préparer une évolution livrable
Avant développement, décrivez le comportement attendu et les cas qui permettront de l’accepter. Reliez la tâche aux demandes d’origine pour conserver le contexte. Précisez aussi les droits d’accès et les effets sur les données existantes.
Une petite évolution peut exiger une migration ou une modification d’intégration. Demandez à l’équipe technique de signaler ces dépendances avant de confirmer le périmètre. Les critères d’acceptation doivent couvrir les conditions qui ont motivé la demande et les erreurs pertinentes pour ce changement.
Vérifier l’usage après livraison
Prévenez les utilisateurs concernés et expliquez comment accéder au nouveau comportement. Demandez-leur de reprendre le cas initial. Si la fonction ne résout pas le problème, conservez cet écart au lieu de fermer la discussion parce que le développement est terminé.
Lorsque cela est pertinent, comparez la fréquence des reprises manuelles ou le temps consacré à l’opération avant et après. Documentez les limites de cette comparaison, notamment les changements de volume ou d’organisation. Archivez ensuite les demandes devenues inutiles avec leur décision afin que la liste active reste consultable.