342 lines
14 KiB
Markdown
342 lines
14 KiB
Markdown
# 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.
|