Importance du recueil des besoins

1. Du côté de la recherche de l’ingénierie des besoins

Certaines études ont montré que l’inadéquation entre les développements et les besoins, d’une part, et les changements de besoins (changement de scope), d’autre part, sont deux facteurs importants dans l’échec des projets (Timothy G. Olson - Successful Strategies to Improve Your Requirements...

1. Les coûts pour le projet

Une recherche effectuée par Boehm et Papaccio (Understanding and controlling software cost : fixing error cost) montre que les coûts de la correction d’une erreur augmentent exponentiellement en fonction de la phase du projet.

L’explosion des coûts

Il sera de 1 USD lors d’une correction en phase de définition des besoins, le coût moyen passera à 5 USD en phase de design, 10 USD lors d’une correction pendant les développements, 20 USD pendant les tests et jusqu’à 200 USD pour une correction après la mise en production.

Cette étude, bien qu’un peu ancienne, a été mise à jour et il semble que le ratio reste stable, mais les coûts ont, eux, tendance à augmenter.

Les projets dont les délais sont serrés et les organisations poussant pour des livraisons rapides sont dans une zone à risque concernant des erreurs sur les recueils des besoins. En effet, poussant les équipes à livrer plus vite, on optera pour la solution la plus rapide et donc celle qui sera la moins fiable. Le recueil des besoins et les tests sont en général les premières étapes qui passent à la trappe. Ces pratiques font multiplier le nombre de bugs par quatre.

L’explosion des délais

L’adage dit : "si on n’a pas le temps de faire les choses...

1. "Les utilisateurs changent d’avis"

Avec les variantes suivantes : "ils ne savent pas ce qu’ils veulent", "ils ne comprennent pas leur propre besoin"…

…Ou alors, le besoin exprimé n’est pas associé avec la stratégie métier des utilisateurs. Si vos besoins sont "flottants", ils ne sont pas ancrés et pas justifiés par un besoin métier, il est alors facile de les changer. Il sera beaucoup plus compliqué de changer une exigence si elle répond à une stratégie, une tactique et un processus opérationnel des parties prenantes fonctionnelles.

…Ou alors vos parties prenantes sont expertes dans leur domaine (marketing, finance…), mais pas en design de solution pour supporter leur quotidien. Lorsque Steve Jobs a lancé son iPhone, peu de futurs utilisateurs auraient été aptes à définir les fonctionnalités d’un smartphone. Elles étaient alors définies en prenant en compte une vision, une problématique des utilisateurs et les capacités d’innovation de l’entreprise. De la même façon, il est souvent difficile pour vos utilisateurs de décrire les caractéristiques de la future solution.

…Ou alors vos parties prenantes ont une réelle justification au changement. La stratégie change, le management change, le marché change, le processus métier change, donc le système décisionnel doit s’adapter. Lorsqu’on voit apparaître ce genre de changement, il est rare que les développeurs ou les analystes pensent que leurs parties prenantes font les girouettes.

Oui, les changements sont inévitables lors d’un projet, encore faut-il qu’ils soient signifiants pour la réalisation de l’objectif global défini.

2. "Ne pas livrer dans les délais : c’est normal"

Voici l’une de mes histoires préférées. L’histoire de Tchouri et Rosetta, une mission spéciale...