Les spécifications à problème (3) Spécifications qui arrivent après le développement.

Ce billet est le dernier d’une série de trois articles consacrés aux spécifications et à leurs problèmes. Les deux précédents parlaient de l’absence de spécification et des spécifications qui changent en cours de développement.

En image

Version texte

• Jour 1 : on coule le béton
• Jour 2 : on construit les murs et le toit
• Jour 3 : on détruit tout et on recommence

Explication du client : « Je ne vous avais pas dis que je la voulais plus petite ? Pourtant c’est logique, c’est moins cher ! »

Mon avis

Ce cas est mon préféré (si je puis dire). Parce qu’il est tellement évident que tout le monde pense en être prémuni. Et pourtant, même les meilleures organisations tombent encore dedans de temps en temps.

La principale cause qui amène à cette situation, c’est lorsqu’un planning de développement a été décidé, mais que la spécification n’est pas prête à temps. Par exemple, en basant vos développements sur un cycle itératif, vous connaissez les dates de début des prochaines itérations. Théoriquement, les spécifications fonctionnelles devraient être écrites au préalable, de manière à pouvoir commencer chaque cycle en connaissant précisément le travail qui devra y être accompli.

Malheureusement, personne n’est à l’abri d’un raté dans l’écriture des spécifications. La réflexion peut être plus compliquée que prévu. Il peut y avoir des querelles de clochers, qui font que plusieurs personnes s’affrontent sur des points-clés, ce qui bloque l’avancement des choses. Même en ayant les idées claires, un spécification peut comporter de nombreux éléments (explication textuelle, wireframe, maquettes, storyboard, cahier de test, …) qui peuvent prendre plus de temps que prévu à délivrer.

Il n’y a pas de solution miracle contre ce problème. C’est dommage, car j’ai vu plusieurs fois des développements être entamés en se basant sur des spécifications incomplètes, sur la seule bonne foi que « on sait où on va, les maquettes ne feront que confirmer tout ça ». Et lorsque les maquettes arrivent, on se rend compte qu’il faut casser une partie importante du travail, pour le refaire autrement. Avec au passage tous les problèmes déjà entrevus dans l’article sur les spécifications qui changent en cours de développement.

Alors que faire ? Deux choses :

1. Anticiper. Prévoir les choses plus tôt. Fixer des dates de livraison des spécifications qui ne soit pas la veille du cycle de développement.
2. Découper. Comme dis plus haut, une spécification est composée de plusieurs éléments. Il ne faut pas attendre que tout soit terminé pour commencer à passer en revue les éléments terminés. Si une expression de besoin est incorrecte, vous pouvez le détecter rapidement, n’attendez pas que la spec textuelle et les maquettes soient terminés avant d’y mettre votre grain de sel.