Cyrille Martraire
Transcription
Donc le book club, c'est plein de gens qui se rencontrent et qui partagent un livre, qui lisent un chapitre par semaine et on en parle. Et au fil des discussions, une semaine, on a parlé avec les experts métiers, les interrogés, et à un moment donné, un collègue avait une surprise. Quoi? Tu veux dire que parler avec des experts métiers, c'est des compétences? C'est quelque chose qui se travaille? C'est quelque chose qu'on peut apprendre?
Cette surprise, c'est le point d'origine de ce talk. Et donc, juste après la pause, la coupure pub, vous allez découvrir comment devenir meilleur, à choper, à aller attraper le savoir métier de vos experts métiers.
Donc la coupure pub, qui je suis? Cyril, développeur encore depuis un certain temps, Cyril sur Twitter. Et on me connaît pas mal à Paris pour avoir créé la communauté Paris Software Craftmanship qui se réunit tous les mois. Avec les communautés de professionnels qui veulent être meilleurs dans leur code et être mieux travaillés, travailler en test-driven development, etc. Et mieux spécifier, mieux travailler aussi avec le métier. Je suis aussi cofondateur de la société Arola, où on est tous fans de tous les trucs en DD. Les TDD, BDD, Domain Driven Design, donc le dernier. Et on va parler un peu de celui-là aujourd'hui.
Voilà, donc retour de la pub. Félicitations, dans votre boulot, vous allez travailler avec des experts métiers. Et là, vous vous sentez... Ouais, bon, ouais, ok, il faut que j'y aille. Pourquoi c'est si difficile de travailler avec des experts métiers? Alors, j'ai posé la question dans différentes conférences, on m'a dit, on ne parle pas tous le même langage. Certes, c'est vrai. Et aussi l'autre réponse qui vient tout le temps, ils n'ont pas de temps pour nous. Alors il s'avère qu'apparemment, plus vous avez d'expertise dans quelque chose, moins vous avez de temps.
Vous avez vu ça aussi. Et donc, le temps des experts métiers, plus ils sont bons, plus, oui, l'OL sont bons, plus, moins, ils ont de temps pour vous. Ce qui veut dire qu'à chaque fois qu'on va passer du temps avec eux, on doit prendre soin de ne surtout pas gaspiller leur temps. Et ça, ça commence par ne pas y aller tout nu, aller les voir. Il faut y aller, et on ne va pas perdre son temps, on va déjà faire ses devoirs avant, et on va d'abord apprendre un petit peu soi-même le métier, autant qu'on peut, pour ne pas partir de zéro. Et pour faire ça, j'ai un petit secret les amis, ça commence avec la curiosité.
Mais la curiosité sincère, attention, ce n'est pas juste une curiosité superficielle. Sans curiosité pour le métier réel, ça ne va pas marcher.
Alors la curiosité, ça c'est le premier ingrédient secret. Ça veut dire que vous allez dans la finance, vous allez vous intéresser vraiment à apprendre un peu la finance. En fait, c'est super intéressant d'ailleurs. Vous allez dans l'assurance, vous allez apprendre un peu. La distribution aussi. Ensuite, le truc, c'est que mon cerveau est limité. J'ai besoin d'un peu de temps pour apprendre. Et donc, je vais commencer par faire mes devoirs, comme je le disais tout à l'heure, et je vais commencer par regarder tout ce qui est accessible aujourd'hui pour apprendre. Alors, il y a plein de bouquins, il y a les bouquins de référence, plein de trucs, on va les regarder rapidement. Dans chaque métier, il existe au moins une bible officielle de ce métier. C'est facile à savoir, vous prenez n'importe qui autour de vous, vous lui demandez comment ça s'appelle. et vous donne la Bible de votre métier. L'autre astuce, c'est qu'il existe des tonnes de dialectes XML depuis très longtemps, qui ont coûté très cher à standardiser et à faire des consensus dessus, comme Oasis par exemple, etc. Et ça, c'est des mines d'informations pour faire rapidement un scan d'un métier. De quoi ça parle? Par exemple, dans n'importe quel métier, il y en a des centaines. Vous voulez parler d'élections? Vous jetez un œil à l'élection Market Language. Et vous avez déjà tout de suite les concepts importants qui apparaissent dans ce métier. Les systèmes d'urgence, de crise, gestion de crise, vous avez des tonnes de trucs dessus aussi. Donc là, ne le prenez pas tel quel, juste regardez tous les noms qui apparaissent dedans. Alors attention, ça c'est très utile. C'est très utile pour avoir un overview de votre métier. Pour avoir des checklists de questions éventuelles à poser, pour avoir des corpus de vocabulaire ou de candidats vocabulaire, Par contre, ce ne sont surtout pas des solutions toutes faites à copier-coller. Surtout pas. Ce n'est pas non plus des feature lists et ce n'est surtout pas la vérité. Votre cas à vous est différent. C'est juste des inspirations. Avec tout cet overview, vous vous imprégnez du métier, et ensuite vous allez voir, hé, expert métier, tout d'abord, j'aimerais savoir comment fonctionne une police d'assurance. Et là, j'utilise un mot métier précis.
Et donc ensuite, la réponse, c'est OK, ça commence par blablabla, et là, on commence à parler sérieusement, puisqu'on rentre dans le vif du sujet, et vous intéressez vos interlocuteurs. Win.
Donc ça c'est un point, j'ai questionné, j'ai interrogé plusieurs leaders d'opinion bien connus, des grands noms du développement logiciel, ceux qui ont fait l'Agile, ceux qui ont signé le manifeste Agile par exemple, et à plusieurs reprises ils me confirment que c'est un truc dont on ne parle jamais. Pour bien réussir leur projet, à chaque fois, ils sont réellement curieux de leur métier, ils s'y mettent vraiment. Ce n'est pas juste le tech, c'est le tech et le métier. Mais ça, on n'en parle pas souvent parce qu'on a tous des métiers différents et donc ce n'est pas quelque chose qui fait consensus dans les conférences. A chaque fois, si je prends un exemple de finance, je vais perdre tous ceux qui ne sont pas dans la finance. C'est un peu le problème de notre profession. Alors l'autre point, c'est que mon cerveau, toujours, a des capacités limitées. J'ai besoin d'écrire pour me rappeler. Et donc, il s'ensuit que la façon de prendre des notes est super importante. Et donc, je vais développer une technique de prendre des notes comme un pro. Imaginons que je suis en train d'écouter en finance un expert métier qui me dit« The visitor requests an insurance quote.
Et je prends des notes, naïvement, comme ça. Vous voyez le problème? Ah! C'est pas du tout ce qu'il a dit. On a déjà perdu de l'info. On a déjà perdu des opportunités d'apprendre davantage de choses. Ce qui a vraiment été dit, c'est que ce n'est pas un user, c'est un visiteur. Il ne demandait pas, il requestait. Et ce n'était pas juste une côte, c'était... Une insurance quote. Vous voyez à quel point on a déjà déformé tout le message? On a déjà perdu tout le vocabulaire. Donc un point extrêmement important, et c'est au cœur de Domain Driven Design, c'est de faire très très très attention au langage et de respecter le langage. Ça veut dire que quand on va écouter des mots, on ne va pas juste choper le sens en gros, on va faire attention à quel mot précis, et pas un quasi-synonyme, quel mot précis a été dit, et c'est celui-là qu'on va essayer de noter. Et croyez-moi, en fait, c'est beaucoup plus dur que ça paraît. Testez-vous demain. Comparez vos notes, mémorisez, comparez avec votre mémoire auditive et vous verrez« Oh, oh, oh, oh, oh, j'ai pas écrit ce qui a été dit».
Ça demande de l'écoute active. L'écoute active, c'est quelque chose qui se travaille. En fait, c'est quelque chose que j'avais découvert aussi à Agile France avec une super présentation de Florent Chabanoy, qui en parlait beaucoup dessus. Il y a quelques années. Donc c'est dur, mais vous pouvez le transformer en un jeu. Comme ça, c'est un coup, c'est plus fun, que j'appelle le Safari Demo.
À chaque fois que vous entendez un mot nouveau, vous le soulignez. Vous entendez une phrase comme ça, vous n'avez pas besoin de comprendre ce que ça dit. Je donne des exemples de finances, mais vous n'avez pas besoin de comprendre la finance pour comprendre ce que j'essaye de passer comme message. Deal. Oh, un nouveau mot, je souligne. Et puis à la prochaine occasion où je peux parler, quand on me rend la parole, could you define deal? C'est quoi le deal?
Et là, on apprend des choses. Alors on continue dans la discussion, et donc le trade est booké dans un certain portfolio. Donc je prends des notes.
Et là, je me dis, mais trade et deal, pour moi, c'est pareil.
C'est des synonymes.
Et ça, c'est un point important à repérer. Tous les synonymes, c'est des signaux importants pour des questions qui servent à creuser. Donc, je vais le faire avec des questions du style, vous parlez de deal et trade comme si c'était la même chose, est-ce que c'est vraiment la même chose ou est-ce qu'il y a une différence? Est-ce qu'il y a une différence? Ça, c'est une question clé. À chaque fois que je mets une petite clé ici, ça veut dire que c'est une question clé. C'est incroyable, c'est une petite astuce.
Un petit code. Et donc là, on commence avec ce genre de questions aussi, on creuse, on rentre vraiment très vite, on va creuser très vite. Le vocabulaire, c'est super important. C'est la porte d'entrée, c'est le sésame pour creuser le métier de façon importante. Alors vous allez me dire à ce point, mais tout ça, c'est juste des astuces, des petits trucs. Eh bien non, c'est super important.
C'est tellement important que Domain Driven Design parle énormément de ça, et c'est tellement important que Eric Evans, le créateur de Domain Driven Design, il a nommé sa société Domain Language. Le langage, c'est la base de tout ce qu'on fait ici, et dans le code, on va retrouver ce langage, bien sûr. On veut retrouver ce langage. Ok, continuons un petit peu. Donc on a des phrases encore comme ça, après l'exécution, je vais réduire la quantité de ce qui reste par ce qui a déjà été exécuté, etc. Oh, un nouveau mot!
Et alors là, je vais répondre par-dessus. Vous parlez de... De ordre et d'exécution.
Je sais déjà qu'un ordre, c'est comme une intention de traiter, mais c'est quoi l'exécution? Alors là, ce que j'ai envie de vous montrer, c'est que je vais commencer ma phrase par« je sais déjà que». Et qu'est-ce que je fais? Pourquoi je fais ça? À quoi ça sert, ce truc? Ça sert à montrer de l'intérêt, montrer ma curiosité, montrer de l'intérêt afin de créer de la crédibilité pour moi-même. Quand on est face à un expert métier qui maîtrise bien son métier, quand on est développeur ou quand on est dans l'équipe de développement en général, on n'est pas toujours très crédible en matière de compréhension du métier. De toute façon, vous n'êtes que des techs. Je ne comprenais rien de truc. Et donc tous les signes de crédibilité que je peux créer, j'en profite pour me mettre en interlocuteur valable face à eux. Le but est qu'ils m'accordent plus de temps à l'avenir. C'est un investissement, créer une relation constructive dans les deux sens.
Un peu d'égal à égal. Bien sûr, on ne va pas être à leur niveau, mais on fait tout pour établir notre crédibilité. Et donc, j'ai plusieurs façons de le faire. Montrer ma curiosité, la mettre en avant, améliorer mes questions au fur et à mesure de ce que j'apprends, et puis challenger.
Challenger, ça veut dire que je ne vais pas tout prendre pour argent comptant. Je vais oser. Poser des questions qui peuvent mettre en évidence des contradictions apparentes dans ce qu'on me donne, dans ce qu'on me dit. Tout ça avec respect, mais surtout pas comme « oui, oui, tu as toujours raison, je t'écoute et je note tout comme parole d'évangile ».
Voilà, donc à ce point, on est en train de faire nos conversations, etc. Et comme on l'a évoqué depuis le début, parler avec les gens, c'est difficile.
Heureusement, il existe un antidote. L'antidote, c'est que les conversations, c'est interactif.
Interactif, ça veut dire quoi? Ça veut dire que vous avez le contrôle, pour au moins la moitié, de ce qui se passe. Ça veut dire que vous pouvez prendre le volant et décider d'emmener la conversation aussi là où ça vous arrange, là où vous pensez qu'il y a quelque chose d'intéressant à faire.
Je bouse beaucoup pour la caméra.
Donc bien sûr, on ne va pas interrompre la conversation brutalement. Ça veut dire qu'on va devoir garder nos questions pour plus tard. Et c'est là encore où la façon de prendre des notes comme un pro redevient indispensable. Donc on a déjà vu que tous les nouveaux mots, je les souligne, ma petite notation perso, vous pouvez avoir la vôtre, mais j'ai d'autres signes, une sorte de sténopersonnel. Un truc qui n'est pas clair, ce truc-là, c'est à préciser plus tard, parce que ce mot particulier, de toute façon, ce n'est pas clair comme mot. Et puis toutes mes remarques à moi, je les mets entre crochets pour bien les différencier, que c'était ma pensée à moi et que ce n'est surtout pas une vérité qui a été donnée, ce n'est pas quelque chose qui a été approuvé par mon interlocuteur. Et bien sûr, toutes les questions qui me passent aussi. Question à poser bientôt. Ce qui veut dire qu'à la prochaine occasion, je vais jeter un oeil dessus et sélectionner ce qui m'intéresse comme question suivante. D'autres ont des techniques plus poussées. Par exemple, dans la communauté des testeurs pro, et là je vous invite aussi à jeter un oeil à leur travail, James Bach et Katrina Tester, des éminences en matière de testing agile pro, ils ont des techniques de man mapping assez efficaces qui permettent d'aller explorer très vite différentes facettes d'un métier, dans le but de le tester, mais c'est tout aussi utile. Dans un but de découvrir pour spécifier. En fait, c'est exactement la même chose, c'est la même activité.
Et donc, en naviguant vos notes, peu importe la forme, texte, mind map, on scanne et puis on dit, le plus important pour moi tout de suite, je priorise mes questions. La prochaine question la plus importante, c'est celle-là. Et donc, on est en train de naviguer la conversation. Comme on navigue une carte, en faisant comme ça.
Donc imaginons une carte plutôt jolie, bon elles sont rarement aussi jolies que ça les miennes, mais parmi tout mon bazar de prise de notes, j'ai différents concepts qui apparaissent. Là on a des factures, des factures imprimées en PDF et des factures électroniques. Et puis il y a la relance pour les factures, et puis la notion de partenaire, des factures avec des partenaires.
On voit plusieurs directions sur cette carte. Il y a de haut en bas, de bas en haut et de gauche à droite. Commençons dans le sens vertical. Ici, verticalement, j'ai une sémantique, une représentation d'intention. Plus je monte, plus je vais vers le pourquoi des choses. Et le pourquoi, vous savez bien que c'est une question clé. Ça, je ne vous apprends rien. Vous connaissez déjà ça par cœur et même les cinq pourquoi. Mais pour l'illustrer quand même, petite anecdote, imaginons qu'on vous dise qu'il me faut un bouton pour un... Vous faites pourquoi ? Votre interlocuteur demande« je vais vérifier avec les utilisateurs». Ça, c'est déjà un signe sans doute que vous n'avez pas un vrai PO d'ailleurs. Vous n'avez pas un vrai expert métier, mais plutôt un rôle proxy, puisqu'il doit aller vérifier ailleurs. Alors ensuite, cette personne revient et nous dit« c'est parce qu'ils ont besoin de passer cette impression au département d'à côté». Est-ce que c'est une bonne réponse? Bien sûr que non. Encore un pourquoi. Pourquoi?
Ils reviennent. Ah, parce qu'ils ont besoin de saisir les infos dans le route système. Waouh! What the fuck?
On peut faire mieux que ça!
Bien sûr, on va faire de l'intégration plutôt. On va complètement rechanger, reconsidérer le besoin. Donc on peut gagner du temps dans ce genre de démarche en demandant dès le départ, dès la première rencontre, c'est quoi le but? Là, on va gagner du temps. Par contre, si on est déjà en plein dans un process qui est déjà là, il va falloir travailler à l'envers, c'est-à-dire essayer, avec les questions de pourquoi et toutes sortes d'astuces, essayer de retrouver, de reverse engineer le vrai pourquoi.
De la solution qu'on vous a donnée comme étant soi-disant un besoin. C'est toujours comme ça, on vous donne des solutions, mais c'est votre boulot. Il ne faut pas arrêter de critiquer tout le monde, c'est comme ça que ça marche. Il faut accepter qu'on nous donne des solutions, on nous demande des solutions, et on doit retrouver le vrai problème à partir de ces solutions. C'est notre boulot de l'équipe de développement. Donc toujours, poser des questions. Et donc, je ne sais pas si vous voyez ici, c'est marqué« Question everything». Et ce que je trouve génial, c'est la réponse du petit vandal qui a ajouté« Pourquoi?
Alors évidemment, si on va trop loin dans cette approche, on risque ce genre de remarques.
C'est vrai. C'est vrai, on peut se perdre dans les pourquoi juste pour procrastiner et se faire plaisir à jouer l'intéressant, à chercher à comprendre tout, tout jusqu'à l'univers. Bon, il ne faut pas non plus abuser trop loin. Mais c'est quand même une question puissante. Voilà, dans l'autre sens, je vais chercher du concret. Et vous savez comme moi que quand on fait de l'agile, on a besoin de your story, on a besoin de scénarios concrets et on va implémenter à partir d'exemples concrets, surtout si on fait du TDD et du BDD. La phrase clé pour du concret, c'est un exemple en anglais. Un example would be handy right about now. C'est les exemples de Brian Marik. Encore, c'est Brian Marik, c'est un testeur qui avait signé le manifeste Agile et qui distribuait ses autocollants. Il en avait toujours sur la table. Et régulièrement, dans les conversations, il sort sa carte et il me faut un exemple concret, les gars.
Alors, dans la vraie vie, quand on est en entreprise, on est plus délicat. Et une façon douce de le tourner, question clé, c'est, ok, je pense qu'on est d'accord, on est tous d'accord, on a parlé pendant toute la réunion, on est d'accord, mais juste pour être 100% sûr, ultra sûr, juste au cas où il y aura encore un petit loup caché quelque part, est-ce qu'on ne pourrait pas avoir un exemple concret quand même?
Alors là, vous reconnaissez la discipline de BDD, Behavior Driven Development, qui consiste à faire juste ça, à chercher des exemples concrets, parce qu'on sait très bien que le diable est dans le détail, et c'est dans ces exemples concrets qu'on va trouver tous les problèmes. Et en fait, on a beau être tous d'accord, on ne l'est pas bien sûr, quand on va chercher dans les détails, on va trouver des tas de sources de désagréments.
Vous connaissez ça, vous avez déjà vu.
Donc évidemment, BDD va bien avec, et en plus il y a tout le formalisme qui va bien, mais ça c'est optionnel. En général, quand on a des exemples concrets, on peut les structurer comme ça, vous les mettez après dans Cucumber ou Specflow, mais ça c'est secondaire. Le véritable bénéfice, c'est d'avoir des exemples concrets sur lesquels trouver, identifier que finalement on n'est pas d'accord. Tout ça nous permet de découvrir les inconnus et les inconnus inconnus, les inconnus qu'on n'imagine même pas, qu'on ne les sait pas.
malentendu le plus tôt possible, qui fait qu'on progresse plus vite et qu'on gagne du temps.
Ce que j'observe au quotidien, dans tous les environnements, c'est que demander des exemples concrets, c'est difficile. A chaque fois, on va vous dire« Ouais, mais c'est trop lent, on n'a pas le temps. » Ça va plus vite de rester au niveau des formules, au niveau des généralités, au niveau des propriétés. Je veux que le système imprime un rapport quand on arrive à la fin de la journée. Aller jusqu'à dire c'est à quelle heure la fin de la journée, le PDF comment il est structuré, etc. Ça, ça a l'air d'une perte de temps. Ça a l'air de détails sans intérêt. Pourtant, est-ce qu'on gagne vraiment du temps si en fait on s'est mal compris et qu'on va devoir corriger derrière, revenir, faire du rework, réouvrir des tickets? Ça ne va vraiment pas plus vite. Ensuite, quand vous demandez des exemples de documents, ça c'est super utile, à chaque fois qu'il y a un contrat quelque part, un PDF, et il y en a quand même régulièrement, ou un XML envoyé à un partenaire, demandez des exemples concrets de ces documents et regardez-les vous-même. Alors évidemment, c'est souvent difficile à parser pour un humain, c'est du langage d'avocat, mais vous le lisez, etc. Et là, vous découvrez un terme. C'est quoi ce truc?
Ah oui, on n'en a pas parlé encore.
Ah ouais, d'accord.
Super important. Et ça encore, je vois régulièrement qu'on ne nous les donne pas. Et on insiste, on insiste, on insiste. Alors il y a des questions de confidentialité, certes. Souvent de noms, vous avez des vrais noms, des vraies parties. Donc dans le passé, j'ai eu la chance, quand même que quelqu'un en a force d'insister, on nous en donne qui sont avec des grandes barres en noir dessus, ou juste en papier, on ne vous les donne pas mais on vous les montre sur une table,
mais ça vaut vraiment la peine de les regarder, et c'est pour ça que vous avez besoin d'un peu d'un vernis métier, même d'un vernis un peu approfondi métier, parce que pour arriver même ne serait-ce qu'à avoir une idée de quoi ça parle et de regarder un peu dans le détail, Si vous ne connaissez vraiment rien au métier, ce sera réellement inutile. Si vous connaissez un peu le métier, vous allez pouvoir découvrir qu'il y a un concept oublié dans tout ça, ou un concept mal compris.
Entre parenthèses, ça vous fait des cas de test gratuits, ce genre de document. Il est tout prêt pour transformer dans vos formalismes préférés pour vos outils de BDD.
Enfin, il reste une direction, l'approche, la direction de côté.
Et ça, concrètement, c'est dans une conversation, vous parlez d'un certain truc, vous parlez d'un panier d'achat, blablabla, blablabla, blablabla, and by the way, ce n'est pas le cas sur la marketplace. Vous prenez des notes. Marketplace.
On était question de fabriquer un système de commande avec un panier d'achat, mais la marketplace, c'est quoi ce truc? C'est juste une remarque en passant, et le risque est de la laisser passer. Mais il s'avère qu'en fait, quand on va creuser, on va découvrir qu'en fait, le projet de shopping cart, c'était la partie visible, mais qu'en fait, il y aura aussi à considérer toute la marketplace et que c'est la plus grosse partie.
Oups!
Ok, donc jusqu'à présent, je vous ai un peu bullshité, parce que jusqu'à maintenant, on a parlé extrêmement positif. C'est-à-dire, mais Cyril, toi, tu n'as vraiment pas la même vie que nous. Toi, tu as des experts métiers qui ont l'air super. Ce n'est pas ce que vous avez. C'est vrai que dans la vraie vie, il y a ce phénomène de l'expert métier idéal.
Et c'est vrai que vous imaginez ça, et en fait vous avez plutôt ça, comme expert métier. En plus, c'est impossible de les reconnaître, franchement, c'est pas écrit dessus, je suis un bon expert métier ou je suis un mauvais expert métier.
Et puis d'ailleurs, les experts métiers, même dans leur métier, ils sont pas tous super bons.
Il y en a quand même qui se plantent.
Par contre, il y a quand même quelques petites astuces. Par exemple, les pires experts métiers, ça, ça se découvre assez vite, c'est ceux dont l'expertise, soi-disant métier, n'est que l'expertise des systèmes historiques sur lesquels ils ont passé plusieurs années. En fait, c'est une expertise d'application qu'ils ont, ce n'est pas une expertise de métier. Alors ça, c'est le risque le plus gros que vous avez, c'est de vous planter avec un pseudo-expert métier qui connaît par cœur l'application qui a toujours été, et vous ne ferez jamais de progrès parce que l'avenir sera toujours décrit dans les mêmes termes et la même façon de penser que la vieille application qui a toujours été comme ça. Ça, c'est le poison absolu.
A l'inverse, pour reconnaître un expert métier crédible,
Là, c'est quelqu'un qui a vécu, et qui a vécu même dans sa chair, d'avoir perdu des sous, par exemple.
J'ai fait une erreur une année. Oh là là, qu'est-ce qu'on a perdu à cause de ça? Je me rappelle encore. On fait des cauchemars. Bon, ça peut marcher aussi en positif. On a fait une super décision et ça a plein gagné de sous. Donc c'est vrai que je traîne beaucoup trop en finance, donc c'est des exemples un peu extrêmes, mais c'est vraiment avoir des choses, il faut avoir des histoires de guerre. Quelqu'un qui a vraiment vécu son truc, et donc ça peut être un billet qui vient, qui a été avant trader, qui a été avant quant, qui a un passé d'être dans le métier lui-même. Ça c'est un excellent exemple, c'est les meilleurs exemples que je connais en fait, c'est ce genre d'exemple. Ou un PDG ou un manager qui a un passé dans le métier lui-même.
Mais quand on n'a pas ça, ou même quand on l'a d'ailleurs, mais surtout quand ton interlocuteur finalement il ou elle n'est pas si bon que ça, on peut aider. Et c'est quelque chose qui est normal. C'est quelque chose qui est normal. Je veux dire, ce n'est pas juste du work around.
Je pense que c'est vraiment notre boulot de se dire, c'est normal que je doive aider mon interlocuteur expert métier à mieux me raconter ce que je dois apprendre. Et donc évidemment cette compétence c'est la fameuse empathie. Mais empathie ça veut dire quoi? Ça veut dire se mettre à la place des autres, se mettre à la place de l'autre en face, se mettre dans l'autre. dans ce qu'ils ressentent. Mais en général, on pense ça, se mettre à la place de l'autre, on pense ça figurativement. Je mets à la place juste en termes d'émotion. Ce que je vous propose, c'est d'aller un cran plus loin et de le faire même littéralement.
Surtout pas, on ne va surtout pas se mettre dans la posture expert métier, explique-moi tout ce que je dois savoir. Non, ça non, surtout pas. Ce qu'on veut, c'est un partenariat dans les deux sens. Vous vous rappelez de Challenger Respectfully, j'écrivais, on va essayer d'avoir une relation d'égal à égal, ou surtout pas une relation de supérieur et de subalterne, Et donc on va essayer de proposer aussi des choses, on va essayer d'avoir des conversations où je propose autant qu'on me propose. Je ne sais pas si vous connaissez ce gars, certains d'entre vous le connaissent forcément, c'est Ward Cunningham qui a inventé le wiki, les CRC cards, et avec Ken Beck, l'extreme programming. Et qui est encore en train de bosser sur les Federated Wiki, et puis encore d'autres trucs. Ils ont vraiment fait... Et les patterns aussi, oui, j'ai oublié. Enfin, trois fois rien dans notre métier, quoi. Donc ce monsieur qui est extrêmement intéressant, au peu de demeurant, il avait écrit il y a longtemps,
Ce super mème, je l'adore, cette super phrase. Le meilleur moyen de poser une question sur Internet, c'est d'avoir la réponse. Ce n'est pas de poser la question, c'est de poster une fausse réponse. Et ensuite, vous laissez Internet vous corriger.
Donc ça marche très bien sur Internet.
Ça marche aussi très bien dans les conversations. Propose quelque chose, proposez n'importe quoi, comme une tactique. Alors donc, en fait, un ordre, si j'ai bien compris, c'est une façon de... C'est ce qu'on reçoit quand on a vendu quelque chose. C'est pas du tout ça. Proposer quelque chose, alors faites de votre mieux quand même, parce que votre crédibilité, encore, là, vous jouez un petit peu avec, mais c'est pas très grave. Faites juste de votre mieux et c'est absolument pas grave si vous êtes à côté de la plaque, si c'est faux ou si c'est incomplet. Parce qu'un expert métier, quel qu'il soit, se fera un plaisir de vous corriger.
Ça, c'est génial. Justement, on va utiliser la propension naturelle de tout le monde à mettre en évidence ce qu'ils savent plus que vous pour dynamiser un peu l'échange.
Ça, ça marche super bien.
Je ne suis pas le seul à dire ça, en fait. Si vous connaissez Lyskeo, elle en parle aussi régulièrement dans ses articles. Et donc, par exemple, on va dire, étant donné, je commence tout le travail, et vous laissez l'autre finir, finalement. Vous amenez votre interlocuteur à terminer la phrase. Ah oui, donc en fait, dans ce cas-là, la livraison est gratuite. Et vous n'avez plus qu'à tourner ça en exemple, à prendre des notes, et vous avez le truc complet.
Voilà, donc ce n'est pas automatique et ce n'est pas si facile. Donc quand on fait toutes ces conversations, on les fait dans des sessions de conversation qui peuvent être une demi-heure par jour, une heure par semaine, deux heures par semaine, parfois moins. Mais quand ça marche bien, il faut une certaine régularité. C'est quand même sympa. Mais quand c'est fini, l'interview est finie pour aujourd'hui. Et donc maintenant, si on a de la chance, on se reverra demain.
Et maintenant, qu'est-ce qu'on va faire?
L'équipe de développement va travailler. On va prendre ce qu'on a compris, on va le mettre dans du code. N'ayez pas peur, on est à l'Incamban, mais je vais montrer trois lignes de code. Donc imaginez que votre métier, c'est le métier des petits chats qui chantent.
Je suis sûr que ça existe quelque part, au Japon par exemple, ça doit exister ça. Les petits chats qui chantent. Donc ce métier, de quoi il parle ce métier? On le voit sur l'image. Ça parle de micro, ça parle de casque, ça parle d'une attitude de rockstar. Pour chacun de ces concepts, on va les retrouver dans le code littéralement, sous forme de classe, méthode, interface, enum.
Les artefacts classiques de code. Donc vous avez un kitten avec un microphone et on chante dans le micro. Et ensuite il y a la notion de playback aussi. Il n'y a pas que des noms, il y a aussi des verbes, des actions, des choses qui se passent. Et puis bien sûr l'attitude de rockstar. Et ça c'est du code. Donc c'est du code ici qu'on lit comme un texte. Mais prendre des notes en code, c'est du code qui tourne, qui s'exécute quand vous le lancez. Vous devez avoir un texte qui s'affiche, ou si vous le branchez sur un système de synthèse vocale, vous devez avoir« miaou miaou miaou» quand vous lancez ce code. Ça doit faire quelque chose, ça doit se comporter. Et c'est là où le code va vous aider à spécifier. On va dire que c'est comme un bloc-notes, c'est du code jetable, on va dire qu'il est jetable. Mais c'est du code qui va aider à comprendre. Et qui va devenir une extension.
Une fois que vous prenez vos idées, même très grossières, c'est très utile dans un POC initial par exemple, ce genre de choses, vous mettez ces idées initiales dans un petit bout de code, vous lancez votre code, et oups, ça ne fait pas ce que j'attendais. Alors qu'est-ce qui manque? Ah ouais, il manque un concept. Imaginez par exemple que vous codez un système de protection. J'ai un exemple concret sur les crédits de défaut de swap. C'est un peu comme de l'assurance. Vous le jouez avec et vous dites qu'il y a un défaut, donc l'assurance doit intervenir.
Mais ensuite, vous continuez de payer l'abonnement, de payer la protection. Et le crédit de swap, ce n'est pas comme ça qu'il marche. Vous vous dites, mais pourquoi il continue? Ah ouais, j'ai oublié le critère de termination. Il manque un concept. Dès le lendemain, je retourne voir l'expert métier, je lui dis, il y a un truc qui manque, il y a un critère de termination, on peut en parler un peu davantage. C'est le code qui m'a montré la solution. Alors vous pouvez le faire à la main aussi, vous pouvez jouer à la main, exécuter votre compréhension à la main, mais c'est pénible et en fait vous ne le ferez pas. Avec le code c'est beaucoup mieux. Et donc le code et les problèmes que vous rencontrez en essayant de le faire marcher, même à toute petite échelle, on parle de petits modèles simples, vont générer des questions qui vont vous permettre de poser de meilleures questions la prochaine fois, et donc de gagner des points aussi en crédibilité, et d'amorcer comme ça une boucle vertueuse de conversation et de collaboration. Bien sûr, parler, interviewer les experts métiers, c'est une boucle dont la plus grande partie, vous n'êtes pas avec l'expert métier, bien sûr.
Donc l'idée, c'est d'être efficace ici pour... pour avoir du boulot intéressant ensuite. Par exemple, sur un POC, une demi-heure par jour ici, le reste de la journée là, c'est très bien. Tout ça, tous les jours. Ce serait l'idéal. Si on pouvait vraiment faire ça, avoir autant accès à des experts métiers, quand on peut avoir autant d'experts à des experts métiers, c'est vraiment le top.
Et comme mon cerveau est toujours limité, il me faut du temps pour faire maturer tout ça, on ne va pas aller trop vite, on va se laisser quelques deux semaines par exemple sur le POC, et puis on continuera même après quand on va vraiment développer un truc livrable. Et au fil du temps, on itère sur tout ça et on gagne en profondeur et en pertinence de compréhension. C'est un phénomène que Eric Evans appelle le« wire pool» de Domain Rewind Design, la spirale.
Alors pourquoi on s'embête avec tout ça au fait ? C'est vrai, après tout, on pourrait juste coder, puis voir après ce que ça donne. Et pourquoi pas? Si votre langage va très très vite à faire, je vous encourage à le faire. Si votre langage est plus compliqué, si vous avez du legacy, si vous avez d'autres problèmes, Ça vaut la peine quand même de découvrir très tôt, avant même d'aller très loin dans le code, tous les problèmes. Parce que la complexité, elle est là, quoi qu'il en soit. La complexité du métier, elle est cachée derrière. Vous ne la voyez pas.
Et si elle reviendra de toute façon, vous pouvez l'ignorer, mais elle reviendra vous mordre un jour ou l'autre. Donc le but de tout ça... c'est de la découvrir plus tôt, c'est de trouver l'échelle qui va permettre de voir ce qu'il y a derrière, pour gagner du temps et éviter du retravail. Alors du retravail, de toute façon, il y en aura quand même, mais on va essayer de le minimiser un petit peu, si tout ça n'est pas cher.
Entre parenthèses, ici, l'échelle, ce n'était pas la meilleure idée, parce qu'on peut aussi passer sur le côté. Bien sûr. Bon, et tout ça, on gagne. Alors à ce point, maintenant je vais vous faire bosser un petit peu.
Vous êtes tous experts métiers de quelque chose. Et vous êtes tous experts métiers forcément de quelque chose qui s'appelle les pantalons. Vous avez tous porté des pantalons pendant des années.
Non, personne. Vous connaissez tous les pantalons, n'est-ce pas?
Et donc, on va se donner trois minutes, peut-être même pas, peut-être même deux. Deux minutes, et je vais vous demander, donc vous êtes des experts métiers en pantalons, Et je vais vous demander, par deux, par petits groupes, de donner une définition très claire de ce que c'est qu'un pantalon. C'est quoi des pantalons? Une définition. Vous connaissez les pantalons. Vous devez être capable de donner une définition d'un pantalon, n'est-ce pas? Et je démarre le chrono. Alors, je ne vous demanderai pas la restitution. Donc, n'ayez pas peur. Allez-y. Mais quand même, ayez votre définition en tête. C'est parti pour deux minutes.
C'est facile ?
C'est là qu'on va faire des millions.
Ah.
Vous faites rien là-bas? C'est bon, c'est fait?
7, 6, 5,
Voilà. Donc, comment c'était? C'était facile?
C'était... Vous faites moins les malins maintenant? C'était facile? Pas tant que ça. Qu'est-ce qui se passe en fait? Vous ne connaissez pas les pantalons? En fait, je pense que ce qui se passe, c'est que vous êtes vraiment dans le rôle d'un expert métier, ici tout de suite, sur les pantalons. C'est quelque chose que vous connaissez vraiment. Le problème, c'est que c'est un savoir qui est... Tacite.
Vous le savez. Par contre, pour l'expliquer, pour l'exprimer, pour le mettre en forme, c'est vraiment plus difficile. Mais vous le savez, vous savez tout. Et donc cette difficulté, c'est une difficulté classique d'expert métier, c'est que je sais, mais je ne sais pas l'expliquer. C'est inconscient. Parfois, c'est tellement internalisé que je ne sais même pas pourquoi je pense comme ça. Et ça par contre, sortir tout ça, formaliser, c'est des choses que l'équipe de développement sait faire, c'est son métier, on est des professionnels de ça.
Une des façons d'aider à sortir tout ça aussi, c'est de challenger, de faire des expériences de pensée. Par exemple, qu'est-ce qui se passerait si je changeais quelque chose? Et comme ça, on va générer des nouveaux exemples. Donc ça a l'air très abstrait. Regardons ça tout de suite. Essayons des nouveaux exemples. Est-ce que votre définition de pantalon permettrait de répondre à cette question?
Vous n'avez sans doute pas vu passer ce débat sur Internet, sur Twitter, il y a quelques mois. Est-ce que votre définition de pantalon permet de répondre à cette question?
Non? Si?
Il y en a? Ça peut un peu? Alors bon, il y a eu des débats, des débats, des débats, des débats, des débats. C'est quoi la bonne réponse? Et puis un jour, à un moment donné, quand même, quelqu'un a trouvé la réponse. Il y a une fille, elle a répondu, mais vous êtes tous des idiots. En fait, évidemment, c'est pour couvrir les fesses.
Le problème, c'est que... Ah non, trouvez un contre-exemple.
Alors, ou bien on garde cet exemple et ça ne marche pas, ou bien on dit que cet exemple, en fait, c'est un mauvais exemple et ça marche. Mais même si c'était vraiment pour couvrir les fesses, on va corriger notre petite question. Et est-ce que maintenant, votre définition permet de répondre à cette question, une fois après avoir corrigé cette histoire de couvrir les fesses?
Est-ce qu'il y en a un pour lequel la définition couvre répond à ça? Oui, un peu.
Et elle permettrait de répondre à ça aussi?
Alors, il y a une autre... Oui, parce qu'ils n'ont pas de fesses, en fait. Alors, en fait, ensuite, il y a un autre mec qui avait trouvé la réponse aussi. Vous êtes aussi des idiots, en fait. Bien sûr, c'est pour couvrir les jambes. Bien sûr. Il y en a qui avaient cette réponse? Oui, quand même.
Bon alors si on n'a pas de jambes aussi, ça marche? Non, ça ne marche pas.
Et puis d'ailleurs, si c'était vraiment pour couvrir les jambes, est-ce que ça permettrait de répondre à ce problème-là?
Avec des mille pattes.
Est-ce que votre définition permet de trancher sur ce genre de débat? C'est quoi les pattes? C'est quoi les jambes pour un animal avec un nombre N de jambes? C'est le genre de situation qu'on a souvent, ça, les combien de situations. Et donc finalement, là, on n'a fait que reporter le problème de définition sur la définition de jambes. La définition de pantalon, maintenant, a besoin d'une définition de jambe, qu'on n'est pas sorti d'affaire, en fait. Mais ce que j'ai envie de mettre en avant avec cet exemple idiot, c'est que la puissance d'une définition, c'est sa capacité à fonctionner dans différents cas. Et plus elle va gérer de cas, plus vous avez une définition puissante. Bien sûr, si ça se paye par une définition compliquée, ce ne sera peut-être pas forcément une bonne idée. C'est à vous de doser. Et vous remplacez définition ici par modélisation.
Et vous êtes directement en termes de design, dans le territoire du design, parce que spécifier, c'est déjà modéliser, c'est déjà prendre partie sur une vision du monde qui finira dans votre logiciel.
Et entre parenthèses, je n'ai pas la solution ici.
Alors, Cyril, est-ce que tu as d'autres techniques? Secrètes ou pas secrètes? En fait, oui, il y en a plein. J'ai dû même en virer beaucoup pour que ça tienne dans ce talk.
Donc, gars... Et une des techniques évidentes, bien sûr, c'est de garder votre boîte à outils mentale aussi à vous. Et ma boîte à outils mentale, elle commence par des bons livres. Alors, il y a un très bon livre ici, bien sûr, Domaine Driven Design, d'Eric Evans. Mais en fait, ce dont on ne parle pas beaucoup, c'est qu'il y avait aussi le bouquin de Martin Fowler, qui était avant, et qui est déjà un bouquin de Domaine Driven Design. C'est un bouquin de pattern d'analyse. C'est-à-dire, Martin Fowler s'est aperçu, en travaillant dans le système de santé, puis dans la compta, qu'en fait, il y a des tonnes de parallèles entre tous ces métiers, et on retrouve les mêmes situations, des petits bouts de situations, qui se répètent un peu partout. Et ces petits bouts de situations, si on les travaille bien, une fois qu'on a trouvé des solutions intelligentes pour un, On peut les réutiliser pour d'autres. C'est toute l'idée de pattern. Mais là, on n'est pas sur des patterns de code. On est sur des patterns, bien sûr, ils nous traitent aussi comment les mettre en code. Mais on est sur des patterns comme gérer la temporalité des choses, des choses qui sont valables entre deux dates, puis qui deviennent différentes entre deux autres dates. Et toutes les façons de représenter ou de réfléchir à ça. Comment gérer les systèmes où on ne fait qu'ajouter des informations et puis on consolide après. Des mesures, des observations, des phénomènes, des quantités, tout ça. Donc ça, c'est un investissement important. Et en fait, ce genre d'outils mentaux, dans votre boîte à outils mentaux, c'est ultra puissant. Puisqu'après, dans une conversation, vous dites, ce truc-là, ça me rappelle vraiment ce pattern. Et après, vous creusez un peu pour vérifier tout de suite si ça colle ou pas. Et si ça colle, vous avez cadré le problème. Vous avez déjà une compréhension prête à l'emploi qui vient de votre boîte à outils mentale. La boîte à outils mentale contient aussi des maths. Bien sûr, je suis grand fan des monoïdes. Et donc, je ne vais surtout pas parler de monoïdes avec mon interlocuteur. Je ne vais pas faire peur, comme ça, quand même. Vous n'avez pas besoin de savoir ce que c'est qu'un monoïde. Mais je vais vous donner tout de suite un exemple. Je vais tenter de tester si j'ai un monoïde devant moi. J'ai des réservations d'hôtels. Et j'en ai une du 26 au 27 et une autre du 27 au 28, est-ce que je pourrais dire que si pour le même client j'en ai deux, alors est-ce que je pourrais dire que c'est équivalent à en avoir une seule du 26 au 29?
Peut-être que oui, peut-être que non. Si c'est oui, alors j'ai le comportement d'une arithmétique de concept. J'aurais, mathématiquement, c'est ce qu'on appellerait un monoïde, mais vous n'avez pas besoin de parler de monoïde. Pour détecter ça. Donc bien sûr, les expériences passées, plus vous avez d'expériences passées, plus vous reconnaissez des petites situations que vous pouvez reconnaître et réutiliser direct. C'est encore une fois quelque chose que l'ISKEO décrit aussi dans ses articles, comme par exemple des patterns de compta qu'on retrouve dans des endroits qui n'ont rien à voir avec la compta,
Un exemple que vous connaissez certainement, c'est la concentration des pouvoirs. Quasiment tous les métiers n'aiment pas qu'une personne puisse devenir dictateur complet. Et on va séparer les pouvoirs importants pour qu'il y ait toujours au moins deux personnes qui se partagent la totalité des pouvoirs. Et donc, une fois que vous l'avez compris, vous l'avez compris dans un certain métier, vous arrivez dans un autre et vous découvrez. Vous êtes un peu surpris. Je m'attendais quand même à ce qu'il y ait une ségrégation des duties, des pouvoirs ici. Ça n'a pas l'air d'être le cas. Vous proposez, c'est aussi un moyen de gagner. Justement, dans une conversation, là, vous marquez des points quand vous sortez ça, parce qu'en général, ce sera vrai. Oui, c'était une erreur. Il n'est pas prévu que tout le monde ait tous les pouvoirs pour faire des choses qui coûtent des sous, dépenser de l'argent, mettre en risque la société.
Un autre exemple que vous avez sans doute repéré aussi, c'est que la plupart des business n'aiment pas effacer de l'information de façon destructive. On efface logiquement, on n'efface pas physiquement. Et donc si on vous demande d'effacer, et que Aspect parle d'effacer, n'hésitez pas à challenger ça aussi. Est-ce qu'on voulait vraiment effacer? Ah non, non, non, en fait, bien sûr. On va le faire à façon comptable, on ajoute une entrée qui remplace la précédente. Donc c'est des exemples de votre boîte à outils, de réutiliser votre boîte à outils pour converger plus vite et proposer et participer plus activement aux conversations. Avec tout ça, on a des découvertes plus rapides. Et une dernière astuce, c'est tout ce qui est invariant. Et là, la question clé, la question magique, c'est, elle est donnée par l'ISKEO, est-ce qu'il y aurait une autre outcome qui serait importante? Est-ce qu'il y aurait un autre résultat, un autre comportement qui serait important? Moi, j'ai une autre façon de le dire aussi, c'est par exemple, sur un exemple, parce qu'on est toujours sur des exemples concrets, pour être précis, Et donc, je vais dire, le budget, c'est la somme de tous les tickets. Par exemple, le budget de la conférence, bien entendu, d'après ce qu'on a dit, c'est la somme de tous les tickets, n'est-ce pas? de tous les billets.
Ok, oui.
Et là, je sors ma question secrète, ma question magique. Est-ce qu'il y aurait un cas où ce ne serait pas vrai?
Power Cushion.
Oui, en fait, c'est vrai qu'il y a quand même des gens qui ne payent pas, par exemple les speakers. Et puis, il y a aussi des gens qui donnent, qui donnent plus. Il y a des donneurs, il y a des gens qui... Et puis, on a des sponsors aussi. Ah oui, donc en fait, c'était faux. Donc, on gagne. Maintenant, notre formule... On avait bien compris pour les billets, mais on avait raté les donations, ceux qui ne payent pas et les sponsors. Ah ah! On progresse avec ce genre de questions.
Alors en fait, si vous faites du domaine de design, vous avez forcément quelque part des bandits de contexte. Et donc, dans ce contexte, de façon générale, si vous avez plusieurs domaines experts, c'est un cas fréquent, en général, ce que vous avez, c'est ça.
Plusieurs domaines experts, c'est de la confusion. Mais on peut aussi le regarder d'une façon positive. La confusion, c'est peut-être aussi simplement qu'ils discutent peut-être du même métier en général, mais chacun regarde une facette particulière, sous un sous-domaine particulier, et que ça, ça va nous donner des indices pour illustrer qu'en fait, il n'y a peut-être pas une seule façon de voir votre métier, mais qu'il y en a deux très différentes. Par exemple, la façon de vendre sera en général très différente de la façon d'acheter. ou de la façon de couvrir les risques, ne serait-ce que parce que vous avez des objectifs complètement différents. Là où le commercial veut s'enrichir et avoir son bonus, le département finance veut surtout que la boîte ne coule pas et va faire tout pour que les clients soient tous solvables. Donc ils ont des objectifs antagonistes. Qui vont se contredire à certains moments, ils n'auront pas du tout la même vision d'un client. Pour un, un client, c'est celui qui va dire oui et signer. Pour l'autre, c'est un bilan, la solvabilité, etc. C'est normal qu'ils n'aient pas la même description chacun de la même chose, le même client en chair et en os. Ça, c'est le concept de bandit de contexte. Complètement, dans toute sa splendeur. Je ne vais pas élaborer, on n'a pas le temps et ce n'est pas l'objet aujourd'hui. Mais je serai ravi d'en parler aussi dans les questions après.
Je ne vais pas vous en parler.
Donc, petit bonus type aujourd'hui.
On a des conversations et on parle avec des mots, mais il n'y a pas que les mots.
Il y a aussi tous les...
Un exemple concret d'il y a longtemps. Est-ce qu'on doit, dans un système de bourse, on a des carnets d'ordre et des ordres à l'achat, à la vente, ils sont triés. On les trie comment? Est-ce qu'on doit trier par date ou par prix d'abord?
Et là, la réponse, c'est... Je dirais plutôt par date. Ok, donc je prends note, trié par date. Commentaire à moi. Pas du tout convaincant.
Ça veut dire quoi? Ça veut dire que... Je vais déjà tout de suite, je sais déjà que le changement d'avis est probable, très probable. Et je vais tout de suite l'inclure, cette information, dans mon design. Et en termes de code, je vais déjà prévoir un endroit où je peux facilement substituer le critère de comparaison par un autre, sans coût. Sans coût particulier, donc avec un pattern comme la stratégie par exemple, et un petit comparateur, ou une fonction que vous injectez, si vous pouvez injecter des fonctions dans votre langage. Alors bien sûr, quand on fait ça, on spécule.
C'est-à-dire qu'on introduit du design qui n'est pas absolument nécessaire tout de suite, de façon prouvée. Par contre, On a quand même une information claire qui est l'incertitude, qui est le fait qu'on n'est vraiment pas sûr. Et cette information, je prétends qu'elle est une bonne raison quand même ici de se prémunir avec un petit très léger surcoût de design. Ce qui est amusant ici, c'est qu'on va transformer quand même de l'hésitation directement, va informer une décision de design. Ça, je kiffe. Mais je trouve que c'est vraiment important d'inclure la totalité de l'image. Après tout, si on ressent les émotions et l'incertitude, ce n'est pas pour rien. Ça doit être utile à quelque chose, quelque part.
Enfin, la logistique. Ne négligez pas la logistique. Une astuce extrêmement géniale qu'un collègue m'avait montré une fois, c'était de se promener partout avec un petit enveloppe, un petit classeur, avec des impressions d'écran de tous les écrans importants.
Oui, ils étaient un peu comme ça, d'ailleurs, pour beaucoup.
Des écrans comme ça aussi. Et toutes sortes de... Tous les écrans dont on parle régulièrement dans les... Dans les réunions ou dans les conversations.
Et le bénéfice important, c'est que quand vous discutez, vous allez gagner beaucoup de temps et beaucoup de précision en disant, avec votre doigt, vous mettez votre doigt dessus et vous dites, je parle de ça. Je trouve que c'est vraiment important d'inclure la totalité de l'image. Après tout, si on ressent les émotions et l'incertitude, ce n'est pas pour rien, ça doit être utile à quelque chose quelque part.
Enfin, la logistique. Ne négligez pas la logistique. Une astuce extrêmement géniale qu'un collègue m'avait montré une fois, c'était de se promener partout avec un petit enveloppe, un petit classeur, avec des impressions d'écran de tous les écrans importants.
Oui, ils étaient un peu comme ça, d'ailleurs, pour beaucoup.
Des écrans comme ça aussi. Et toutes sortes de... Tous les écrans dont on parle régulièrement dans les réunions ou dans les conversations.
Et le bénéfice important, c'est que quand vous discutez, vous allez gagner beaucoup de temps et beaucoup de précision en disant, avec votre doigt, vous mettez votre doigt dessus et vous dites, je parle de ça.
Puis d'un coup, c'est beaucoup plus concret quand même. Vous n'avez pas remarqué que souvent dans les salles de réunion, c'est tout vide et vous parlez dans l'air et vous espérez que l'autre a la même image dans sa tête que vous, alors qu'il suffirait d'amener l'image. Et donc les moyens pauvres aussi sont quand même très efficaces. Si vous avez des écrans, il y en a partout maintenant, ce n'est pas forcément une bonne idée parce que trouver votre image, déjà vous loguez, la réunion est à moitié passée, et ensuite trouver le bon endroit dans votre gestionnaire d'un format de document, non, non. Rien ne vaut quelques trucs imprimés dans une petite pochette que vous gardez avec vous. Ça va beaucoup plus vite.
Ensuite, autre point logistique, le lieu.
Quelle est la différence entre cet endroit et celui-là? Est-ce que vous pensez vraiment que les meetings vont se passer de la même façon dans ces deux différents lieux? Si vous avez déjà tenté de faire une réunion ici, parce qu'il n'y avait plus de place là, Vous avez certainement vu la différence d'ambiance. Déjà, quand vous êtes là, vous avez moins l'impression qu'on vous surveille, vous pouvez plus facilement parler, lâcher un peu ce que vous avez envie de dire. C'est vrai que pourquoi on fait toujours des salles comme ça dans les entreprises?
C'est une photo d'Internet, ce n'est pas d'un client.
Cet endroit aussi est magique. Cet endroit est magique.
Parce que jusqu'à présent, il y a aussi un non-dit, c'est qu'on est censé avoir planifié du temps avec les experts métiers.
En vrai, on n'arrive pas souvent à planifier des rencontres régulières et des choses. Par contre, si vous traînez là, vous les croisez quand même de temps en temps, régulièrement, de plus en plus souvent. Et c'est en fait là que vous allez pouvoir peut-être faire avancer votre projet pour de bon.
Donc ne négligez surtout pas, c'est du travail de passer du temps ici. Si vous voulez vraiment que votre projet avance, c'est du travail. Ensuite, oui bien sûr la pause clope aussi pour ceux qui fument, ça c'est un avantage injuste des fumeurs. Autre astuce logistique, si vous n'êtes pas nombreux, si vous asseyez tous du même côté de la table, Alors, vous pouvez dessiner ensemble, sans avoir le dessin à l'envers. Ça paraît con, mais c'est quand même super utile.
C'est un exemple et ça vous permet d'utiliser tous les langages spécifiques à tous les métiers. Et tous les métiers ont des langages spécifiques. Si vous êtes en finance, on dessine comme ça les flux d'argent dans le temps. En positif, reçu ou en négatif. Bien sûr, la musique a son langage, la mécanique a son langage, la supply chain management a ses notations graphiques, et même les missions d'envoi de satellites dans l'espace, ils ont leurs propres notations pour faire ça. Et bien sûr, même la danse a des notations. En fait, si vous creusez un peu dans votre métier, il y a des notations multiples sur la gestion d'entrepôt, il y a des notations un peu dans tout. Et plus votre métier est mature, plus il y a de notation mature. Donc le langage, c'est aussi les notations, c'est aussi le sketching, le tableau et tous les petits diagrammes qu'on peut faire avec et qu'on peut pointer du doigt. Et c'est mieux si on est du même côté que la table.
On arrive à la conclusion. Et en conclusion, achetez mon livre.
Bon, ça, ce n'est pas la vraie conclusion. En vraie conclusion, mais c'est un vrai livre quand même.
Et il sera chez Addison Wesley l'année prochaine en papier.
Tout ce que j'ai mentionné aujourd'hui, c'est juste des exemples. L'important, c'est que vous personnalisez votre boîte à outils, la vôtre à vous, basée sur votre expérience, qui marche bien, etc. Et par contre, je dois vous avertir de quelques clichés qui sont un petit peu embêtants. Le premier, c'est... C'est le rôle de l'ouvrier, le développeur ouvrier. Dites-moi ce que je dois faire et je vais le faire. Un problème. Pas de souci, je le ferai parfaitement. Non, ça, ça craint. On n'est pas du tout dans une relation constructive. Donc c'est l'exécutant pur. L'autre extrême, c'est, toujours dans les travers typiques des développeurs d'ailleurs, c'est je suis un architecte, je vais vous impressionner avec ma brillance, mon excellence technique, je vais faire des trucs.
J'en connais. J'en connais plein.
Ensuite, il y a le troisième problème, c'est plutôt le mien par exemple, c'est« je suis plus intelligent que vous les gars, et j'ai mieux compris que vous votre métier, et donc je vais vous expliquer». Ça, c'est dangereux à plein de titres, même si c'est vrai d'ailleurs. C'est quand même très dangereux. Et donc je postule cette règle d'or, qui est que toujours, toujours, toujours, leur faire sentir Faire être très très clair que je ne les mets pas en danger. Toujours parler sous leur contrôle. Je n'ai aucune intention de piquer leur boulot. Et c'est quelque chose que je dois mettre des gages régulièrement, donner des gages de tout ça. Demandez confirmation de tout. Et le plus fréquent, c'est que systématiquement, vous avez le dernier mot, toujours. Et je vous donne toujours l'occasion de donner le dernier mot. Toujours, toujours, toujours.
Ce qui revient effectivement à dire, on a des conversations d'égal à égal, mais à la fin, c'est vous qui validez et vous avez le dernier mot sur tout.
Donc, j'espère avec tout ça vous avoir convaincu quand même que juste ces conversations avec des experts métiers, ce n'est pas quelque chose d'aussi trivial que ça n'y paraît, c'est quelque chose qui se travaille. It's a thing.
Alors pour conclure, et quand même juste peut-être casser quelques mythes, Bien sûr, je choisis aussi les projets sur leur potentiel, et notamment sur leur potentiel d'avoir un métier riche à creuser, de type domaine, de type métier riche, et plutôt différenciateur, là où le software peut faire quelque chose d'intéressant. C'est pour ça aussi que j'aime bien la finance, entre parenthèses, depuis très longtemps. Et l'autre point, c'est que je choisis aussi les projets basés sur la capacité à accéder à des personnes. Alors, ce n'est pas toujours comme prévu, mais c'est quand même un point important. Donc j'ai un biais. Vous n'avez pas forcément le même biais. Mais avec tout ça en tête, à la fin, j'aime bien ces mots de...
Proposer des idées, ce n'est pas juste une tactique, c'est aussi une façon de suggérer de plus en plus fréquemment des idées innovantes, des véritables nouveautés, des véritables propositions même de valeurs métiers. Vous avez vu tout à l'heure, on a vu tout à l'heure sur les modèles métiers, que quand un bon modèle, il a même un pouvoir de prédiction. Vous pouvez prendre un modèle qui était prévu pour deux jambes, il peut parfois prédire qu'il marcherait aussi sur huit jambes ou N jambes. C'est des choses qu'on peut extrapoler par extrapolation. Vous prenez votre compréhension et vous l'extrapolez, et elle propose des choses. On pourrait aussi faire ça, on pourrait aussi faire ça. Et finalement, on arrive à le saint graal de cette collaboration, c'est quand on finit dans les deux sens par proposer des choses à partir du code. Le code suggère des fonctionnalités nouvelles. Et là, on arrive à un point où on passe de juste supporter un métier à augmenter un métier, faire des choses qui n'étaient pas possibles avant le logiciel. Et donc là, on est dans une nouvelle phase de création de valeur. Alors c'est quelque chose qui n'est pas possible tant qu'on se sépare, tant que ceux qui savent quoi faire et ceux qui savent comment le faire sont séparés.
C'est ce que disait en gros Michael Fedor dans cet article.
Et donc il faut arrêter avec cette dichotomie de business versus IT versus business.
Cette séparation est longue. Elle empêche de saisir les opportunités de type le software mélangé au métier qui permet de faire des choses augmentées.
Donc en pratique, en général, on ne peut pas le faire. Les sociétés d'aujourd'hui n'acceptent pas encore bien ça. Dans l'idéal, on refonderait les équipes, on arrêterait la séparation, on n'aurait plus une direction IT, une direction business, mais on refonderait les deux. Tout de suite, on n'a pas ça. Mais on peut le faire à petite échelle quand même, pour de faux, mais c'est quand même presque pour de vrais, avec des exercices type event storming, où on met tout le monde dans une pièce, Pendant cette journée-là, tout le monde sera une seule, il n'y aura plus de séparation, pas de silo, on sera tous ensemble.
Une autre façon de le faire, mon image est bien dégueu là, c'est le mode programming, où tout le monde est dans la même pièce, donc toute l'équipe de développement, et là vous avez votre expert métier qui est invité et qui vient le temps de sa tâche. Si pendant deux heures on bosse sur un truc, on va essayer de l'avoir pendant deux heures, le temps qu'on travaille sur la user story qu'il a proposée. Et donc ici, Mob Programming parle de Product Owner, mais si on remplace Product Owner par Domaine Expert, on a le meilleur des mondes pour la réussite de vos projets. Il est 18h, merci de votre attention, et bon week-end! Ah non, pas encore! Oh non!