Réponse.

L'origine de cette question remonte aux difficultés classiques d'interaction entre le business et l'informatique : l'opinion subjective, les impressions personnelles et les émotions distordent souvent les besoins et les priorités (par exemple, ce qui est "critique" pour l'un peut être peu intéressant pour l'autre).

Problème : l'influence des facteurs subjectifs entraîne des pertes d'objectivité, des conflits et un manque de transparence, ce qui affecte la qualité du système et la satisfaction du client. Les préférences implicites d'un important stakeholder peuvent introduire des souhaits non argumentés dans les exigences.

Solution:

Formaliser le processus de collecte des exigences par le biais de questionnaires, de matrices de priorisation et d'entretiens structurés
Utiliser des méthodologies pour identifier les véritables besoins (5 Pourquoi, analyse de la chaîne de valeur)
Impliquer différents types de stakeholders et documenter tous les points de vue (carte des stakeholders)
Vérifier le résultat par le biais d'accords documentés et de revues de groupe
Appliquer des tests utilisateurs de prototypes pour confronter les attentes à la réalité

Caractéristiques clés :

Utilisation de sessions interfonctionnelles et de cartographie des intérêts
Introduction de critères formalisés pour l'attestation des exigences
Contrôle continu des changements d'attentes des stakeholders (journal des stakeholders)

Questions pièges.

Un seul conseil général de collecte des besoins avec des experts métiers est-il suffisant pour éliminer tous les aspects subjectifs ?

Non. Lors des conseils, certaines opinions se perdent en raison de la domination de participants actifs, et des détails importants restent souvent en dehors du cadre. Une interview individuelle ou en petit groupe est nécessaire, suivie de la compilation des résultats.

Peut-on considérer l'opinion du propriétaire du produit comme la seule source authentique pour toutes les exigences ?

Non. Le Product Owner est une source importante, mais d'autres stakeholders (par exemple, support, comptabilité, sécurité, utilisateurs) peuvent faire ressortir des nuances critiques dont l'ignorance conduit à des erreurs graves.

Faut-il toujours faire confiance à la priorisation des exigences par le business sans vérification supplémentaire de la justification ?

Non. La priorisation est souvent subjective et dépend des objectifs commerciaux actuels. Il est nécessaire de justifier les priorités à l'aide de matrices valeur/risque, ROI, objectifs stratégiques de l'entreprise.

Erreurs courantes et anti-patterns

Suivre aveuglément l'opinion du participant le plus bruyant ou le plus prestigieux
Ignorer l'opinion des "silencieux" stakeholders
Collecte des exigences non formalisée ("au feeling")

Exemple de la vie

Cas négatif : L'analyste a validé les exigences uniquement avec un représentant du business, ignorant complètement les utilisateurs et les techniciens.

Avantages :

Travail rapide
Pratique pour le stakeholder leader

Inconvénients :

Conflits cachés, retours, retravails
Le système n'est pas convivial pour les utilisateurs finaux

Cas positif : L'analyste a travaillé sur la carte des principaux groupes d'influence, a effectué des entretiens avec tous, a noté les divergences, et a préparé un document de priorisation basé sur des critères objectives.