Faut-il écrire des spécifications ?

Au début d'un projet, on veut parfois écrire beaucoup.

Ecrire ce que le logiciel fera. Les données qu'il va manipuler. Les fonctions disponibles. Le design des différents écrans.

Après avoir écrit tout ça, on se met d'accord avec les multiples parties prenantes qui vont approuver le document. Puis on le soumet à une équipe qui va transformer le document en code, pour un prix fixe convenu à l'avance.

Cette façon de procéder donne l'impression de maîtriser les choses. On sait ce qu'on veut. On sait ou on va et combien ça va coûter. Les risques semblent réduits.

J'ai vu des projets très réussis de cette façon. Et d'autres sévèrement bousculés en cours de route.

Parce qu'il est très difficile de s'accorder sur une représentation mentale unique à la seule lecture d'un document. Pour une même phrase, chaque lecteur imaginera une version différente (un peu comme dans un roman).

La conséquence est d'obtenir à la fin quelque chose de très différent de ce que vous aviez envisagé au départ. Et comme le prix fixe est convenu à l'avance, vous allez batailler indéfiniment sur l'interprétation des phrases, et surtout à propos de ce qui n'est pas écrit.

“Bien sûr que je n'ai pas écrit qu'il fallait pouvoir ajouter un utilisateur. Mais c'est évident sinon c'est inutilisable.”

Cahiers des charges, spécifications, ou tout autres documents décrivant l'attendu de l'application sont difficiles à écrire. Il faut chasser toutes les ambiguïtés en intégrant des exemples, des schémas ou des copies d'écran.

Mais ça ne met pas à l'abri des oublis. Par exemple :

• sur l'administration des données,
• sur le comportement attendu en cas d'erreur, ou de donnée manquante.

Alors pour synchroniser ce qu'on a en tête avec l'équipe de développement, j’ai observé deux pratiques qui ont bien fonctionné.

Le prototype

Rien de tel qu'un exemple concret pour se faire une idée commune de l'objectif, pour faire émerger les questions.

Un prototype est une sorte de conversation avec votre idée. Il offre un moyen de trouver des simplifications qui vont rendre l'outil intuitif. Il valide aussi le projet, et illustre de quelle façon il résoud le problème.

Pour construire un prototype, on peut procéder :

• avec un wireframe, c'est à dire un schéma simplifié des différents écrans. Un peu à l'image de ce qu'on ferait sur un tableau blanc. Le problème est que l'on se contente d'une vue statique, alors que les utilisateurs cliquent, scrollent, zooment, ... Le wireframe ne permet pas de représenter les interactions.
• à l'aide d'un outil de design (AdobeXD, Sketch, Figma). Apprécié des designers, il donnera un rendu très précis et très travaillé.
• en codant quelques parties visibles de l'application, en utilisant de fausses données. Une fois au point, on peut s'en servir comme point de départ pour coder le reste de l'application.

Le risque du prototype est de partir trop tôt sur un mauvais niveau d’abstraction. On peut se perdre dans les détails (le bouton à cet endroit, le texte un peu plus gros, …) au lieu de se concentrer d’abord sur les concepts : quels services propose-t-on à l’utilisateur ? Quelles données manipule-t-il ? Comment gagne-t-il réellement du temps ?

L'immersion

Le succès d'un projet repose aussi sur la capacité du développeur à incarner les utilisateurs du produit qu'il conçoit.

Il vous faut passer du temps à expliquer pourquoi vous avez besoin de faire développer quelque chose, et comment vous pensez que les utilisateurs vont interagir avec le produit.

• Organisez des discussions avec l'équipe de développeurs.
• Expliquez-leur votre métier, votre organisation, les attentes de vos clients.
• Immergez-les quelques jours dans vos équipes.
• Montrez-leur vos outils actuels, avec lesquels vous travaillez au quotidien.

Ces capacités à se projeter, à se mettre à votre place, à comprendre votre besoin et votre modèle d’affaire constituent une clé de réussite du projet au moins équivalentes aux qualités techniques.

Le temps manque toujours. Alors si on le consacrait plutôt à expliquer / discuter / prototyper, plutôt que de s’enfermer plusieurs jours pour écrire un pavé rapidement obsolète qui risque d’être rarement lu ?