En général quand je dis ça comme ça, ça fait sourire :).

Les informaticiens doivent se dire « oui elle est gentille, elle n’invente rien, tout le monde veut créer de la valeur ».

Sauf que messieurs-dames les informaticiens, je ne sais pas pourquoi vous êtes les seuls à qui il faut expliquer ça. L’informaticien(ne), très poli, peut me demander « bon d’accord mais c’est quoi la valeur pour le client ? ».

La valeur est créée quand les clients sont contents.

Tout « bon » chef de projet vous le dira : le client ne sait pas ce qu’il veut. Et puisque le client ne sait pas ce qu’il veut, on va se protéger de son indécision et en lui faisant valider des spécifications.

D’ailleurs un « bon » chef de projet est celui qui se bat le mieux.

C’est donc une guerre, le développement logiciel.

On entend alors :

  • « monsieur le client, ce que vous demandez n’est pas du tout conforme avec la demande initiale » -> changement
  •  « monsieur le client ce n’est pas ce que nous avions convenu dans les spécifications » -> changement

Et qui dit changement dit facturation supplémentaire, et le chef de projet est content.
L’objectif avoué est donc de faire valider les spécifications et de ne pas produire de bugs en face de ces spécifications. Au passage si on a pu facturer cher les changements c’est super.

Et bien pas du tout.

En agile on dit bienvenue au changement, le changement est une opportunité, une chance d’arriver au bon produit.
La réaction normale au changement devrait être :

  • « super ! ça sera mieux comme ça ! »

 

Rendez vous compte que l’on demande aux clients de valider des spécifications. Le client ne sait pas faire ça ! Le client sait parler de son besoin, pas des spécifications.

Par exemple : prenons mon plombier, lors d’une visite de chantier de ma maison.
Il me demande « Madame, je les mets où les lavabos ? »
Moi je n’en sais rien du tout, et je le lui fais savoir.
Il m’emmène dans la salle de bain et me dit « Vous vivez comment là dedans ? »
Là c’est facile je sais répondre : « On aime bien avoir de la place sous la douche, pour mettre les affaires sèches à proximité. Puis on aime bien être tous devant le miroir pour prendre des photos du brossage de dents c’est rigolo. »
Pendant que je parle il déduit que la table supportant les 2 lavabos doit être à xxx cm du mur 1 et à xxx cm du mur 2.

Nous avons fait une conversation sur mon besoin, et de cette conversation a émergé la spécification.
Mon plombier n’est pas allé me chercher un « plombier spécifieur » pour écrire une spécification qu’il m’aurait faite valider, puis il aurait fait appel à un « plombier développeur» qui aurait réalisé le produit.
Celui qui réalise (le plombier) est le mieux à même de discuter pour savoir comment répondre à mon besoin : nous avons cette conversation ensemble, lui et moi.

 

Les informaticiens sont informaticiens. Les plombiers sont des plombiers. Les plombiers savent que leurs clients ne sont pas plombiers. Pourquoi les informaticiens ne savent ils pas que leurs clients ne sont pas informaticiens ?

J’entends trop souvent « le client ne sait pas ce qu’il veut » : c’est faux. C’est surtout qu’on ne parle pas le même langage, et qu’on ne pose pas les bonnes questions.
Au lieu de « monsieur le client, que voulez vous comme écran ? » , il faut demander « monsieur le client, comment doit on améliorer votre vie ? ».

On doit lui demander quelle valeur métier on doit créer, et avoir une conversation avec lui à ce sujet.

J’ai l’impression que nous autres les informaticiens nous sommes hautains, conscients de notre supériorité face à cet outil, l’informatique, qui est censé être connu de tous et dont nous sommes les experts (les magiciens).

Ou alors on ne se rend pas compte que notre métier dépasse le cadre strict de l’informatique, et que l’on doit chercher à comprendre quelle est la valeur à créer.

 

La question du comment est la question de la spécification.

Bien sûr il y a des spécifications en agile, ne commettez surtout JAMAIS l’erreur de les enlever.
En agile on raconte des histoires pour comprendre le besoin : en tant que xxx je veux xxx afin de xxx.

Afin de : c’est la question de la valeur à créer.

Raconter des histoires, avoir une conversation sur le besoin pour faire émerger la spécification, cela donne du sens aux développeurs. Cela leur permet de comprendre quelle valeur il faut créer et de ne pas se retrouver à la fin à entendre un client pas content dire « non ce n’est pas un changement, c’était implicite ».

L’objectif contractuel de respecter les spécifications doit être remplacé par des objectifs métiers : la valeur doit avoir été créée là, là et là.

 

La question est simplement : quel est votre besoin ? que voulez vous faire ? pourquoi devons nous faire ceci ?

L’objectif est de rendre les gens contents, de réaliser des applications parfaites où les utilisateurs ne passent pas leur temps à chercher la fonction x ou y. Le client doit pouvoir utiliser l’application comme quand j’utilise le lavabo : c’est mon bon produit.

 

On veut changer le monde : le rendre plus heureux pour tous. 

L’objectif est de changer la vie de nos utilisateurs. Avant ils n’avaient pas cette application : pourquoi doit on la faire ? Quelle valeur doit on créer cette fois ci ?

 

L’agile est une démarche disciplinée de création de valeur.

 

 

 

Développeur, Chef de projet et surtout Scrum Master pendant plusieurs années. J’ai connu un avant et un après l’agilité 🙂
Je crois profondément que ce sont les personnes et les interactions qui font réussir les projets, que les personnes sont importantes et qu’elles veulent bien faire leur travail.
Aujourd’hui Coach agile, j’accompagne les projets et les organisations dans leur transformation agile.

Citations :
« Il est préférable d’être à peu près juste que précisément faux. » (John Maynard Keynes)
« Je sais pourquoi tant de gens aiment couper du bois. C’est une activité où l’on voit tout de suite le résultat. » (Albert Einstein)
« Aucun plan ne survit au premier contact avec l’ennemi » (Von Moltke)
« Soyez insatiable soyez fou » (Steeve Jobs)