Conséquences d'avoir des exigences en retard

Voici le principal problème que nous avons avec les exigences: les experts métiers ne réalisent pas les conséquences qu'entrainent la remise tardive des exigences d'un projet.

L'équipe informatique sait généralement que chaque phase après l'analyse coûte de plus en plus cher pour revenir en arrière et ajouter des exigences, mais les experts métiers n'ont pas cette connaissance.

Le métier ne comprend pas ce que cela coûte en temps, en argent et en efforts pour revenir en arrière, avoir des discussions sur les nouvelles exigences, mettre à jour la documentation, mettre à jour la conception, écrire le nouveau code, mettre à jour la documentation de test, et l'ajouter au planning de test. Puis le tester et éventuellement avoir du temps pour retravailler dessus.

La meilleure façon de gérer cela est d'inclure un peu d'éducation au coup d'envoi de votre session de recueil des exigences. Expliquer l'importance d'être impliqué dès le début et de faire notre mieux pour identifier toutes les exigences durant la phase d'analyse. Vous pouvez dire que c'est compréhensible que, de temps en temps, il y aura des exigences manquantes qui arriveront plus tard dans le projet, mais notre but est de minimiser cela autant que possible.

Maintenant, nous allons faire un peu de math. Nous devons être capable de mesurer cela. Un coût de 1 est affecté à l'effort nécessaire pour corriger une erreur dans les exigences - c'est à dire ajouter, changer, ou supprimer une exigence à différentes phases du projet.

• Durant la phase de recueil des exigences, cela coûte 0,1 à 0,2 pour corriger une exigence
• Durant la phase de conception, cela coûte 0,5
• Durant la phase de développement, cela coûte 1
• Durant la phase de tests unitaires, cela coût 2
• Durant la phase de tests d'acceptance, cela coûte 5
• Durant la phase de maintenance (après le déploiement en production), cela coûte 20 pour corriger un problème

Cela nous apprend qu'il coûte 200 fois plus cher de corriger une exigence lors de la phase de maintenance que lors de la phase de recueil.

Voici d'autres chiffres qui viennent d'études faites par IBM et HP: 4% des projets échouent à cause de délais irréalistes, 13% échouent à cause du manque d'information de la part des utilisateurs, 12% échouent à cause d'exigences incomplètes, et 12% des projets échouent à cause des changements dans les exigences et les spécifications.

Si vous ne voulez pas utiliser l'exemple du coût unitaire avec votre métier, au moins donnez leur ces pourcentages.

Puis dites leur que "nous ne voulons pas que ce projet échoue en raison d'un manque d'information ou d'exigences oubliées. Donc, nous allons tous rester impliqués tout au long de ces séances de recueil d'exigences et nous assurer que nous les avons toutes répertoriées. Mon travail en tant qu'analyste est de documenter vos attentes à propos du logiciel. Je ne peux pas faire de proposition et vous ne devriez pas vouloir que je le fasse. Ceci est votre chance de nous dire exactement ce que vous avez besoin pour être efficace, et avoir les outils nécessaires pour faire votre travail. Ne laissez pas passer cette occasion - soyez impliqué dans ces discussions afin qu'au moment où vous obtiendrez votre produit, vous pourrez dire "cela ressemble et fonctionne exactement comme je m'y attendais".

L'éducation est la clé du succès. Informez vos partenaires métiers et vous verrez des résultats immédiats.

source originale: The analyst coach