Langue de l’interface
La plupart des outils de gestions des exigences sont en anglais.
Si les membres de vos équipes de développement utilisent souvent cette langue dans leurs outils techniques, celle-ci n’est pas forcément maitrisée par les membres de vos équipes d’analystes, métiers ou réglementaires.
Proposer une interface dans la langue native de l’utilisateur est donc un atout pour son appropriation et sa bonne utilisation par vos équipes.
Langue des exigences
Dans un contexte international, il est courant que des équipes de pays et donc de langues différentes interviennent sur vos projets.
Le consensus le plus courant est de rédiger les exigences en anglais.
Malheureusement, ce choix peut conduire à des erreurs en raison d’une mauvaise maitrise de cette langue par les intervenants (métier, réglementaire, analystes ou même techniques). En matière réglementaire en particulier, il est fondamental que les exigences réglementaires, pour lesquelles chaque mot a son importance, soient reportées dans leur langue de rédaction initiale.
Proposer un outil de gestion des exigences qui fournit une traduction fiable et de qualité va dans le sens d’une diminution des erreurs de rédaction, d’interprétation et compréhension des exigences.
Vous confortez également les différents utilisateurs en leur proposant un contenu dans leur langue native.
Réticences des équipes techniques
Certains responsables d’équipes techniques voient dans un outil de gestion des exigences un concurrent aux outils de modélisation UML qu’ils utilisent éventuellement. Il y a également une peur non justifiées qu’une partie de leurs activités leur « échappe » au profit des analystes.
Cette peur et ce ressenti sont largement subjectifs et injustifiés :
- Un outil de gestion des exigences n’est pas un outil de modélisation UML et ne peut ni ne doit remplacer ce dernier. De la même façon, un outil de modélisation UML n’est pas un outil de gestion des exigences et il ne répond pas aux besoins de vos équipes non techniques ;
- La clarification des exigences, grâce à l’utilisation d’un certain nombre de diagrammes / représentations définis par UML, améliore la qualité les exigences fournies par les analystes. Cette clarification et augmentation de la qualité diminuent les erreurs d’interprétation, le temps perdu en réunion, les erreurs (couteuses) de conception / architecture et vont permettre aux équipes techniques de se concentrer sur leur vrai métier : l’architecture, la conception technique et l’implémentation du besoin exprimé ;
- Il ne faut pas oublier que les diagrammes et représentations UML utilisées par les analystes ne sont que des compléments aux autres exigences textuelles et ne peuvent en aucun cas constituer l’intégralité du référentiel d’exigences. C’est la raison principale pour laquelle l’idée de certains responsables techniques d’imposer l’utilisation d’un outil de modélisation UML aux analystes est une erreur.
Les équipes techniques ont tout à gagner de l’utilisation d’un outil de gestion des exigences par votre organisation.
L’absence d’intégration avec les autres outils
L’absence d’intégration avec les outils de modélisation ou de tests est un argument souvent utilisé par les responsables techniques contre la mise en place d’un outil de gestion des exigences.
Si une telle intégration est effectivement souhaitable, son absence ne saurait justifier de ne pas fournir à vos équipes non technique un outil qui conduit à la création d’un référentiel d’exigences de qualité.
Par ailleurs, les fonctions d’export proposées dans la plupart des outils de gestion des exigences permettent d’assurer une réutilisation des exigences dans les outils de modélisation UML, de gestion de contenu à destination des équipes de développement ou encore de tests.
Il ne faut pas oublier que l’intégration a un coût : c’est l’augmentation de la complexité dans l’utilisation des outils et la lourdeur des processus permettant de passer de l’un à l’autre. Une fois passés les arguments marketing sur les vertus de l’intégration qui ont conduits à l’acquisition d’outils aux coûts de licence et de fonctionnement parfois prohibitifs, ce sont les utilisateurs qui se retrouvent confrontés à une utilisation difficile, voire impossible.
Résistance au changement « naturelle » (MOA, équipes techniques, métier)
Toute nouvelle méthode de travail, tout nouvel outil rencontre une résistance naturelle au changement. Afin de faciliter l’appropriation de votre outil de gestion des exigences, il est primordial de rappeler à vos équipes :
- Le coût financier et humain de l’absence ou d’une mauvaise gestion des exigences ;
- Les bénéfices d’un outil de gestion des exigences pour tous les intervenants de vos projets de développement.
L’appropriation et l’adoption de l’outil sont en général très rapide. Vos analystes seront d’ailleurs incapables de s’en passer au bout de quelques mois…
Des revues collaboratives qui remplacent les documents provenant d’outils bureautiques
Les inconvénients liés à l’utilisation de documents issus d’outils bureautiques (Word, Excel, Powerpoint) sont bien connus :
- La validation de documents de dizaines à centaines de pages, dans lesquels les besoins sont dilués dans une structure parfois touffue, est tout simplement impossible. On a dans les faits une validation par défaut, en attendant de voir ce que ça donne vraiment une fois implémenté ;
- Le coût financier et humain d’exigences imprécises, peu claires, incomplètes et parfois même contradictoires est très important ;
- Les conséquences sont également importantes en termes de relations entre les équipes non techniques et techniques, les premières se sentant incomprises et les secondes se retranchant derrière une formalisation interprétée d’un besoin mal exprimé (voire pas exprimé du tout).
Les revues collaboratives apportent des changements importants dans le processus de validation des exigences :
- Des revues au périmètre clairement défini et limité sur un nombre réduit d’exigences ;
- Une validation engageante… et non plus par défaut ;
- La revue devient une activité collaborative, ce qui augmente la qualité, la complétude et la pertinence des retours sur les exigences de la revue ;
- La garantie pour les équipes techniques d’exigences claires, précises, complètes et non contradictoires.
La encore, il est important de communiquer sur les inconvénients des revues réalisées avec des documents issus d’outils bureautiques et d’expliquer les avantages (pour tous les participants de vos projets de développement) des revues collaboratives ciblées.
Conclusion
Vous l’avez compris, la professionnalisation de vos analystes, qui résulte de la mise en place d’un outil de gestion des exigences pour vos projets de développement, va rencontrer un certain nombre de résistances, le plus souvent de la part des responsables de vos équipes techniques.
Afin de lever ces freins, il est fondamental de rappeler les inconvénients d’exigences rédigées avec (et non gérées par) des outils bureautiques et les bénéfices, pour tous les intervenants de vos projets de développement, de la mise en œuvre d’une véritable gestion des exigences.
Heureusement, ces résistances et ces freins disparaissent très rapidement dès les premiers sprints !