Evidence-based stakeholder identification: Managing conflict and its impact on requirements prioritisation

Dans le monde complexe de la construction de logiciels, les personnes qui comptent le plus sont souvent les plus difficiles à trouver. Ces individus, appelés parties prenantes (ou stakeholders), sont les clients, les gestionnaires et les utilisateurs dont les besoins façonnent le produit final. Si une équipe manque une personne clé, le logiciel pourrait ne pas parvenir à résoudre les bons problèmes ou ignorer des risques critiques. Pendant des décennies, trouver ces personnes a été une question d'intuition humaine, reposant sur l'expérience des chefs de projet pour deviner qui détenait le plus d'influence. Cependant, à mesure que les projets deviennent plus vastes et plus mondialisés, deviner ne suffit plus. Le défi n'est pas seulement de trouver ces personnes, mais de comprendre comment peser leurs opinions divergentes. Une personne peut affirmer qu'un utilisateur spécifique est vital, tandis qu'une autre insiste sur le fait qu'il est non pertinent. Lorsque ces points de vue subjectifs s'affrontent, les méthodes traditionnelles peinent souvent à trouver une voie claire, laissant les équipes incertaines de savoir qui compte réellement.

Une équipe de chercheurs de l'Université d'Almería a proposé une nouvelle façon de résoudre ce casse-tête, s'éloignant des pressentiments pour se diriger vers une approche mathématique conçue pour gérer le désaccord. Leurs travaux se concentrent sur un concept appelé « saillance », qui est simplement une mesure de la manière dont une personne est perçue comme importante ou influente au sein d'un groupe. Dans leur étude, ils ont traité les opinions de différentes personnes comme des preuves, un peu comme un jury pesant des témoignages. Ils ont utilisé un cadre connu sous le nom de théorie de l'évidence, une méthode initialement développée pour gérer l'incertitude, afin de combiner ces évaluations subjectives en une image unique et claire. Les chercheurs ne cherchaient pas seulement l'accord ; ils ont construit un système spécifiquement conçu pour gérer le conflit. En analysant à quel point les recommandants divergeaient les uns des autres, leur méthode pouvait déterminer quels acteurs étaient véritablement centraux pour le projet et lesquels n'étaient que du bruit périphérique.

Pour tester leur idée, les chercheurs ont appliqué leur méthode à un ensemble de données réelles provenant d'un projet de l'University College London appelé RALIC. Ce projet impliquait la fusion des systèmes d'accès aux bibliothèques et aux centres de fitness, et l'équipe d'origine avait déjà identifié une liste de 18 personnes clés et 28 rôles. Les chercheurs ont pris un réseau de recommandations où des centaines de personnes évaluaient l'influence des autres sur une échelle de zéro à dix. Ils ont injecté ces évaluations dans leur système, qui les a converties en une croyance partagée sur l'importance de chacun. Les résultats ont été frappants. Dans une version du réseau, leur méthode a réduit le vivier initial de parties prenantes potentielles de près de 85 %, ramenant la liste à seulement 15 ou 19 individus clés selon la règle mathématique spécifique utilisée. Dans une autre version, la réduction était d'environ 70 %. Le système a réussi à filtrer le bruit, identifiant un groupe central qui comprenait des personnes que l'équipe d'origine avait omises, tout en confirmant l'importance de celles qu'elle soupçonnait déjà.

L'étude a révélé une relation fascinante entre conflit et clarté. Les chercheurs ont constaté que lorsque les personnes donnant des recommandations divergeaient moins, le système pouvait s'accorder sur un groupe de parties prenantes clés plus petit et plus précis. Inversement, lorsque le réseau était rempli de conflits élevés, le système devenait plus prudent, identifiant un groupe légèrement plus large pour s'assurer que rien d'essentiel ne soit oublié. Ce comportement suggère que le niveau de désaccord au sein d'une équipe est en soi un signal utile. Les chercheurs ont également découvert que la manière dont les gens expriment leurs préférences importe énormément. Ils ont testé trois méthodes différentes pour recueillir les contributions : classer les éléments par ordre, attribuer un score, ou distribuer un nombre fixe de points. Ils ont constaté que ces différentes méthodes produisaient des résultats significativement différents. Par exemple, dans un réseau à haut conflit, passer d'un système de classement à un système de notation modifiait complètement les exigences considérées comme les plus importantes.

La découverte la plus significative était peut-être que le groupe spécifique de personnes choisi pour fournir des informations changeait le résultat des priorités du projet. Lorsque les chercheurs ont comparé les priorités fixées par l'ensemble de la foule des parties prenantes par rapport à celles fixées uniquement par les parties prenantes « clés » identifiées par leur méthode, les résultats étaient souvent statistiquement différents. Cela signifie que s'appuyer sur les opinions de tout le monde peut mener à un ensemble d'objectifs différent de celui obtenu en s'appuyant sur les opinions des personnes les plus influentes. Dans certains cas, la « foule » privilégiait des fonctionnalités dont les parties prenantes clés ne se souciaient pas, et vice versa. L'étude suggère que si une équipe ne filtre pas soigneusement qui elle écoute, elle risque de construire un logiciel qui satisfait la multitude mais échoue à satisfaire les quelques personnes qui dirigent réellement le succès du projet.

Les chercheurs ont conclu que leur approche offre un moyen pratique et automatisé d'identifier les bonnes personnes à écouter, transformant un processus subjectif et désordonné en un processus structuré et quantitatif. Ils n'ont pas prétendu avoir résolu tous les problèmes du développement de logiciels, mais ils ont démontré que la gestion du conflit ne consiste pas seulement à lisser les choses, mais à utiliser ce conflit pour affiner la liste de ceux qui comptent. En traitant les opinions des parties prenantes comme des données pouvant être combinées et analysées, les équipes peuvent dépasser l'intuition et prendre des décisions basées sur un consensus clair. Ce travail souligne que dans le réseau complexe des projets logiciels modernes, savoir qui écouter est aussi crucial que de savoir quoi construire. L'étude rappelle que le chemin vers un projet réussi commence souvent non pas par une liste de fonctionnalités, mais par une compréhension précise du réseau humain qui le sous-tend.