SAND-framework/data/doc-prince-book-generation/doc/tome1/Contents/func-communiquez.md

# Communiquez

## Adoptez une Langue Commune

Ce que vous entendez en utilisant un mot peut parfois (souvent !) être
totalement différent de ce qu'une autre personne entend pour ce même
mot. Et c'est encore pire avec les développeurs !


Gardez cela à l'esprit : les développeurs ne parlent pas la même langue
que vous. Lorsque vous parlez "stock", "produit" ou "commande", un
développeur pensera "base de données", "enregistrement" et "sauvegarde
en base".


La première chose à faire est donc de constituer avec vos équipes une
Langue Commune. Peu importe le moyen : une feuille excel, un document
word ou un bout de papier feront l'affaire ! L'important  est de créer
un référentiel commun, souvent désigné par "Ubiquitus Language",
c'est-à-dire **un moyen d'utiliser une terminologie dont on sait qu'elle
est comprise par tous de la même manière**.


Attention, cet Ubiquitus Language, **cette Langue Commune ne doit PAS
être élaborée unilatéralement !** Instaurez un dialogue entre toutes les
parties prenantes du projet, jusqu'à déterminer des termes plus
importants que les autres. Identifiez les, puis, en commun,
définissez-les. Ne l'oubliez pas : une définition que vous aurez mis en
place tout seul ne voudra peut-être rien dire pour un développeur.


Dernière chose : ce référentiel commun ne doit porter que sur le domaine
fonctionnel. Il est inutile de créer un référentiel technique (du moins
pas en dehors des équipes techniques) : ce qui compte ce n'est pas de
faire du développement logiciel ; non, ce qui compte c'est votre
produit, vos bénéfices fonctionnels et votre vision !


Pour synthétiser cette Langue Commune en quelques mots, elle permet :

+ d'éviter un travail de traduction entre les tâches techniques et les
besoins fonctionnels (le jargon métier)
+ que tout le monde "parle" votre projet comme vous le "pensez"
+ d'éviter de vous retrouver avec des surprises idiotes, dues à des
incompréhensions sémantiques ou à des ambiguïtés.



> les développeurs ne parlent pas la même langue que vous


## Laissez la technique aux développeurs

Laissez-moi vous rassurez tout de suite : **non, vous n'avez pas besoin
de savoir comment fonctionne techniquement votre produit**. Non, vous
n'avez pas à comprendre la terminologie des développeurs.

Mieux ! Vous ne devez SURTOUT PAS comprendre ce que font les
développeurs.


Ça fait maintenant quelques années que je conduis une voiture. Je sais
passer mes vitesses, je comprend comment lire mon tableau de bord...
Mais je ne sais pas, mais alors pas du tout, comment fonctionne ma
voiture. Et croyez-moi, je n'en ai rien à faire ! 


Je dois vous avouer une chose : quand j'ai une panne, je vais voir mon
garagiste et je lui fais confiance. Quand il m'explique le problème, je
dis des "ah oui ?" avec un air curieux. Mais je ne comprend rien ! Et c'est 
tant mieux !


Pourquoi serait-ce différent pour l'informatique ? Mettre les mains
"dans la cambouis" risque :

+ de brider vos demandes quand vous allez imaginer qu'un point va être
techniquement coûteux alors qu'il n'en n'est rien
+ de vous faire adopter une angle de vue différent (celui des développeurs) au détriment de votre vision initiale
+ de laisser le code dominer le domaine fonctionnel
+ de vous faire perdre votre force fonctionnel

Je peux vous le dire : les projets les plus coûteux et les plus en
retard sur lesquels j'ai travaillé ont été initié par d'anciens
développeurs devenus chefs d'entreprise ou fonctionnels. Naturellement,
et on ne peut pas les en blâmer, ils ont tendance à vouloir comprendre
l'implémentation technique de leur produit. 


Cependant, cela est très coûteux : tout d'abord l'équipe technique doit
passer beaucoup de temps à expliquer ce qu'elle fait au lieu d'avancer
réellement. Ensuite, elle doit passer du temps également à monter en
compétence le fonctionnel. Enfin, et ce n'est pas le moindre, cela
introduira un sentiment de défiance entre vous et l'équipe technique,
sentiment qui va ralentir et limiter vos possibilités de créer une
Langue Commune et freiner l'investissement de vos équipes.


> Vous ne devez surtout pas comprendre ce que font les développeurs



## Racontez votre produit

Combien de documents sont passés entre vos mains sans que vous ne les
lisiez totalement, partiellement ou pas du tout ? Avouez-le, cela nous
est tous arrivé au moins une fois. 

Pourquoi le document que vous fournissez à votre prestataire ne
serait-il pas justement celui-là même qu'il va survoler, ou mal
comprendre ?

Un document word, par exemple, est une excellente base de travail. Vous
pouvez y noter vos réflexions, vous en servir comme brouillon... Mais
pas comme spécification !

