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.