« Nous avons besoin d'un système qui gère les réservations » n'est pas une spécification — c'est un souhait, et aucun développeur ne peut estimer un souhait. L'écart entre ce qu'un client veut dire et ce qu'un développeur peut réellement construire est l'endroit où la plupart des devis dérapent avant même la première ligne de code, parce qu'un brief vague reçoit une estimation vague, et une estimation vague est la graine de chaque dispute de périmètre qui suit.
La différence entre une fonctionnalité et une spécification
« Les clients doivent pouvoir réserver en ligne » décrit une fonctionnalité. Cela ne dit pas ce qui se passe quand deux clients essaient de réserver le même créneau au même moment, si une réservation nécessite une validation ou se confirme instantanément, ce qui arrive si le paiement échoue après que le créneau a été retenu, ou si l'annulation dans l'heure précédant le rendez-vous se comporte différemment d'une annulation une semaine avant. Chacun de ces points est une décision réelle avec un coût de développement réel, et aucun n'est visible dans la phrase décrivant la fonctionnalité — ils n'apparaissent qu'une fois que quelqu'un commence à construire et doit deviner, ou s'arrête et pose la question.
Les critères d'acceptation transforment un souhait en quelque chose de constructible
Une spécification devient estimable dès qu'elle énonce précisément à quoi ressemble le « terminé » : pour cette entrée, exactement cette sortie ; pour ce cas limite, exactement ce comportement. « Un client peut réserver un rendez-vous » devient constructible une fois formulé plus près de « un client sélectionne un créneau disponible, reçoit une confirmation en moins de 60 secondes, et le créneau devient indisponible pour les autres clients dès sa sélection, pas seulement une fois le paiement terminé ». Ce niveau de précision semble excessif pour une petite fonctionnalité et semble indispensable la première fois qu'une fonctionnalité ambiguë déclenche deux semaines de désaccord sur ce qui avait réellement été promis.
Les ambiguïtés qui causent des dépassements de façon fiable
Une poignée d'écarts apparaît dans presque tout projet sous-spécifié : que se passe-t-il en cas d'erreur (l'utilisateur ne voit rien, un message générique, ou un message précis), que se passe-t-il aux limites de l'usage normal (zéro résultat, l'entrée maximale autorisée, une soumission en double), qui peut voir ou modifier quoi, et que doit faire le système quand deux personnes tentent d'agir sur le même enregistrement en même temps. Rien de tout cela n'est exotique — ce sont des situations ordinaires qui se produisent constamment en production — mais ce sont exactement les situations qu'un brief d'un paragraphe ne mentionne jamais, parce qu'elles ne deviennent évidentes qu'une fois que quelqu'un construit réellement la chose.
Pourquoi cela protège les deux parties, pas seulement le développeur
Une spécification détaillée n'est pas de la bureaucratie gratuite — c'est le document vers lequel les deux parties peuvent se retourner quand un désaccord surgit plus tard. Sans elle, « ce n'est pas ce que nous avons demandé » et « c'est exactement ce que vous avez demandé » sont deux affirmations vraies à propos de la même phrase vague, et résoudre cela coûte plus de temps et de bonne volonté que rédiger correctement la spécification dès le départ n'en aurait coûté.
Bien faire cela dès le début fait partie de la même décision acheter, construire ou configurer — car même la bonne approche ne produit un système qui fonctionne réellement que si ce qui est construit a été spécifié assez clairement pour être construit.
Notre équipe logicielle transforme la description simple d'un client en spécifications au niveau des critères d'acceptation avant d'estimer quoi que ce soit, pour que le devis reflète ce qui va réellement être construit, pas une supposition.