Comprenez : votre pensée est ce qu'elle est : mouvante, changeante, et
surtout personnelle. Avec tous les efforts du monde, vous n'arriverez
pas à transmettre l'ensemble de votre pensée par écrit. Il subsistera
toujours de l'interprétation, des non-dits, de l'implicite... Voire même
parfois des contradictions qu'il faudra lever. C'est normal, comme un
projet, une pensée vit et change.

Votre vision, vos besoins, vos spécifications... tout cela doit faire
l'objet d'un échange oral. Racontez votre produit plutôt que de le
décrire. Qu'en pensez-vous ?

**Votre projet doit être le résultat d'une conversation** : impliquez
vous, mais impliquez aussi le testeur, le fonctionnel, l'ergonome, le
graphiste et le développeur. Racontez leur votre produit, et dialoguez,
de telle manière que :

+ Ils **s'approprient votre besoin**
+ Ils **mettent en évidence certaines incohérences** le plus tôt possible
+ Ils vous proposent des changements (vous restez le seul maître de les
accepter ou non)
+ Ils soient impliqués et aient le sentiment d'être partie prenante de
votre projet
+ Ils ne perdent pas de temps à traduire votre message

C'est d'ailleurs comme ça que vous allez vous rendre compte que certains
points demeurent obscurs, malgré tous vos efforts. Cela signifiera peut-être que 
ces points sont plus importants que vous ne l'estimiez, et il sera
peut-être utile d'y consacrer plus de temps.


Oubliez donc les spécifications fonctionnelles détaillées (SFD), et
autres joyeusetés qui font la joie du développeur quand il doit lire un
document de 200 pages pour comprendre un besoin qu'il mettra 20 minutes
à implémenter. La documentation est utile, les SFG, SFD, etc. aussi,
mais uniquement quand elle est réservée aux cas qui le nécessitent
vraiment ! 


Oubliez cette masse de documentation d'autant plus qu'elle va être un
frein à votre besoin de changements : très vite, avec de nombreux
documents, vous allez : 

+ ou bien avoir un décalage conséquent entre vos spécifications et votre produit (quid des nouveaux arrivants sur le projet ?),
+ ou bien devoir passer un temps précieux à mettre à jour vos spécifications à chaque changement. Et ça, croyez-moi, dans la vraie vie ça n'arrive jamais si vous n'avez pas une ressource dédiée à cette tâche, à temps plein !


Vous allez le voir, il existe d'autres moyens de préciser votre besoin.
En attendant, oubliez les documents word, pdf, rtf... Et Initiez la
conversation.


> Racontez votre produit plutôt que de le spécifier

## Identifiez le Domaine fonctionnel

Vous l'avez vu, vous avez besoin de constituer une Langue Commune avec
vos équipes. Vous le savez également, une image vaut souvent mieux qu'un
long discours... Pourquoi ne pas concilier les deux ?

Il existe une approche, mise en évidence par Eric Evans, pour faire en
sorte le code source (ce qui permet à votre produit de fonctionner)
corresponde de près aux fonctionnalités métiers. Cette approche, c'est
le Domain Driven Design, ou Conception Pilotée par le Métier.


En général, au fil du temps, les développeurs qui auront travaillé sur
votre projet vont mettre en place ce qu'on appelle familièrement des
"rustines", des morceaux de code source rapides à mettre en place mais
peu maintenables, destinés à gérer vos demandes de changements fonctionnels.


Pire, dès le départ, les développeurs vont se focaliser sur les aspects
techniques du projet. Normal me direz-vous ? Non, car s'ils font cela,
l'énergie à dépenser pour comprendre les liens entre le code source et
le besoin fonctionnel risque d'être très importante, voire tellement
importante que votre projet risque de vous mettre sur la paille à la
moindre demande de changement.

Le Domain Driven Design propose une approche différente : les
développeurs vont se focaliser avant tout sur le besoin métier, et
concevoir leur code source autour de ce besoin. Ça peut paraître une
évidence, mais c'est loin d'être le cas, croyez-moi ! Le code source
sera alors le reflet du besoin métier.


Si vous et vos équipes souhaitez mettre en place cette orientation (du
Domain Driven Design), **la première chose dont vous aurez besoin, après
une Langue Commune, sera une cartographie du domaine fonctionnel couvert
par votre application**. 

Rassurez-vous, rien de bien compliqué. Oubliez les logiciels de
modélisation, oubliez Visio, oubliez l'UML, Merise (si vous les avez
déjà utilisés), voici venue l'ère ... du papier et du crayon !


Listez, puis représentez sur un dessin simple, l'ensemble des grands
concepts fonctionnels liés à votre produit (ceux qui sont présents dans
votre glossaire, votre Langue Commune). Reliez-les entre eux par de
flèches annotées, qui représenteront les différentes interactions de ces
concepts entre eux. S'il y a trop de flèches à un endroit, c'est que
vous vous attardez trop sur des détails. Si vous pensez que ce ne sont
pas des détails, prenez une autre feuille et redémarrez, mais cette fois
en zoomant sur la partie concernée.

