Lorsqu’une nouvelle fonctionnalité est demandée pendant un projet logiciel, précisez d’abord le problème à résoudre et les effets sur les travaux existants. Au lieu de développer immédiatement ou de refuser, rassemblez les informations nécessaires à la décision. Vous pourrez ainsi examiner le nouveau besoin sans perdre de vue les engagements précédents.

Pourquoi de nouvelles idées peuvent-elles brouiller le plan ?

En découvrant les premiers écrans, les utilisateurs peuvent identifier des besoins auxquels ils n’avaient pas pensé. Cela ne signifie pas que l’idée initiale était mauvaise. Mais de petits ajouts à chaque échange, sans enregistrement distinct, peuvent créer des attentes différentes sur la livraison.

Une personne imagine une case supplémentaire, une autre attend aussi des filtres et des rapports. Le problème n’est pas l’apparition d’idées, mais leur interprétation différente. Si les limites initiales restent floues, réexaminez les éléments nécessaires à la première version.

Décrivez la difficulté plutôt que la fonctionnalité

Au lieu de « ajoutons un bouton », écrivez quelle tâche ne peut pas être accomplie. Indiquez l’origine de la demande, la situation concernée et la difficulté de la méthode actuelle. Il n’est pas nécessaire de choisir tout de suite la solution technique.

Si les dossiers en attente sont difficiles à retrouver, un nouvel écran n’est peut-être pas la seule réponse. Un filtre dans la liste, un statut plus clair ou un ordre de travail différent peuvent être étudiés. Ce sont des pistes de discussion, pas des solutions déjà validées ; leur pertinence dépend de l’examen du système.

Ajoutez un exemple d’usage. « Au début de la semaine, je veux voir les tâches sans responsable » est plus concret que « améliorer les rapports ».

Distinguez défaut, besoin d’explication et nouveau travail

Une opération convenue qui échoue n’est pas la même chose qu’un comportement nouveau demandé plus tard. Parfois, le logiciel fonctionne comme prévu, mais la règle métier a été mal expliquée. Relisez ensemble les décisions et le résultat attendu pour identifier la situation.

Ne vous fiez pas seulement au nom de la demande. Une « petite correction » peut nécessiter un nouveau champ ; une « nouvelle fonction » peut être résolue par une explication du comportement existant. Le but n’est pas de décider d’avance si le travail sera payant, mais de décrire le changement de manière commune.

Comparons les possibilités dans une entreprise fictive

Imaginons une entreprise suivant ses demandes de travail dans une liste partagée. La première version prévoit création, affectation et changement de statut. Lors d’un essai, un utilisateur demande une note d’évaluation supplémentaire pour les dossiers clôturés. Cet exemple est entièrement fictif.

Demandez d’abord à quoi servira la note. Rappellera-t-elle au responsable sa prochaine tâche, ou permettra-t-elle à une autre personne de revoir la décision de clôture ? Dans le second cas, il faut aussi préciser les lecteurs et le moment où la clôture sera considérée comme terminée.

L’équipe peut examiner si le champ de description existant suffit. Si un champ séparé est nécessaire, les options incluent l’ajout immédiat, le report à une version suivante ou le remplacement d’une tâche non commencée. Aucun choix ne convient à tous les projets ; il dépend de l’importance quotidienne de la note et des effets sur les autres travaux.

Quelles questions résoudre avant de décider ?

Dans une courte note d’évaluation :

  • Quel besoin ? Décrivez la tâche inachevée et le résultat attendu, pas seulement l’écran.
  • Que se passe-t-il si cela attend ? Le travail est-il bloqué, existe-t-il une solution temporaire ou recherche-t-on surtout du confort ? Soyez concret.
  • Quels éléments changent ? Examinez avec l’équipe les dossiers, les rôles et les étapes concernés.
  • Que vérifier de nouveau ? Choisissez des tâches existantes potentiellement touchées, en plus du nouveau comportement.
  • Quelle décision ? Notez l’action immédiate, le report ou l’information attendue, avec le motif.

Le premier examen ne révèle pas toujours tout. Conservez les inconnues comme questions ouvertes au lieu de deviner. Sans information suffisante sur le délai ou le coût, aucun chiffre définitif n’est nécessaire.

Après accord, gardez des attentes communes

Le demandeur et l’équipe doivent comprendre la décision de la même façon. Intégrez les changements acceptés à la liste actuelle et conservez les demandes reportées. Une discussion ne doit pas être confondue avec une autorisation de réalisation.

Définissez à l’avance l’exemple qui vérifiera le résultat. La distinction entre résultat attendu et observé dans le guide des tests d’acceptation peut aider.

Évaluer les fonctions ne vise pas à réduire les idées. Il s’agit de comprendre pourquoi un besoin devient prioritaire et comment les autres tâches sont affectées. La décision repose alors sur un besoin examiné et un choix consigné plutôt que sur la dernière demande entendue.