Les spécifications à problème (1) Pas de spécification

Il existe 3 grands types de problèmes avec les spécifications. Il y a quelques mois, j’ai préparé une présentation pour expliquer notre nouvelle organisation dans mon entreprise. Dans cette présentation, j’abordais les spécifications, en tentant d’expliquer les conséquences négatives qu’il peut y avoir lorsqu’elles ne sont pas préparées correctement.

Pour rendre mon propos immédiatement compréhensible, j’ai fait un parallèle avec l’architecture «classique», qui est souvent utilisée pour imager l’architecture informatique. Soyez indulgents quant à la qualité des dessins, ça a été fait avec OpenOffice Impress, qui n’est pas vraiment idéal pour ça (ni aidé par mes talents).

En image

Version texte

On peut voir un mur de briques qui s’éloigne à l’infini.

Explication du maçon : « Moi, tant qu’on me dit rien, je fais du mur ! »

Mon avis

Trop souvent − et quel que soit le type d’entreprise dans laquelle j’étais − je me suis retrouvé dans des situations problématiques, simplement parce que les personnes censées réfléchir aux spécifications fonctionnelles ne prenaient pas le temps de penser à tous les cas particuliers de ce qu’ils voulaient mettre en place, ou parce qu’ils estimaient que certaines choses étaient tellement évidentes qu’il n’y avait pas besoin de les exprimer clairement.

Dans le meilleur des cas, l’équipe technique est obligée d’éclaircir ces zones d’ombre, car il est impossible d’écrire du code « flou ». Cela fait alors perdre beaucoup de temps, car il faut faire des allers-retours avec le client, pour déterminer précisément le périmètre de son besoin. Et si le besoin n’a pas été suffisamment bien pensé (s’il l’avait été, la spécification aurait été faite), on perd encore plus de temps.

Dans le pire des cas, ce sont carrément des fonctionnalités entières qui ne sont pas développées. Vous connaissez l’exemple le plus débile que j’ai vu dans le genre ? Un site qui a été développé sans fonctionnalité « Mot de passe oublié ». Les fonctionnels n’en ont pas parlé parce que ça leur semblait aller de soi. Les développeurs avaient le nez dans le guidon, submergés de boulot qu’ils étaient, et se sont contentés de développer ce qui a été spécifié. Évidemment, ce genre d’erreur n’est découverte qu’après la mise en production finale…