Cette cartographie, qui doit être simple (en caricaturant un peu, disons
que votre neveu de huit ans devrait pouvoir la comprendre s'il connaît
votre Langue Commune !), sera le **référentiel du Comportement de votre
Produit**.


Ce comportement étant désormais identifié, il sera plus facile pour les
équipes d'appréhender les changements et d'en identifier les
conséquences.


Cette cartographie vous servira également : elle va vous permettre
d'identifier l'indispensable, l'utile et le pratique dans votre produit.
Vos équipes doivent commencer à travailler sur l'indispensable.
L'utile et le pratique viendront après.


> Prenez un papier et un crayon, puis dessinez la cartographie
fonctionnelle de votre Produit


## Faites-vous interviewer

Mais attention, cette cartographie fonctionnelle, en réalité... ce n'est
pas à vous de la faire !

Pourquoi donc cet air surpris sur votre visage ? Je veux simplement dire que ce 
n'est pas à vous *seul* de la réaliser. Mais rassurez-vous, vous en serez le 
moteur.

Concrètement, vous devez dans un premier temps discuter avec vos
développeurs, mais surtout ceux-ci doivent réaliser un travail d'enquête : 
vos développeurs doivent vous interviewer. 

Ou plutôt ils doivent interviewer le Produit. Après tout... vous êtes le
porte-parole de votre produit.

Cet interview, comme une interview classique va consister en différents
moments :

+ présentation générale d'un aspect fonctionnel
+ une question de l'équipe technique sur un point abordé
+ votre réponse fonctionnelle
+ une nouvelle question de l'équipe technique
+ etc.


Attention, l'interview ne doit jamais dériver sur des aspects
techniques. Il sera largement temps plus tard de voir comment résoudre
techniquement tel ou tel point. Pour l'instant, ne discutez QUE du
fonctionnel.


Cette démarche a au moins trois avantages :

+ impliquer les équipes techniques sur votre besoin métier
+ mettre en évidence des aspects implicites, qui sont évidents pour une
personne du métier, mais totalement inconnus des équipes techniques
+ vous permettre de prendre du recul sur votre métier et votre besoin en
l'expliquant à des néophytes.

> Les équipes techniques doient interviewer le porte-parole du produit

## Les tâches ne servent à rien

Vous voulez que vos développeurs développent une nouvelle fonctionnalité
? Ne leur donnez pas de tâche à faire ! N'exprimez que votre besoin...

Imaginez un instant cette scène : vous re-voila chez votre
concessionnaire automobile, prêt à signer le chèque de votre nouvelle
voiture. A votre avis, des deux situations suivantes, laquelle est la
plus adaptée :


+   Situation 1 :
    > Client : "J'ai besoin de la voiture le mois prochain. Il vous faudra
    > donc passer commande auprès du constructeur. Pour cela vous disposez du
    > logiciel mis à disposition par ce dernier. Entrez vos codes d'accès,
    > puis saisissez la référence de la voiture, puis cliquez sur "Commander".
    > Dès que vous recevez la voiture, faites un bilan complet, puis
    > appelez-moi."

+   Situation 2 :
    > Client : "J'ai besoin de ma voiture le mois prochain, je sais que vous
    > ferez le maximum. Tenez moi simplement régulièrement informé de
    > l'avancée de la commande..."


Alors, à votre avis, quelle situation est la plus adaptée ? La deuxième
sans doute, non ? Examinons la Situation 1 : que se passe t-il si le
concessionnaire appelle directement le constructeur pour commander votre
voiture plutôt que de respecter les tâches qui lui sont assignées...

Quel en sera le résultat ?

+ Vous serez livré plus vite
+ **Les objectifs seront atteints**
+ **Pourtant le concessionnaire n'aura pas accompli les tâches demandées**

Je pense que vous avez compris : peu importe ce que va faire votre
concessionnaire, ce qui compte c'est d'être livré à temps. Pire, vous
risquez d'embrouiller le concessionnaire ou de le mettre sur des fausses
pistes. Avec une liste de tâches à suivre, le concessionnaire ne
pourrait pas prendre l'initiative d'appeler directement le constructeur
automobile. 


Et bien pour le développeur c'est pareil. **Exprimez votre besoin, les
délais souhaités, les modalités, mais ne lui dite pas comment réaliser
ce besoin**, vous risquez de le mettre sur de fausses pistes.


Attention, les listes de tâches sont utiles bien entendus, mais pas pour
communiquer. Vous pouvez avoir votre liste de tâches, les équipes de
développement vont peut-être (sans doute !) transformer votre besoin en
sous-tâches techniques... Mais en aucun cas vous n'avez besoin de
communiquer avec des tâches à faire. Le dialogue ne doit porter que sur
votre besoin métier.

> Communiquer en liste de tâches ne sert à rien, le dialogue ne doit
porter que sur le besoin métier.