gien-verschatse-slow-down-to-speed-up-your-decision-making

[00:00:04] Ah, me voilà. D'accord. Bonjour tout le monde. Bonjour mes amis. Je ne ferai pas la présentation en français, car ce serait inutile pour nous tous.
[00:00:19] Euh, je parlerai peut-être un peu, mais euh pas très bien. Je voulais commencer par un lever de main. Qui a déjà entendu ça : nous avons utilisé la technologie X une fois et ça a horriblement mal tourné, c'est pourquoi nous ne pouvons pas l'utiliser dans ce projet. Qui a déjà entendu ça ou quelque chose de similaire ?
[00:00:39] D'accord, quelques-uns.
[00:00:42] Et celui-là ? Mon projet précédent a utilisé la technologie X et ça a marché super bien. Faisons exactement la même chose. Quelques-unes, quelques mains de plus. Oui, c'est ce que j'entends souvent quand je vais dans des entreprises.
[00:00:59] La vérité est que nous ne sommes pas très bons pour prendre des décisions. Donc choisir une technologie, c'est prendre une décision, et ce que nous faisons réellement, c'est de ne pas penser aux circonstances de cette entreprise, nous essayons juste de faire quelque chose qui a déjà été fait auparavant. Alors, désolée, pas désolée. Euh, mais aujourd'hui, je suis là pour, je l'espère, vous enseigner un peu sur la prise de décision et comment la faire un peu mieux dans votre entreprise ou pour vous-même personnellement. La conférence s'intitule 'Ralentir pour accélérer votre prise de décision' et à la fin de la conférence, vous comprendrez pourquoi vous devez ralentir afin d'accélérer. Alors, bonjour. Je m'appelle Gene. Je suis de Belgique, de la partie néerlandaise. Euh, je suis consultante chez Artlin et avant cela, j'ai été développeuse de logiciels pendant 13 ans. J'ai également co-écrit un livre intitulé 'Collaborative Software Design' avec Kenny et qui me soutiennent là-bas au quatrième rang aujourd'hui.
[00:02:06] Et donc, en tant que consultante, je suis souvent appelée dans des entreprises quand les choses ne vont plus très bien. Et ils nous disent, nous voulons passer aux microservices et nous voulons que vous nous aidiez à concevoir les microservices. Et puis, vous savez, je commence à recueillir des informations, à regarder autour de moi et à essayer de comprendre quels sont exactement les problèmes qu'ils essaient de résoudre. Et souvent, c'est parce qu'ils ont un, vous savez, un monolithe devenu trop grand et qu'ils ne comprennent plus vraiment les limites.
[00:02:42] Alors ils veulent s'en débarrasser et recommencer.
[00:02:47] Et puis je dois dire, je suis désolée, mais cela ne va pas résoudre votre problème. Parce que votre problème n'est pas que votre monolithe n'a plus, vous savez, de bonnes limites. C'est par exemple que vous ne savez pas comment euh diviser vos équipes ou comment vous
[00:03:09] en fait ce qui est important pour l'entreprise, vous ne parlez pas à la partie commerciale de cela. Vous ne comprenez pas comment cette entreprise gagne de l'argent et donc vous ne comprenez pas vraiment à quoi devrait ressembler un bon système logiciel. Donc, dire simplement que nous allons passer aux microservices ne va pas résoudre votre problème.
[00:03:30] Et la raison en est souvent que nous n'apprenons pas à réfléchir à ce type de décisions. Et c'est une décision que vous devez prendre. Et quand je travaillais en tant que programmeuse et maintenant en tant que consultante en logiciels, je constate souvent que les gens ne comprennent pas vraiment comment s'y prendre. Alors ils font juste quelque chose qui leur semble acceptable et ils avancent. Et j'étais très, très frustrée par cela. Surtout quand je devais assister à des réunions et que nous n'arrêtions pas de parler, parler, et que rien ne se passait et que tout le monde avait des opinions, mais qu'il n'y avait aucune issue. C'était plutôt le désordre. Euh, c'est ce qu'on appelle un théâtre de participation où tout le monde participe vraiment à la prise de décision, mais aucune décision n'est réellement prise. Alors je suis revenue au début. Et je voulais en fait comprendre, d'accord, qu'est-ce qu'une décision ? Je pense que la plupart d'entre nous pourront nous donner une définition. Mais j'ai commencé à regarder d'autres industries et j'ai rencontré un ami qui a étudié l'économie et il m'a dit qu'en fait, il existe une théorie de la prise de décision. Et on nous apprend ce qu'est une décision. Et maintenant que nous sommes dans le logiciel, il a dit, je suis aussi très frustré car les gens ne savent pas vraiment tout ça. Alors j'ai commencé à creuser la question.
[00:04:59] Et maintenant, je l'appelle un sujet qui a gravement échappé à tout contrôle. J'avais l'habitude de dire un peu hors de contrôle. Mais maintenant, je donne des conférences à ce sujet, donc je pense que ça a un peu empiré. Parce que je veux vraiment aider les entreprises à prendre de meilleures décisions. Je ne prétends pas être une experte en prise de décision, euh loin de là. Mais j'ai appris des choses en cours de route qui m'ont vraiment aidée et je vais les partager avec vous aujourd'hui et j'espère qu'elles vous aideront aussi.
[00:05:27] Je vais donc commencer par une définition ennuyeuse. Ce qu'est une décision. C'est donc un choix entre deux ou plusieurs alternatives qui implique une allocation irrévocable de ressources. Et il y a deux choses très intéressantes à ce sujet. Il s'agit d'un choix entre deux ou plusieurs alternatives et d'une allocation irrévocable de ressources.
[00:05:51] C'est donc une alternative, c'est quelque chose qui vous mène réellement à un futur différent.
[00:05:58] Parce qu'imaginons que nous devions choisir une technologie pour, euh, vous savez, activer la journalisation dans votre système et que les deux fassent exactement la même chose, alors il n'y a vraiment pas de décision à prendre. Donc, ils doivent vous emmener vers un avenir différent.
[00:06:19] Et le fait est que ce que les gens ne réalisent souvent pas, c'est que nous avons besoin de plus d'une option pour pouvoir les comparer. Nous avons donc besoin de ces deux alternatives ou plus. Et surtout quand il s'agit de concevoir, même lorsque nous créons des modèles de domaine par exemple, pour les intégrer dans un code. La première chose qui nous vient à l'esprit, c'est ce que nous utilisons. Et nous ne décidons pas vraiment parce que nous n'avions qu'une seule option là-bas.
[00:06:49] Ne pas décider est d'ailleurs aussi une option. Euh, le problème est que le temps décidera pour vous la plupart du temps.
[00:06:57] Et la deuxième est l'allocation irrévocable de ressources. C'est une façon très économique d'exprimer euh, vous savez, l'argent, le temps et les gens, en gros. Je n'aime pas le mot ressources, mais si vous regardez l'économie, il est partout. Et j'aime bien ce concept dans ma définition parce que ça ce que cela signifie, c'est que, eh bien, si vous vous trompez, il y a un coût. Vous avez consacré du temps, des gens ont investi leur temps là-dedans et cela a coûté de l'argent. Mais ce qui est amusant, c'est que j'ai maintenant la liberté de changer d'avis et tout ce que j'ai à faire, c'est de payer le prix. Et aller de l'avant.
[00:07:46] Si vous voulez prendre une décision, qu'est-ce qui doit être là exactement ? J'ai donc commencé à regarder un peu, c'est un modèle et non le modèle d'une décision. Mais pour moi, euh, si vous voulez prendre une décision, vous avez besoin d'un décideur. Vous avez besoin d'un cadre, je parlerai un peu plus de cela plus tard. Nous avons besoin d'alternatives, vous avez certainement besoin de deux options ou plus, nous avons aussi souvent besoin d'informations et nous avons euh une préférence. Et puis il y a une sorte de processus, une sorte de logique qui nous dit quelle ligne de conduite nous devrions adopter.
[00:08:23] Et donc, qui est le décideur ? Quelqu'un a-t-il déjà été à une réunion où ils n'arrivaient pas à savoir quelle option choisir et tout le monde changeait toujours d'avis ?
[00:08:38] Encore.
[00:08:41] Si vous y repensez, y avait-il une personne responsable de prendre cette décision ?
[00:08:50] Oui non.
[00:08:54] Souvent, il y en a, nous avons des chefs d'équipe et des choses comme ça. Mais pour moi, un décideur est quelqu'un qui a l'autorité, l'engagement et la permission de prendre la décision. Et l'autorité signifie en gros que, eh bien, probablement quelque part dans leur titre de poste, ils seront autorisés à prendre cette décision.
[00:09:13] Si vous êtes chef d'équipe ou chef technique, vous pouvez prendre des décisions technologiques. Si vous êtes architecte, vous pouvez prendre des décisions de conception, des choses comme ça, donc vous avez cette autorité au sein de l'entreprise. L'engagement est personnel. Cette personne est-elle prête à prendre la décision ?
[00:09:32] Ce n'est pas toujours vrai. Ils doivent donc être engagés. Et le dernier est la permission. Cette personne, de la part des autres personnes affectées par la décision, a-t-elle réellement la permission de prendre cette décision ?
[00:09:48] J'ai travaillé dans une équipe, c'était il y a environ 10 ans je crois, et nous avions un chef d'équipe. Et cette personne n'était pas très appréciée, elle avait des opinions très fortes, mais elle n'avait pas programmé depuis 15 ans. Et ils ont continué à prendre des décisions en notre nom. Donc cette personne n'avait pas notre permission de prendre réellement ce type de décisions.
[00:10:17] C'est pourquoi je définis un décideur comme ça. Et très souvent, lorsque les décisions ne sont pas prises, c'est parce qu'elles sont contrecarrées ou que vous y revenez sans cesse, c'est parce que, vous savez, l'une de ces trois choses manque à la décision. Je me souviens que j'avais un ami et il est venu me voir avec un problème. Et j'étais très enthousiaste à ce sujet. J'étais là, oh, voici ce que tu peux faire, tu peux faire A, tu peux faire B, tu peux C. Et je pense que tu devrais choisir B pour cette, cette, cette et cette raison. J'ai en quelque sorte expliqué tout mon processus de prise de décision. Et ils se sont mis très en colère contre moi pour ça. Euh parce que j'étais clairement engagée à prendre la décision en son nom. Mais je n'avais pas la permission et je n'avais certainement pas l'autorité de le faire. Donc même dans vos relations personnelles, si quelqu'un se met en colère contre vous, c'est probablement à cause de cela et j'ai vu cela arriver plusieurs fois aussi.
[00:11:21] Le deuxième est le cadre. Et c'est en fait la façon dont le décideur perçoit le problème. Comment regardons-nous cela, comment allons-nous prendre cette décision ?
[00:11:37] Maintenant, la partie la plus difficile de toute décision est en fait de savoir comment vous allez cadrer ce problème. Comment allons-nous aborder cela, et c'est aussi la partie à laquelle nous consacrons le moins de temps. Donc la question que le premier a enseignée ce matin était très pertinente : quel est le problème que nous essayons réellement de résoudre ? Et très souvent, cette question est en quelque sorte contournée ou ignorée, ou le problème est formulé de telle manière qu'il contient déjà une solution. Nous devrions donc y consacrer du temps.
[00:12:09] Nous devrions ralentir et examiner quel est exactement le problème, le comprenons-nous, avons-nous suffisamment de perspectives à son sujet ?
[00:12:21] Et la première chose que je vais faire, mon eau est derrière la scène.
[00:12:28] D'accord.
[00:12:31] Alors, le premier problème que vous devez, la première question que vous devez vous poser est : est-ce un problème ? Ou avons-nous une polarité ?
[00:12:42] Parce que tout dans la vie n'est pas un problème qui doit être résolu.
[00:12:48] Qu'est-ce qu'une polarité ? C'est fondamentalement un problème ou un défi continu qui n'a pas de solution claire en termes de choix de l'un par rapport à l'autre. C'est un choix entre deux ou plusieurs alternatives de ma définition, ce n'est pas là. Comme si nous voulions, si vous allez dire quel restaurant allons-nous choisir ce soir ? Alors vous aurez quelques options et vous en choisirez une et vous avancerez et c'est un problème que vous pouvez résoudre.
[00:13:16] Mais par exemple, si nous parlons de devoir faire, nous voulons faire de la modélisation collaborative dans notre entreprise, mais nous devons aussi, vous savez, coder pour que cela puisse passer en production, c'est en fait une polarité.
[00:13:30] Parce que les gens ne cessent de me demander : quelle quantité de modélisation collaborative devrions-nous faire, quand pouvons-nous commencer à coder comme si c'était un problème à résoudre ? Et je suis là, non, ce n'est pas l'un ou l'autre, c'est quelque chose que vous devez faire les deux et vous devez faire des allers-retours entre. Donc la polarité n'est pas quelque chose que l'on peut résoudre, elle doit être gérée.
[00:13:53] C'est pourquoi nous avons la complexité locale versus la complexité globale dans les systèmes logiciels. Ce n'est pas quelque chose que vous pouvez résoudre. C'est quelque chose que vous devez gérer et vous assurer que les deux sont dans un assez bon équilibre.
[00:14:06] Combien de pouvoir, combien de pouvoir de décision l'équipe a et combien vous pouvez décider par vous-même est aussi une polarité, quelque chose que vous devez gérer. Il y aura de nouvelles situations qui surgiront et que vous devrez discuter. Et parfois, vous remarquez que décider de ce type de technologie en tant qu'individu ne fonctionne pas vraiment, nous devons le déplacer vers l'équipe et ensuite nous devons déplacer certaines choses vers l'individu. Donc tout ça, ce sont des polarités. Il y a une carte amusante pour ça, je vais regarder d'un peu plus près, qui vous aide en fait à faire ça dans un contexte d'équipe. que vous avez géré. C'est ainsi que la complexité locale versus la complexité globale dans les systèmes logiciels. Ce n'est pas quelque chose que vous pouvez résoudre, c'est quelque chose que vous devez gérer. et assurez-vous que les deux sont dans un équilibre assez bon. Combien de pouvoir, combien de pouvoir de décision l'équipe a et combien vous pouvez décider par vous-même. est aussi une polarité, quelque chose que vous devez gérer. Il y aura de nouvelles situations qui se présenteront et que vous devrez discuter et parfois vous remarquerez que déployer, euh, ce type de technologie en tant qu'individu ne fonctionne pas vraiment. Nous devons transférer cela à l'équipe, puis nous devons transférer certaines choses à l'individu. Donc tout cela sont des polarités. Il y a une carte amusante pour cela, je vais regarder de plus près, qui vous aide en fait à faire cela dans un contexte d'équipe. Donc, euh, vous avez la gauche et la droite, n'est-ce pas, de la polarité, quel que soit celui que vous essayez de gérer, nous avons donc une modélisation collaborative qui est bonne. Par exemple, et puis nous remplissons les effets positifs de tout ce qui se trouve à gauche et les effets positifs de tout ce qui se trouve à droite. Et la raison pour laquelle je commence par le positif est qu'il est très facile de dire des choses négatives. Où que nous allions, je suis la même chose, de la même manière, je pense que c'est un peu comme nos cerveaux sont entraînés, nous sommes là pour voir les problèmes, nous sommes très bons pour les critiquer et voir les conséquences négatives de quelque chose. Et le positif est beaucoup plus difficile, c'est donc par là que j'ai commencé, j'ai commencé par la partie la plus difficile. Et puis je remplis les effets négatifs et le négatif euh de la gauche et l'effet négatif de la droite. Et comme vous pouvez le voir, il y a un symbole de l'infini dedans. Ce qui signifie que si nous faisons quelque chose pendant trop longtemps, comme si nous faisons de la modélisation collaborative euh pendant trop longtemps, ou si nous mettons trop de choses au niveau de l'équipe lorsque nous essayons de prendre des décisions, nous allons en fait vraiment commencer à ressentir ces effets négatifs. Et ce que nous devons alors faire est en fait de revenir de l'autre côté. Si nous commençons à coder ou si nous déplaçons certaines choses vers des décisions individuelles afin que nous puissions ensuite profiter de l'effet positif. Et ce que nous voulons faire, c'est expérimenter ces effets négatifs, vous savez, le moins souvent possible. Et il y a des signaux et des observations que vous pourriez faire avec votre équipe. Que vous pouvez dire, ok, ce que nous commençons à remarquer, cela signifie qu'il est temps de passer à l'autre pôle de la polarité, il est temps de commencer à coder ou il est temps de revenir à la modélisation collaborative. Et puis il y a des actions que vous pouvez entreprendre. Vous dites que, oh, nous allons programmer une session de 30 minutes pour faire de la modélisation collaborative là-bas quand nous remarquons que le codage ne fonctionne pas réellement, nous subissons trop d'effets négatifs. Donc je remplis cela avec l'équipe afin que tout le monde soit euh sur la même longueur d'onde et ensuite nous voyons comment nous pouvons euh gérer cela. D'accord. Je pourrais en dire beaucoup plus sur la polarité et la gestion de la polarité, euh, mais les décisions concernent euh des problèmes. Donc la question que j'ai est que pouvez-vous faire avec le problème ?
[00:17:05] Vous pouvez le résoudre ou vous pouvez le rendre hors de propos.
[00:17:10] Cela signifie que vous n'avez plus à résoudre le problème car cela n'a pas d'importance. Rendre quelque chose non pertinent est très difficile, ce n'est pas si facile.
[00:17:21] Une des histoires dans les cercles de prise de décision concerne un ascenseur dans un immeuble d'appartements pour lequel ils ont reçu beaucoup de plaintes, disant que l'ascenseur était tout simplement trop lent. Ils ont donc réuni un groupe d'ingénieurs dans une pièce pour résoudre ce problème. Et ils cherchaient des moyens d'accélérer l'ascenseur.
[00:17:45] Et puis quelqu'un d'autre est venu et a regardé, oh, ce qu'ils font réellement, c'est essayer d'accélérer l'ascenseur. Et ils ont dit, eh bien, en fait, et si les gens ne remarquaient plus que l'ascenseur est lent ? Alors ce qu'ils ont fait, c'est qu'ils ont accroché des miroirs à côté de l'ascenseur, car quand nous pouvons nous regarder, nous percevons le temps un peu différemment. Et donc les gens ont simplement cessé de remarquer que l'ascenseur était lent, il était toujours lent. Donc le problème a été rendu hors de propos, il n'a pas été résolu du tout. Et comme vous pouvez le voir sur les photos, j'ai vu cela euh dans la nature quand je suis allé à des hôtels, certains l'abordent avec euh un bon sens de l'humour. Hé, nous savons que l'ascenseur est lent, euh lent. Et d'autres, en quelque sorte, font vraiment de l'ascenseur une sorte de fête, euh, pour que vous ne remarquiez pas euh à quel point il était lent. Quand je regarde le logiciel, je pense que ce que nous avons de plus proche en matière de tentatives pour rendre un problème non pertinent, surtout quand il s'agit de gros tas de boue et de, vous savez, des monolithes mal conçus, c'est le projet Phoenix. Nous n'essayons pas d'obtenir de meilleures limites, nous n'essayons pas d'obtenir une meilleure modularité, nous ne passons pas aux microservices, nous recommençons simplement. Ils ne se terminent pas bien la plupart du temps car, eh bien, vous créez aussi un désordre à l'intérieur de cette nouvelle base de code et vous ne rattrapez jamais vraiment votre retard. Euh, donc je ne le recommande pas, mais si vous pensez au logiciel et au développement logiciel, c'est ce que je vois de plus proche pour rendre un problème non pertinent là-bas.
[00:19:26] D'accord. Alors, si vous voulez prendre une décision, vous devez vous demander quel type de problème j'ai exactement ? Et j'ai pour vous quelques modèles qui vous aideront à raisonner et à expliquer les problèmes à vos collègues et à la direction supérieure. J'aime beaucoup celui-ci, il parle du rôle des faits et du jugement dans un problème ou un problème que vous essayez de résoudre. Lorsque le rôle du fait est très élevé et qu'aucun jugement n'est fondamentalement nécessaire, nous parlons de problèmes simplistes. Cela signifie qu'il n'y a qu'une seule réponse qui est en fait déterminée par les faits. Par exemple, qu'est-ce que F sharp, qu'est-ce que low cone, le fait est-ce la conférence. Je ne sais pas si vous connaissez F sharp, c'est un langage de programmation dont j'étais très friand. Quand je l'ai découvert.
[00:20:19] Puis le deuxième est déterministe, le fait y a toujours un rôle. Mais il n'y a qu'une seule réponse, mais elle est déterminée par une sorte de formule. Si nous regardons le calcul de la vélocité ou quand nous faisons du scrum, il y a une sorte de formule et ensuite nous obtenons une réponse à cela. C'est donc un problème déterministe. Nous avons aussi l'aléatoire. Où nous avons différentes réponses et toutes sont possibles, mais toutes sont identifiables. Et quand vous choisissez une pile technologique, vous résolvez en fait un problème aléatoire.
[00:20:54] Parce que si nous nous efforçons vraiment, nous pouvons vraiment nommer toutes les bibliothèques de journalisation en Python, par exemple. Je ne dis pas que c'est une bonne idée de le faire.
[00:21:04] Mais nous pourrions le faire. C'est donc un problème aléatoire.
[00:21:09] Quand nous pensons à la conception de logiciels et à la façon de créer des modèles de domaine et à la façon d'intégrer ces modèles de domaine dans notre code. Nous sommes face à un problème indéterminé. Parce qu'il y a différentes réponses, toutes sont possibles et toutes ne sont pas identifiables.
[00:21:27] J'ai dit que les modèles de domaine sont le meilleur exemple. Et je pense que c'est vraiment important parce que les gens nous demandent souvent : pourquoi la programmation est-elle si difficile ? Et je dirais, s'ils ne font qu'écrire du code, et je dirais que le simple fait de coder, oui, ce n'est probablement pas si difficile, mais la programmation est plus que du simple codage. Il s'agit de comprendre, d'essayer d'acquérir cette connaissance du domaine, de voir comment je peux la convertir en un modèle qui les aide réellement à résoudre le problème, puis de convertir ce modèle en code. Et c'est un indéterminé, ça veut dire que le jugement est très élevé. Nous devons en quelque sorte essayer de nous évaluer pour savoir si ce que nous avons trouvé sera utile maintenant et pour l'avenir. Alors si les gens disent, pourquoi devrions-nous essayer de euh consacrer du temps à la modélisation collaborative, pourquoi voulez-vous parler à votre analyse commerciale, pourquoi voulez-vous parler à l'entreprise dans son ensemble ? Disons que nous essayons de résoudre un problème indéterminé, et c'est en fait assez difficile. Parce que le jugement est très élevé et que le rôle du fait est presque inexistant. Je trouve donc que c'est un modèle très utile pour communiquer pourquoi certaines choses dans notre industrie sont difficiles et pourquoi certaines choses sont en fait euh plutôt faciles, comme la différence entre le codage et la programmation proprement dite.
[00:22:53] Le deuxième, euh, est une façon d'aborder euh les problèmes. Parfois, si nous y regardons de plus près, il y a ce désordre ou un point douloureux que nous remarquons et nous essayons en quelque sorte de comprendre ce que c'est. Donc nous essayons de euh déterminer quel est le problème exactement parce que nous ne sommes pas sûrs. Ce qui n'est pas une position facile à occuper, nous ressentons juste la douleur, mais nous ne connaissons pas la cause.
[00:23:22] Parfois, nous essayons en fait d'atteindre quelque chose et nous ne sommes pas tout à fait sûrs de la manière d'y parvenir. Peut-être que nous sommes conscients, nous savons où nous en sommes actuellement, nous savons où nous voulons aller ou nous avons une idée de là où nous voulons aller. Mais comment y arriver est un mystère total. Si nous regardons la refonte d'un système logiciel ou la refactorisation de certaines parties du code, nous sommes souvent confrontés à ce deuxième problème : comment y arriver est un mystère total. Et donc nous devons nous asseoir, réfléchir à ce à quoi nous voulons qu'il ressemble et comment nous pouvons trouver un chemin de là où nous sommes actuellement à là où nous voulons être. Aussi pas quelque chose de si facile à faire.
[00:24:04] Et le dernier, et c'est mon préféré parce que c'est drôle, euh, non pas parce que c'est utile. Mais c'est que si quelqu'un a une solution dont il est tombé amoureux et qu'il cherche maintenant un problème. pour le résoudre. quel problème est celui que nous résolvons réellement ici et nous avons créé un outil et maintenant vous allez avoir des problèmes. Et quand nous parlons de buzz et de suivre les tendances, nous sommes souvent dans ce dernier cas. J'ai fait ça, je suis, vous savez, euh, tombé amoureux de cette solution et puis j'ai essayé de trouver un problème pour pouvoir l'utiliser au travail. Donc si vous, si vous regardez ça, si vous montrez ça à des gens, par exemple si vous avez un, vous avez un bug, mais ce sont les points douloureux dans votre système et/ou il y a un peu un désordre mal défini là et vous n'arrivez pas à le comprendre, euh, ou si vous essayez de redessiner quelque chose ou de refactoriser quelque chose et que vous ne savez pas vraiment comment ça se passe, euh, ou si vous essayez de faire rire les gens tout en disant que non, nous n'allons pas faire ça parce que c'est nous n'avons pas de problème, alors en fait vous avez besoin de la solution pour ça. Si vous essayez de faire rire les gens, tout en disant que non, nous n'allons pas faire cela parce que nous n'avons pas de problème, alors en fait vous avez besoin de la solution pour cela, alors vous pouvez montrer cela aux gens et cela aide un peu à communiquer et à leur faire mieux comprendre comment vous devriez gérer tout cela.
[00:25:24] Donc je l'ai déjà dit plusieurs fois, quel est exactement le problème que vous résolvez ? Pour ce faire, nous avons besoin d'un énoncé de problème, quelque chose qui explique ce qui ne va pas. Et ce n'est pas une chose facile à formuler correctement.
[00:25:40] Il y a beaucoup de pièges quand on essaie de faire ça. Le premier piège est qu'il n'y a pas de focus. Alors, comment pouvons-nous réparer notre grosse boule de boue ? Comment pouvons-nous réparer la mauvaise architecture ? Comment pouvons-nous améliorer cette architecture ?
[00:25:54] Il n'y a pas de véritable focus dans ce problème que nous essayons de résoudre. Voulons-nous examiner l'ensemble du système ou voulons-nous examiner les parties les plus critiques ? Où sont exactement les choses, vous savez, les plus douloureuses pour nous, est-ce les plus douloureuses pour nos utilisateurs ou est-ce les plus douloureuses pour nos développeurs ? Alors, comment allons-nous faire cela ? Donc il n'y a pas de focus et il y a tellement de questions, nous devons en fait formuler cela un peu mieux et y regarder un peu plus en profondeur, puis nous fixer sur un problème.
[00:26:28] que nous voulons résoudre et qui définit ce cadre. comme prise de décision. Quelle est l'étendue de notre examen de l'ensemble du système logiciel ou quelle est la précision de notre concentration sur les parties les plus importantes de notre système logiciel. Comment allons-nous réajuster cette chose ? Le deuxième piège est que l'attention est motivée par des hypothèses et par des solutions. Comment passer aux microservices ? Les microservices sont très clairement une solution qui tente de résoudre certains problèmes.
[00:27:01] Et en ajoutant déjà la solution ici, nous éliminons les options, nous n'avons plus ces deux alternatives ou plus dont nous avons besoin pour prendre une décision. Il n'y a que des microservices, nous avons déjà terminé, donc ce n'est pas vraiment une décision à prendre.
[00:27:19] vous savez, inconsciemment déjà fait.
[00:27:26] Et la façon dont vous formulez le problème est très importante car elle influencera le résultat. Cela détermine comment vous l'abordez, quel type d'options je peux réellement trouver, cela va être déterminé par cela et donc, quel type de résultat vais-je obtenir une fois que j'aurai sélectionné l'une des options. Nous devons donc vraiment passer un peu plus de temps là-dessus, jouer avec le problème en fait.
[00:27:51] Nous pouvons le reformuler en paraphrasant, comment convaincre les gens de faire de la conception axée sur le domaine ? C'est une question que l'on me pose souvent. Euh, mais vous pouvez aussi dire, comment pouvons-nous rendre notre équipe enthousiaste à l'idée de faire de la conception pilotée par le domaine ? Ce qui est un sentiment très différent dans ces deux questions. Si nous parlons de comment convaincre par rapport à comment les rendre enthousiastes, vous proposerez des options très différentes pour réellement réparer quelque chose.
[00:28:20] Le deuxième est que vous pouvez rediriger l'attention. Comment pouvons-nous réparer notre grosse boule de boue ? est comment pouvons-nous améliorer l'expérience utilisateur ? Parce que les utilisateurs ressentent notre douleur, ressentent la douleur de ne pas avoir un système logiciel bien conçu. Nous nous concentrons en fait sur l'expérience utilisateur au lieu d'essayer simplement de passer aux microservices ou de redessiner notre monolithe. Nous redirigeons donc complètement l'attention et nous proposerons différentes options avec différentes idées grâce à cela. Et le dernier est de demander pourquoi. C'est quelque chose que je dois faire très souvent en tant que consultant logiciel. C'est aussi quelque chose que les enfants de cinq ans font très souvent et quelque part entre être consultant et être un enfant de cinq ans, les gens m'ont informé que ce n'était pas bien de continuer à poser la question pourquoi.
[00:29:16] Euh, donc j'ai dû réapprendre un peu ça. Mais en gros, disons que nous voulons passer aux microservices, c'est donc un énoncé de problème basé sur une solution. C'est comme, pourquoi ? Eh bien, notre monolithe s'est transformé en une grosse boule de boue. D'accord, alors comment pouvons-nous rétablir les limites de notre monolithe ? C'est en fait la question. Le problème que nous voulons résoudre. D'accord, mais pourquoi ? Eh bien, parce que nous ne pouvons plus comprendre le code. Et puis vous avez dit, d'accord, comment pouvons-nous réellement retrouver la connaissance de notre monolithe ? Parce que c'est ce que nous voulons faire ici. Pourquoi ? Et tu sais, tu continues. Et comme vous pouvez le constater, nous avons commencé par passer aux microservices et nous avons fini, en le faisant seulement trois fois, peut-être devrez-vous le faire un peu plus, par vouloir réellement retrouver la connaissance perdue dans notre système logiciel. Encore une fois, deux problèmes très différents.
[00:30:06] Et la plupart du temps, quand les gens veulent passer aux microservices, il s'agit de connaissances perdues et d'essayer de les regagner et d'être capable d'en reprendre le contrôle afin de ne pas être euh si perdus. Il y a une toile de recadrage très amusante, enfin, je la trouve amusante. que vous pouvez remplir, je ne l'ai pas mis sur une toile. parce que je trouve que la toile n'apporte pas vraiment de valeur ajoutée. Mais il y a quelques questions que vous pouvez vous poser lorsque vous essayez de définir le problème que nous allons résoudre. Quel est le problème ? Qui est impliqué ? Qu'est-ce qui nous manque en regardant en dehors de ce cadre ? Vous pouvez le déterminer et dire, ok, mais qu'y a-t-il d'autre ? Parce qu'il y a peut-être quelque chose en dehors de ce cadre que nous pouvons faire, ce qui le rend non pertinent. il s'agit de connaissances perdues et d'essayer de les retrouver et d'être capable d'en reprendre le contrôle afin de ne pas être si perdu. Il existe un cadre de reformulation très amusant, enfin, je le trouve amusant, que vous pouvez remplir. Je ne l'ai pas mis dans un cadre parce que j'ai l'impression que le cadre n'ajouterait pas vraiment de valeur, mais il y a quelques questions que vous pouvez vous poser lorsque vous essayez de définir le problème que nous essayons de résoudre. Quel est le problème ? Qui est impliqué ? Qu'est-ce qui nous manque ? en regardant en dehors de ce cadre ? Vous pouvez le déterminer et dire : 'Ok, mais qu'est-ce qu'il y a d'autre ?' Parce que peut-être qu'il y a quelque chose en dehors de ce cadre que nous pouvons faire, ce qui le rendrait non pertinent. Repenser l'objectif. Y a-t-il un meilleur objectif à poursuivre si nous disons que nous voulons améliorer notre expérience utilisateur au lieu de dire que nous voulons avoir des micro-services, peut-être que c'est un meilleur objectif à poursuivre. Examinez les points positifs, quelles sont les exceptions positives, par exemple, quelle partie de notre base de code est en fait facile à gérer. Vous essayez de regarder les choses positives parce que nous parlons souvent de manière négative de notre monolithe et vous savez, nous n'avons rien à voir avec le fait que tout est en désordre maintenant. Alors, quels sont les points positifs de cela ? Très important. Regardez dans le miroir, quel est mon rôle dans la création du problème ? Comment ai-je contribué ? Ce n'est pas quelque chose que nous faisons souvent. Ou j'ai été responsable de la création de désordres dans les bases de code. Ou je suis responsable de la prise de mauvaises décisions. Euh, alors comment ai-je contribué à cela ? Et quel problème les autres personnes de notre entreprise essaient-elles de résoudre ? Regardez ce qu'il en est de l'équipe et comment passer en production. Un peu mieux, mais peut-être que l'équipe à côté de moi essaie de résoudre un problème différent et peut-être qu'ils ont une meilleure compréhension et nous pouvons réellement apprendre les uns des autres. Si nous disons que notre chef de produit ou propriétaire de produit n'est jamais disponible pour nous ou qu'il n'écoute pas ce que nous leur disons, nous n'avons aucune voix dans la prise de décisions. D'accord, mais quels sont leurs problèmes et qu'est-ce qu'ils essaient de résoudre ?
[00:32:25] Et puis-je d'une manière ou d'une autre les aider à résoudre leurs problèmes, ce qui rendrait les choses un peu plus faciles pour moi aussi. Et donc je trouve que c'est très utile pour bien cadrer en tant que décideur. D'accord, donc nous comprenons un peu mieux le problème. Et maintenant ? Eh bien, maintenant nous avons besoin d'informations.
[00:32:54] Et donc c'est l'une de ces trois choses que j'ai dites qui sont entrées dans le processus de prise de décision.
[00:33:01] Lorsque j'essaie de redessiner un système logiciel, j'utilise la modélisation collaborative pour obtenir ces informations. J'essaie de comprendre les processus métier. J'essaie de comprendre les règles et les politiques. J'essaie de regarder les parcours utilisateurs, quels workflows sont là. Et je fais ça avec les personnes qui ont réellement cette connaissance. Ce qui la plupart du temps n'est pas moi, parce que ce que je comprends, c'est comment le système logiciel fonctionne, mais ce n'est pas nécessairement la réalité. Et donc je veux en quelque sorte l'obtenir de la personne qui sait le mieux. J'ai donc organisé une session de modélisation collaborative là-bas. Il existe de nombreux outils qui peuvent le faire. Donnons-vous tous une solution facile. Ce que je recherche, c'est que ce soit simple. Je ne veux pas passer une heure à expliquer comment l'outil fonctionne avant de pouvoir l'utiliser. Il doit donc être facilement accessible à toutes les personnes impliquées. Et il doit être visuel. Et c'est aussi une des choses que j'apprécie beaucoup, c'est de visualiser les choses, de noter les problèmes, de noter les options, de noter mon analyse, de rendre tout très visuel. Nous avons l'event storming, le domain storytelling, le user story mapping, l'example mapping, toutes ces choses. Je regarde aussi différentes industries, par exemple j'utilise souvent le business model canvas pour comprendre l'entreprise. Quels sont les objectifs, comment gagnons-nous de l'argent, qui sont nos clients ? Parce que j'ai aussi besoin de ces informations lorsque j'essaie de redessiner le système, car cela influencera mes options. Donc n'importe quel outil peut être utilisé. Et puis la question est, oui, mais combien d'informations ? Parce que je ne peux pas continuer à faire ça indéfiniment.
[00:34:48] Donc, à partir du moment où certaines informations ne vous font plus changer d'avis, elles n'ont plus vraiment de valeur. C'est trop de temps et trop d'argent parce que notre temps est payant, je pense, pour moi, que nous investissons en ce moment pour essayer de prendre cette décision.
[00:35:05] Euh, donc je me suis arrêté là. Ce n'est pas une chose facile à évaluer. Et parfois, on passe un peu de temps et on réalise que l'information que j'obtiens actuellement ne me fait plus changer d'avis, elle n'est plus utile. Euh, alors nous arrêtons. Donc nous faisons aussi un peu trop d'informations. Mais euh, pas assez. J'ai déjà dit que nous avions besoin d'options et d'alternatives. Je n'ai pas dit comment j'y suis arrivé quand je conçois un système logiciel.
[00:35:48] Accroissons la tension dans la pièce, comme, oh, comment elle fait ça ?
[00:35:55] J'ai donc conçu des alternatives. C'est quelque chose que je n'ai pas vu faire souvent dans les entreprises. Ils proposent une conception logicielle et c'est tout. Ils l'appellent le 'à être'. Et ils ne proposent pas plus d'options que cela. C'est la même chose lorsque nous concevons nos modèles de domaine pour le code, lorsque nous regardons dans l'équipe, nous essayons de comprendre comment nous pouvons intégrer cela dans notre code, nous le concevons une seule fois.
[00:36:24] Et nous faisons une seule chose, et c'est ensuite la solution. Malheureusement, ces solutions n'existent pas. Il existe de nombreuses solutions et nous essayons de trouver la plus utile pour nous. Alors, je vais faire quelque chose comme ça, oh, en fait ça sépare le back office, ça sépare les paiements. Pour l'instant, même lorsque nous refaçonnons un monolithe. Et le plus amusant, c'est qu'une fois que vous avez deux designs, il est très facile d'en obtenir d'autres. Donc, une fois que vous avez deux alternatives, générer d'autres alternatives n'est en fait plus si difficile. Et là, vous vous demandez peut-être, mais combien ? Et la plupart du temps, optez pour trois.
[00:37:09] Quand je regarde, vous savez, nous devons ajouter, à un moment donné avec l'un des clients, j'avais besoin d'ajouter un système ERP dedans, et donc j'ai fait trois designs sur la façon dont nous pourrions réellement l'intégrer. Et la raison en est que je veux éviter une situation de nous contre eux. Et si vous n'avez que deux options, vous pouvez très facilement, vous savez, obtenir cette division, alors que si vous avez trois options, les gens sont plus dispersés et cela ne devient plus nous contre eux. Je ne sais pas si vous avez déjà été en conflit sur quelle technologie. Où vous avez juste deux groupes et ils attaquaient en fait les gens au lieu de penser, vous savez, nous parlons en fait des technologies. J'essaie donc d'éviter cela un peu, car c'est un gâchis plus difficile à nettoyer que de redessiner un système logiciel. Et quand les relations au travail se sont mal formées. Comment je fais ça ? J'utilise en fait des heuristiques. En gros, c'est encore une définition très ennuyeuse et très longue. Nous connaissons les heuristiques, nous en parlons comme d'une règle empirique. Mais la raison pour laquelle je vous donne cette définition de la croyance sur le cool, euh, c'est parce que c'est une aide plausible qui vous apportera une solution à un problème, mais qui, en dernière analyse, est injustifiée, incapable de justification et faillible. Cela signifie donc que la solution que je peux trouver pourrait ne pas être la bonne. Mais j'utilise l'heuristique de conception pour créer mes options là-bas. La bonne nouvelle est que que les heuristiques fonctionnent en fait aussi bien que de faire des analyses plus approfondies sur les problèmes. Par exemple, euh aux urgences, ils ont une heuristique pour déterminer si quelqu'un fait une crise cardiaque ou non.
[00:39:09] Et la raison en est que si vous faites une crise cardiaque, vous devez être traité très rapidement. Et donc ils ont une liste de contrôle et si vous avez six sur huit ou quelque chose comme ça, ils vont vous traiter comme si vous faisiez une crise cardiaque, même s'ils ne le savent pas à ce moment-là. Et ils ont découvert que c'est en fait plus bénéfique que de faire des tests qui prennent du temps. Donc cette heuristique sauve plus de vies que si nous nous asseyions et, vous savez, faisions plus de tests pour voir si cette personne fait une crise cardiaque. Donc elles sont faillibles, mais ne donnent pas nécessairement de moins bons résultats. Donc je pense que c'est une excellente nouvelle.
[00:39:47] Alors ce que je fais, c'est que je décompose en limites. Je commence par une de mes techniques de modélisation collaborative, dans ce scénario, je vous montrais un event storm. Et ensuite j'ai commencé à diviser en limites et j'ai appliqué mes heuristiques de conception en conséquence. Par exemple, l'une des heuristiques de conception que j'ai est que nous mettons la communication des systèmes externes dans une limite différente. Et nous avons obtenu les paiements de cela, la première option que les paiements séparés. Redesign, je vous ai montré comment ça a été obtenu. Il y a une autre présentation sur la façon de bien faire la conception. Je parle de la partie décision.
[00:40:30] Euh, donc je ne vais pas trop entrer dans les détails de la conception des limites. Comme je l'ai mentionné, nous avons écrit un livre à ce sujet intitulé 'Conception de logiciels collaboratifs'. où vous pouvez tout lire sur la façon dont nous utilisons ces heuristiques pour le faire. Et la dernière chose dont nous avons besoin pour une décision est la préférence. Vous pouvez également utiliser des heuristiques basées sur la valeur ici. Par exemple, quelqu'un pourrait se soucier beaucoup du changement climatique et de l'environnement, et cela pourrait en fait changer sa préférence pour les options que vous avez créées. Vous avez besoin de préférences. Parce que si vous ne vous souciez pas du futur que vous allez obtenir, encore une fois, vous n'avez aucune décision à prendre. Autant lancer une fléchette sur les options et choisir celle-là puisque vous vous en fichez. Nous avons donc besoin de préférence. J'ai fait une interview il y a quelque temps sur la facilitation des décisions d'architecture logicielle. Euh, et j'ai dit quelque chose que je pensais n'avoir jamais dit dans ce sens auparavant. J'ai dit, après 20 ans dans l'industrie, j'ai trouvé un moyen de parler des émotions sans réellement parler des émotions. Et c'est de cela qu'il s'agit la préférence. Vous essayez de voir, pourquoi cette personne veut-elle vraiment passer aux microservices ? Qu'est-ce qu'il y a derrière et souvent, ils ont eu une mauvaise expérience avec le monolithe. Euh, donc ils ne veulent pas reconcevoir le système en un monolithe, parce qu'ils ont peur que ça ne finisse encore par un gâchis. En parlant de préférences plutôt que d'options, j'obtiens en fait des informations dont nous ne sommes pas très susceptibles de parler. Parce que nous devons nous soucier de la décision, donc ce n'est pas mauvais. Alors nous avons une sorte de logique. Vous savez, pour se résumer à une seule option, cela doit être là.
[00:42:28] En ce qui concerne la technologie, j'ai fait une présentation à ce sujet. J'ai en quelque sorte essayé de créer un processus qui est assez simple à réaliser, mais qui est un peu plus structuré que la façon dont nous choisissons les piles technologiques de nos jours. Vous pouvez le trouver via le code QR. Quand il s'agit de conception logicielle, je peux utiliser à nouveau des heuristiques. Elles sont vraiment bonnes pour prendre des décisions rapides là-bas. Si vous avez déjà entendu parler de choses comme le rasoir d'Ockham ou le rasoir d'Hanlon, les lois sur lesquelles est basée la pensée systémique. Alors ce sont des heuristiques pour prendre des décisions rapides car elles vous enlèvent des options. Euh, donc si deux modèles concurrents ont tous deux un pouvoir explicatif égal, il est plus probable que la solution simple suffise. Donc si nous créons plusieurs modèles de domaine pour notre code, alors nous pouvons en fait choisir celui, vous savez, s'ils ont un pouvoir explicatif égal, alors nous pouvons choisir le simple et donc nous n'avons plus vraiment à penser aux autres que nous avons conçus. Nous pouvons aussi utiliser des heuristiques pour cela. Ou si nous voulons faire un peu plus d'analyse. L'économie parle de probabilité à ce stade, mais je n'ai pas trouvé cela très utile en conception logicielle. Euh, j'utilise la liste pro/con. Euh, en gros, c'est un outil visuel. Ça m'aide à réfléchir à, d'accord, quels sont les points positifs de ce design et quels sont les points négatifs de ce design. Euh, mais ce qui le rend le plus intéressant, c'est la partie 'correction' de cela. Ça vous fait en quelque sorte réfléchir à la façon dont nous pouvons faire en sorte que ces choses négatives aient moins d'impact sur nous.
[00:44:20] Par exemple, si nous passons aux microservices et que nous allons travailler soudainement dans une architecture événementielle. Alors l'un des inconvénients est qu'en fait, nous n'avons jamais fait cela auparavant, nous n'avons aucune connaissance à ce sujet. Et puis une des choses que nous pouvons faire est, vous savez, euh, organiser un déjeuner où nous avons résolu les choses ensemble, ou nous pouvons envisager une formation et demander un budget, ou nous avons un budget dans notre équipe pour réellement nous éduquer. Ainsi, nous pouvons faire en sorte que cette chose négative ait moins d'impact. Et je trouve ça très utile. Vous ne le transformerez jamais en quelque chose de positif, mais vous pouvez le faire avoir moins d'impact. Et nous ne pensons pas vraiment à tout ça, alors comment pouvons-nous faire des choses qui améliorent réellement cela ? Et puis quand nous faisons ça pour toutes nos options, vous savez, on continue d'entendre dans notre industrie, tout est un compromis. Mais les gens ne savent pas vraiment quel est le compromis. Et donc si vous remplissez cela pour vos options, alors c'est essentiellement tout ce que vous obtiendrez de l'option un et rien de ce que vous obtiendrez de l'option B et c'est le compromis que j'obtiens en choisissant un design plutôt qu'un autre. Et c'est très visuel et c'est très clair et tout le monde comprend quel compromis il fait réellement en avançant. Je l'ai déjà mentionné si vous voulez approfondir un peu plus cela. Utilisez le code QR. Je publierai mes diapositives après cela. Et puis quand on fait ça pour toutes nos options, vous savez, nous continuons d'entendre, vous savez, dans cet arbre, tout est un compromis. Mais les gens ne savent pas vraiment quel est le compromis. Donc si vous remplissez cela pour vos options, alors c'est essentiellement tout ce que vous allez obtenir de l'option un et rien de ce que vous allez obtenir de l'option B, et c'est le compromis que j'obtiens en choisissant un design plutôt qu'un autre. Et c'est très visuel, et c'est très clair, et tout le monde comprend quel compromis ils sont en train de faire en allant, euh, de l'avant. J'ai déjà mentionné ceci, si vous voulez approfondir un peu, euh, cela, le code QR. Je publierai mes diapositives après, euh, ça. Alors, quand faire quoi, quand utiliser l'heuristique et quand faire une analyse. Euh, si vous avez des connaissances limitées et un temps limité, vous pouvez utiliser l'heuristique. Ils n'utilisent pas, euh, de pires résultats. Si nous avons des connaissances limitées, car vos connaissances sont toujours limitées, euh, mais nous avons du temps, vous pouvez faire une analyse un peu plus approfondie.
[00:46:23] Et puis la question devient, combien de temps ?
[00:46:27] Et puis je dois dire, ça dépend, parce que je suis consultante.
[00:46:32] Mais je n'en reste pas là. J'en dis plus que ça. D'un point de vue économique, il est acceptable d'investir un million de dollars pour prendre une décision d'un milliard de dollars. Donc, si c'est quelque chose qui va réellement coûter beaucoup d'argent à votre entreprise, il est acceptable de passer beaucoup de temps à analyser le problème, à essayer de, à essayer de faire cela. Et donc si nous avons des problèmes aléatoires et indéterminés où le jugement joue en fait un si grand rôle sur le fait, nous pouvons consacrer plus de temps, nous pouvons prendre le temps d'essayer de repenser notre système, euh, là. Ce qui renvoie à ce modèle que vous utilisez, et ensuite vous pouvez communiquer mieux pour expliquer pourquoi il vaut la peine de ralentir, euh, pendant un certain temps. Et pour vraiment réfléchir à la façon dont nous allons aborder cela.
[00:47:32] La deuxième façon d'aborder cela est de vous poser la question : cette décision est-elle irréversible ou réversible ? Euh, parfois appelée porte à sens unique ou à double sens. Euh, en gros,
[00:47:50] mais avec notre définition d'une décision où nous avons, la décision n'est plus un point dans le temps, c'est maintenant un processus que nous traversons de conception, d'obtention d'alternatives, d'obtention d'informations, de discussion sur les préférences, sur ce processus. Et nous savons que si nous payons le prix, nous pouvons changer d'avis. Il ne reste plus beaucoup de décisions irréversibles pour votre équipe. Si vous êtes prêt à payer le prix. Et puis au lieu de se dire, oh, devrions-nous changer d'avis à nouveau, vous vous dites, sommes-nous, sommes-nous prêts à faire cela, l'information, la nouvelle connaissance que nous avons est-elle suffisamment précieuse pour revenir à l'analyse et voir si nous avons changé d'avis, en gros ? Donc, j'ai une bonne nouvelle, à moins que ce ne soit une décision qui mettra votre entreprise en faillite, ce qui est irréversible,
[00:48:42] la plupart des décisions sont réversibles. Et c'est une façon très différente de penser, car cela aide vraiment à gérer le stress et l'anxiété lorsque vous devez prendre ce type de décisions. au travail parce que je ne peux pas changer d'avis, je peux me tromper sur l'option que j'ai choisie, je peux revenir en arrière en cours de route.
[00:49:06] Et la raison pour laquelle j'ai dit que vous travaillez toujours avec des connaissances limitées, c'est à cause de l'incertitude. Et ce n'est pas quelque chose auquel tout le monde est habitué, mais chaque décision est prise avec un certain niveau d'incertitude. Et parfois ce niveau d'incertitude est très, très, très bas, et parfois l'incertitude est très élevée. Et encore une fois, lorsque nous parlons de problèmes indéterministes, parce que c'est du jugement, l'incertitude est plus élevée que si nous avions un problème simpliste parce que, je veux dire, je pourrais me tromper de réponse à la question.
[00:49:40] Mais je peux facilement, vous savez, corriger ça. Et nous devons apprendre à gérer cette incertitude, et nous ne sommes pas très bons pour la gérer. J'ai une heuristique clairvoyante que j'utilise, euh, si je pouvais poser une question à une personne clairvoyante afin de me sentir confiant pour prendre cette décision, quelle serait cette question ? Et j'essaie de formuler cette question et ensuite je vais chercher l'information, voir si je peux trouver l'information, euh, à cette question. Et le moment où je me dis que je ne voudrais vraiment plus rien demander, c'est le moment où je sais que je peux réellement commencer à éliminer, euh, des options. En équipe, j'investis en quelque sorte dans la certitude. Euh, donc je commence avec eux en cartographiant de un à 10, à quel point vous vous sentez réellement confiant en prenant cette décision à ce moment-là ? Et puis à un certain moment, je demande à nouveau, et si je remarque que, vous savez, la confiance ne monte plus, alors je me dis, vous savez, l'information que nous obtenons est sans valeur, et je devrais essayer autre chose ou je devrais arrêter et commencer à éliminer les options là.
[00:50:52] Donc les décisions peuvent être faciles ou difficiles. Si je veux choisir une saveur de crème glacée, c'est une décision très facile. Si je veux acheter une maison, vous savez, c'est un peu plus difficile. Certaines choses sont très difficiles. Et donc l'incertitude détermine en fait si quelque chose est plus facile ou plus difficile à faire ; si vous avez une décision difficile à prendre, alors vous devriez y consacrer plus de temps. Euh, j'ai des amis qui ne prennent pas de décisions faciles et même pour une glace, il faut y réfléchir cinq minutes et c'est assez frustrant, alors j'essaie de leur faire découvrir l'heuristique. Euh, on verra si ça aide. Nous avons du réactif, une décision peut être réactive ou proactive.
[00:51:40] En matière de conception logicielle et de refactoring, la plupart de ce que j'ai vu sont des décisions réactives. Et cela signifie que quelque chose s'est produit et que nous devons maintenant réagir. Et la plupart du temps, c'est ça, non ? Nous avons une grosse boule de boue et maintenant nous devons réellement corriger cela, le code n'est plus facile à refactoriser et maintenant nous devons le corriger. Donc la plupart des décisions que je vois dans les équipes et les logiciels sont réactives. Le proactif fonctionne différemment. C'est je veux quelque chose ou nous voulons quelque chose.
[00:52:11] Euh, donc maintenant nous devons prendre une décision pour que cela devienne une réalité. Et il est important de comprendre quel type de décision c'est. Parce que si vous êtes réactif, le temps dont vous disposez pourrait ne pas être le même que lorsque vous êtes dans une situation proactive. Dans une situation proactive, rien n'est urgent, je peux donc prendre plus de temps. Dans une situation réactive, il y a de la pression, il y a des émotions, euh, souvent les gens sont frustrés, euh, des choses comme ça, vous savez, donc je pense que c'est précieux. Et donc ce n'est pas l'un ou l'autre. C'est plutôt une échelle, en fait, plus proactif ou plus réactif. Mais comme je l'ai dit, la refonte logicielle, j'ai constaté qu'elle est toujours plus réactive que proactive. Et vous devriez vraiment, vous savez, examiner votre entreprise et voir quel est le principal mode par défaut que nous avons pour prendre des décisions, sommes-nous en mode réactif ou en mode proactif ? Et si vous êtes en mode réactif, demandez-vous comment nous pouvons commencer à changer cela au sein de mon équipe, comment puis-je réellement commencer à prendre des décisions proactives, car c'est une situation beaucoup plus détendue dans laquelle se trouver.
[00:53:24] Et une décision peut être bonne ou mauvaise.
[00:53:30] Alors, j'ai un exemple, ça implique, euh, la conduite en état d'ivresse, mais c'est la meilleure façon que j'ai de l'expliquer. Euh, alors Laura a beaucoup bu, mais elle décide de rentrer chez elle quand même, elle perd le contrôle de son volant et heurte un arbre et est, euh, blessée. Je pense que nous sommes tous d'accord que c'est une mauvaise décision. D'accord. Deuxième scénario, Laura a beaucoup bu, mais elle décide de rentrer chez elle quand même, elle rentre chez elle en toute sécurité sans aucun accident. Je pense toujours que nous sommes tous d'accord que la conduite en état d'ivresse est une mauvaise décision.
[00:54:07] Alors Laura ne boit pas du tout, puis elle rentre chez elle et arrive en toute sécurité sans aucun accident. Hourra, bonne décision. Et Laura ne boit pas du tout, mais elle perd le contrôle de son volant et heurte un arbre et est blessée. Et en quelque sorte, c'est le moment où les gens se disent, c'est une mauvaise chose parce qu'elle a été blessée. Du genre, eh bien, non, parce qu'elle n'a pas bu, euh, du tout, et elle est rentrée chez elle et c'est, c'est ce que nous décidons. Donc la mauvaise nouvelle, c'est qu'une bonne décision ne garantit pas un bon résultat. La bonne nouvelle, c'est qu'une mauvaise décision ne garantit pas non plus un mauvais résultat. Et quand on parle de bonnes ou de mauvaises décisions, ce que je remarque, c'est que les gens ne comprennent pas qu'il y a la qualité de la décision et ensuite il y a le résultat. Et parce que nous avons de l'incertitude, il n'y a aucune garantie que nous l'aurons. Alors j'essaie de juger la décision, ce qui signifie, tous les éléments étaient-ils présents avec leur preneur de décision, euh, étaient-ils engagés, avaient-ils la permission, y avait-il un processus, avaient-ils plus de quelques options ? Et si tous ces éléments étaient là et si nous avons pris le temps, alors nous avons pris une bonne décision et nous avons un mauvais résultat à cause de l'incertitude. Et cela aide aussi à raisonner, euh, à ce sujet quand on ne dit pas que nous avons pris une mauvaise décision.
[00:55:38] Donc c'est ce qui est pour moi une bonne décision, je l'ai un peu expliqué là quand je regardais l'autre diapositive. Donc si les six éléments étaient là, et que nous avons fait du bon travail, c'était une bonne décision, nous avons juste eu de la malchance.
[00:55:54] Et j'essayais d'expliquer ça et c'est un peu difficile jusqu'à ce que j'entre dans le monde du poker et comment ils, vous savez, jouent au poker et comment ils placent des paris là-bas. Et je suis tombé sur ce terme et ça s'appelle le "resulting". Et cela signifie essentiellement d'assimiler la qualité de votre décision à la qualité de votre résultat. Donc vous regardez le résultat et vous dites, eh bien, la décision était une mauvaise décision, ce qui n'était pas nécessairement vrai. Et c'est très important au poker de pouvoir faire la distinction entre cela. Quelqu'un pourrait toujours avoir une meilleure main, mais vous avez fait le bon mouvement. Et donc, quand vous commencez à confondre la qualité de votre décision avec la qualité de votre résultat, ils appellent cela le "resulting". Je suis donc très heureuse d'avoir maintenant un mot pour cela, et je peux dire aux gens que en fait, le Mulaner n'était pas une mauvaise idée, ce n'était pas une mauvaise décision, c'est juste que nous avons eu un mauvais résultat, et vous êtes, euh, en train de faire du "resulting". Donc je veux remettre Mulanelist sur la table comme option. Je le dis d'une manière beaucoup plus polie que cela.
[00:56:56] Au fait. Et vous pourriez vous demander, alors pourquoi s'embêter ?
[00:57:03] Et pour moi, c'est pour deux raisons. Avoir cette, vous savez, décision comme un processus crée de la clarté. Clarté pour moi et mon processus de pensée, mais aussi clarté pour tout le monde. Je peux expliquer quelle décision j'ai prise, quelles options j'ai envisagées et pourquoi, au final, j'ai choisi une option plutôt qu'une autre.
[00:57:26] Et la deuxième est la cohérence. Donc si vous avez ce processus, comme je vous ai montré le processus de refonte d'un système logiciel où j'utilise l'heuristique pour concevoir des options, et j'utilise les listes pour et contre pour voir ce qui est mieux. Et donc si vous faites cela, vous créez une cohérence au sein de votre processus de prise de décision et vous l'améliorez toujours un petit peu, euh, un peu plus. Parce que vous savez maintenant où une décision était mauvaise et comment l'améliorer. Et donc avec le temps, vous verrez que la qualité générale de vos décisions augmente, et donc la qualité de votre résultat s'améliore également, euh. Parce que nous y avons plus réfléchi, nous ne nous sommes plus contentés de suivre la mode ou la dernière tendance. Et donc j'obtiens de la cohérence dans ma prise de décision. C'est pourquoi je peux réellement, euh, vous savez, accélérer, encore une fois, avec le temps, vous vous retrouverez à prendre des décisions d'une manière similaire, euh. Et ça aide vraiment.
[00:58:34] Merci à tous d'avoir assisté à ma conférence. J'espère que vous avez appris quelque chose. Je suis là jusqu'à demain vers quatre heures, alors n'hésitez pas à venir discuter si vous avez des questions.
[00:58:54] Une question.
[00:59:00] Merci.
[00:59:39] comment je gère, euh, euh, les problèmes d'ego ? Très doucement. Euh, et j'essaie d'avoir, la plupart du temps, un entretien individuel. Je ne pense pas, euh, que des choses comme ça, il y a toujours quelque chose en jeu et j'essaie de le trouver, euh, les gens étant têtus sans bonnes raisons, j'ai souvent senti que ce n'était pas le cas. Nous en sommes de nouveau à ces préférences, à ces heuristiques basées sur des valeurs, nous en sommes de nouveau aux émotions, dont nous ne sommes pas autorisés à parler. Euh, alors j'essaie d'avoir une conversation ouverte et honnête et de vraiment écouter cette personne, ça s'appelle l'écoute active, on en parle un peu dans le livre aussi là-bas.
[01:00:30] Et voir, vous savez, quel est réellement le problème ici ? Euh, et aussi une chose, euh, si quelqu'un d'autre prend la décision, par exemple si ce n'est pas votre préférence que nous suivons, ce que nous oublions souvent, c'est de poser la question, de quoi avez-vous besoin pour nous suivre ? Par exemple, vous ne voulez pas réévaluer cette décision, elle a échoué, mais de quoi avez-vous besoin pour me suivre ici afin que nous puissions faire cela ? Et puis souvent on obtient de bonnes réponses, et il faut en tenir compte, on ne peut pas simplement ignorer tout ce qui a été dit. Parce que j'ai vu ça arriver avec des patrons aussi, ils demandent votre avis et ensuite ils ignorent complètement votre avis. Alors ne faites pas ça. Euh, mais ça aide la plupart du temps.
[01:01:21] Euh, pour avancer un peu. Alors oui.
[01:01:24] Donc la prochaine session est les deux dernières. Bon appétit. Nous sommes en France.

Transcription (Traduit)