Regis Medina - Entraîner les Avengers - Oubliez tout ce que vous savez sur le management tech (FR)

[00:00:05] Alors, d'où je viens, moi je je suis sorti de l'école en 95. Donc je suis un ingénieur programmeur. Et je suis rentré dans le monde du travail avec une une rencontre assez violente sur sur ce que c'est que la réalité d'un projet logiciel. La première année, en fait, de de travail pour moi, j'ai fait 50 jours des weekends des jours fériés, en trop. J'ai vécu le moment où j'arrive le lundi matin à 9h, je repars, je finis ma journée le mardi à 17h, après avoir codé toute la nuit pour corriger des bugs. Et alors, ça va pas toujours être aussi violent que ça. Mais grosso modo, ça m'a ça m'a fait tout voir tout de suite en fait ce challenge qu'on a, c'est comment est-ce qu'on fait de la qualité en allant très très vite. Alors, du coup, c'est en tant que que vieux con que je vous parle. Et ce que j'ai ce que j'ai, alors je continue à rester dans dans le monde de la tech, et ce que j'ai vu, c'est que le seul truc qui est changé depuis cette époque-là, c'est euh la forme et la taille des écrans. Alors, euh la réalité en fait du du développement, c'est toujours en fait, on a pas le temps, on a pas le temps. Il faut aller vite, il faut aller vite, il faut aller vite. On a pas le temps, on fera la qualité plus tard. Ça ça vous parle? Vaguement? Euh et ça crée en fait une espèce de de dynamique que j'ai modélisé comme ça, que que j'ai modélisé dans ma tête au moins enfin très très tôt. Euh qui est en fait, on démarre, il y a un nouveau projet. Alors c'est génial, c'est une nouvelle équipe, c'est une nouvelle techno, on repart sur une base propre, ça va être vraiment le bonheur. Puis on construit, on build, on est très très content ce qu'on fabrique. Et puis au bout d'un moment, on commence à nous dire, bah oui, mais là les cocos, vous êtes gentils mais il va falloir accélérer. Et puis là il va falloir accélérer. Et puis bon bah là, écoutez, on a plus le temps de faire propre, il faut que ça sorte. Ça ça vous parle? Et du coup, bah là il faut prendre des raccourcis. Et puis c'est pas grave, on fera propre plus tard. Et ce qui se passe, c'est que bon, on a le bol. Il y a quelques anciens qui commencent à partir. Comme ça va assez vite, on recrute, on remet plein de devs qui comprennent rien dans l'équipe. Ça vous parle? Oui. Et au bout d'un moment, en fait, on se retrouve avec une une base de code pourrie. La bonne nouvelle, c'est que ceux qui l'avaient conçu initialement sont partis. Et il va se passer un moment où il y a quelqu'un qui va dire, écoutez, par rapport à ça, c'est une vieille technologie, il faut qu'on prenne, il faudrait redémarrer. Voilà. Alors j'ai j'ai passé les, je veux dire, les 12 15 premières années de de ma carrière à me nourrir de ça. Ça ça un peu cynique mais euh je vais y venir. Mais je me suis toujours demandé est-ce qu'on peut pas faire un petit peu mieux?
[00:02:39] Et euh et grosso modo en fait, c'est un c'est un sujet pour moi de recherche depuis 27 ans, donc ça fait 27 ans que que je vois les projets informatiques. J'en ai vu deux ou trois. Euh et ce que j'ai fait c'est que au cours de ma carrière, au début c'est un coup de bol, maintenant c'est vraiment délibéré. En fait, j'ai posé en fait des pierres blanches pour montrer en fait mes niveaux de mes niveaux de compréhension qui évoluaient. Donc je vais vous raconter vite fait mon parcours pour vous expliquer comment j'en suis arrivé là. Il y a eu toute une phase d'extreme programming, donc j'ai fait partie des trois quatre premiers français à découvrir ça à la fin des années 90. Euh et j'ai vécu à à cette époque-là, enfin dans cette période, donc je fais mon premier projet, je dirais XP, peut-être en 2000. Et j'ai vécu un peu plus tard le moment vous savez où on a codé un petit truc, on est trois. Tout d'un coup les grands chefs disent, bon bah voilà, il y aurait tout ça à faire, ça coûte combien? On envoie les estimations et le lendemain, ça revient en disant, écoutez, c'est simple, il faut que vous soyez 22.
[00:03:41] Euh donc j'ai vécu le moment où on est trois dans l'équipe à la fin de l'année, en fin décembre, et on est 22 à la mi-mars, avec la moitié des développeurs d'ailleurs qui ont jamais codé. Euh et alors j'ai j'ai fait j'ai j'ai je suis allé très très loin dans cette compréhension de ce qui est devenu après l'agilité, mais que j'avais pris sous l'angle technique. Euh jusqu'à réaliser que au bout d'un moment que avoir des équipes tech qui marchent, c'était vaguement faisable, mais que le vrai problème, c'était bah tout le reste de la boîte. C'est que ça sert à rien d'avoir une équipe de dev qui dépotte. Si on on parle pas au client, si on comprend pas les besoins, où est-ce que ce que je veux dire? Et ce truc là fait que vers je dirais vers les années 2007 2008, j'ai pris une décision délibérée de faire contrôle alt sup et de de sortir de la tech pour aller voir ailleurs. Et aller voir ailleurs, en fait, j'avais rencontré des gens à l'époque qui s'intéressaient de très près au lin. Euh et j'ai pris la décision de d'explorer le lin au sein d'un d'un cabinet de conseil. J'ai dû suivre de près ou de loin, je passe 100, 150 projets d'amélioration en tant que consultant lin, vous savez que la cravate, le costume. Euh et initialement, ce que j'imaginais, c'était que le Lin était de l'Agile un peu mieux. Et je cherchais dans dans le Lin une recette un peu plus passe partout qui me permettrait de faire de l'agile partout dans la boîte. L'agile dans les ventes et cetera. Après, je suis passé par une phase où je pensais que c'était un process ou un une mécanique d'amélioration des process. Euh et la claque que je me suis pris à cette époque-là.
[00:05:27] Et pour comprendre d'où vient la claque, ce ma mission en fait, c'était de faire l'aller-retour en permanence entre les métiers de l'IT, tous les métiers de l'IT, le support, la maintenance, les data centers, les projets et de faire le retour entre ça et ce que j'appelle aujourd'hui le Lin hardcore à la japonaise, c'est-à-dire aller au fond de ce qu'a fait Toyota.
[00:05:46] Pour essayer de comprendre qu'est-ce qu'on pouvait apprendre de ce monde-là qui avait rien à voir avec la tech. Je crois que j'ai mis les pieds dans une usine pour la première fois à 38 ans. Mais je faisais en permanence l'retour pour comprendre qu'est-ce qu'on a à apprendre de ces gens-là. Euh parce qu'en fait, initialement, je pensais qu'ils étaient dans notre passé et de plus en plus, maintenant, je suis convaincu que ces gens-là sont dans notre futur. Pour nous, qu'ils ont la tech. Et la claque que je me suis prise, c'est de comprendre que le Lin c'est pas une façon d'améliorer les process, c'est pas une méthode d'amélioration continue, en fait, c'est une pratique personnelle. C'est une pratique personnelle pour le dirigeant. Et ça c'est un truc que j'ai décrit dans un bouquin qui s'appelle Learn to Scale. Euh et à l'époque où je commençais à faire de de du line, pardon, c'était vraiment des projets dans des grosses boîtes. Et dans ce cheminement où j'ai compris que c'était une méthode pour les gens, ce que j'ai réalisé, ce qu'on m'a enseigné aussi.
[00:06:40] C'est que le Lin, c'est une pratique pour le dirigeant. Il y a une personne qui fait du Lin dans la boîte, avant tous les autres, c'est le dirigeant. Euh je vais revenir après sur ce que ça veut dire. Donc ça c'est ce que j'ai documenté dans dans Learn to Scale, qui est une espèce de de bouquin de la méthode. L'étape d'après, ça a été de comprendre, ça c'était il y a deux trois ans maintenant.
[00:06:58] De comprendre que cette méthode n'est c'est pas une méthode, c'est pas une amélioration des process, c'est une pratique personnelle, mais en fait au-delà de ça, c'est un nouveau modèle d'entreprise. Euh et c'est pour moi et pour mes co-auteurs, le seul modèle crédible alternatif au modèle térroriste financier qui est en train de vous fait toutes nos boîtes et qui font que euh bah tous là, on est en train d'essayer de fuir les grandes boîtes pour se réfugier dans des start-ups qui quand elles deviennent des scale-up, sont presss de redevenir des grosses boîtes. bah tous là, on est en train d'essayer de fuir les grandes boîtes pour se réfugier dans des start-ups qui quand elles deviennent des scale-up, sont pressées de redevenir des grosses boîtes. Vous voyez? Et donc l'idée c'est de de donc ça c'est apprendre l'apprendre avec le lin, c'est de de comprendre que en fait, il y a vraiment un autre modèle d'entreprise qui est possible. L'étape d'après, ça a été de de travailler avec des gens pour le faire pour de vrai, donc je fais ça depuis 2016. Je suis pas le seul, je fais partie de l'institut de France, on est on est plusieurs à à pratiquer ça, essayer de porter le flambeau. Je suis pas le seul, je fais partie de l'institut de France, on est on est plusieurs à à pratiquer ça, essayer de porter le flambeau. Euh on a écrit il y a on a publié il y a il y a pas très très longtemps un bouquin qui s'appelle Rage de Bar, qui est en fait euh c'est c'est les deux fondateurs d'Aramis Auto, Nicolas Chartier, Guillaume Pauli, qui racontent leur aventure et qui racontent leur appropriation de cette méthode de management mais vraiment du point de vue de toute l'entreprise. On parle d'une vraie entreprise, c'est une entreprise qui est rentrée en bourse il y a pas très longtemps, qui fait plus d'un milliard de de chiffre d'affaires.
[00:08:15] Alors, il y a il y a une astuce dans Race the bar dans le titre, de la même manière qu'il y a une astuce dans Learning to Scale. Et qui va ça va m'aider en fait pour la suite. L'astuce dans Learning to scale dans le titre, c'est que on imagine souvent que c'est je vais apprendre à faire du scale. Et en fait non, c'est pas du tout ça l'intention, c'est le learning, c'est l'apprentissage est un levier de scale. Et donc la question de comment est-ce que je grandis, comment est-ce qu'une entreprise grandit sans devenir une grosse boîte pourrie, c'est qu'en fait, on arrive à maintenir l'apprentissage vivant. Ce que font les boîtes d'entreprise modernes, c'est qu'elles tuent l'apprentissage parce qu'elles essaient de mettre tout le monde dans des petites boîtes. Vous voyez? Et donc là ce qui est passionnant dans Race the bar, c'est qu'on voit des dirigeants qui ont qui adoptent ça comme modèle d'entreprise pour créer une entreprise qui est fondée sur le fait que tout le monde apprend tous les jours. Et il y a un deuxième deuxième astuce dans le titre. C'est que Raise the bar, on imagine que c'est Raise the bar sur l'entreprise. Et en fait, ce que fait vraiment le praticien Lin, c'est qu'il est en permanence en train de raise the bar lui-même. Et donc c'est une méthode d'auto amélioration. Alors, il y a un petit, il y en a un qui est en train de couver. Euh on est en train de de finaliser, ça devrait sortir d'ici la fin de l'année. Un bouquin pas équivalent, mais dans dans la même veine sur euh les pratiques line des dirigeants de de tout le groupe Théo. que vous connaissez, qui sont des des habitués ici. Et et là encore, l'idée c'est pas de montrer comment est-ce que Théo a mis en place la pratique line, la discussion c'est comment est-ce que les dirigeants euh de Théo s'approprient cette façon de penser ou cette façon, cette façon d'être en tant que manager. Et et là encore, l'idée c'est pas de montrer comment est-ce que Théo a mis en place la pratique line. La discussion, c'est comment est-ce que les dirigeants euh de Théo s'approprient cette façon de penser ou cette façon, cette façon d'être en tant que manager, pour réussir leur boîte. Ce qui m'amène au au machin.
[00:09:51] Alors c'est quoi le Lin? Euh il y a tout un il y a beaucoup de flou autour de ça. Ce qu'on appelle le Lin, c'est l'étude du modèle de management Toyota en dehors de Toyota. Mais ce qu'on appelle aussi le Lin, c'est la pratique de ce qu'on appelle euh le le le TPS, donc le Thinking People System. Euh et donc c'est un c'est une pratique délibérée en fait pour le manager. Donc l'idée c'est que c'est pas un truc que je plaque dans la boîte. C'est je j'accélère ma progression en tant que manager en me forçant à réfléchir sous le prisme du TPS. Alors, une façon de le voir, c'est imaginez que vous passiez euh à partir de maintenant, vous lancez un chronono et vous allez commencer à réfléchir sérieusement, vous documenter, tester plein de trucs pour essayer de construire une entreprise qui est centrée sur le client et qui est centrée sur l'apprentissage de tout le monde, tous les jours, partout. Imaginons que vous fassiez ça pendant 10 ans, 20 ans, 30 ans. Le TPS, c'est ce que vous aurez envie de vous raconter quand vous parlerez à votre mois d'aujourd'hui. Vous voyez ou pas? Et donc ça a rien à voir avec l'usine, ça ça marche partout. On n'a pas trouvé d'activité humaine dans lequel le modèle ne fonctionnait pas. Et il faut le voir vraiment, c'est moi je ça c'est le karaté du business. C'est ou c'est c'est l'équitation. Quand on regarde en fait le le management, le management en fait est une activité qui a une complexité inouïe, inouïe.
[00:11:15] C'est que si je suis tech lead, si je suis CTO, il faut que je maîtrise les technologies, il faut que je maîtrise le business, il faut que je sache construire une organisation, faut que j'ai des connaissances en en management opérationnel, de performance, faut que j'ai des théories sur la qualité, il faut que j'ai des théories sur la motivation des gens, sur la psychologie, sur la gestion du conflit, sur la négociation. Vous voyez ou pas? Maintenant, une fois qu'on a vu ça, regardez euh comment est-ce qu'on est formé pour devenir manager. Ça ça vous fait rire ou pas? Non? Il y a que moi que ça fait rire? Ils sont tristes les gens.
[00:11:48] Euh et l'idée c'est de se dire bah soit en fait la la pratique du du TPS, c'est soit je me dis bon bah je vais bidouiller euh Ah, j'ai lu un super truc, ils font ça chez Netflix, je vais essayer. je le fais comme ça, je tâtonne. Euh soit en fait, je comprends qu'en fait le management c'est un les humains font ça depuis très très longtemps, il y a des choses qu'on sait, il y a une physique du management. Et du coup, je vais me former pour accélérer ma formation. Donc euh c'est une façon de réfléchir qui à force et mesure qu'on s'entraîne à voir à travers le TPS, change la façon dont on voit les choses. Et euh je vais vous faire une démonstration. Vous vous reconnaissez des machins comme ça? Vous en avez déjà vu?
[00:12:27] Alors du coup c'est intéressant de se dire qu'est-ce que je vois là-dedans?
[00:12:33] Euh alors je je suis désolé, mais je vais vous dire vraiment ce que je pense quand je vois ça. Euh le premier truc que je me dis, c'est euh le timideur est un salaud d'exploitant.
[00:12:45] Non?
[00:12:48] Euh en fait, je me dis ça parce que quand je regarde la structure du camban, la priorité, elle est donnée au fait que les choses avancent dans le process parce qu'il faut chiper, il faut chiper. Par contre, on voit pas les gens.
[00:12:59] Oui, il y a un petit petit là. Mais le truc est pas fait pour voir les gens, en fait, il est fait pour chiper des pièces. Et je me dis, bah ça c'est l'exploitant, c'est on rigole hein, quand je dis ça, je le connais pas et on peut mais j'imagine que c'est quelqu'un de très bien. Mais mais en fait là ce que je vois, c'est que c'est un système dans la pensée en fait, c'est il faut que ça sorte, il faut que ça sorte. Expliquez-moi pourquoi ça sort pas et je vous explique pourquoi vous allez le sortir quand même. Je force un bien sûr un peu le trait, j'essaie de vous faire voir quelque chose. Deuxième truc que je me dis, c'est bon, ils ont vraiment pas envie d'être bons. Ils ont envie de progresser. C'est évident, vous voyez ou pas?
[00:13:35] Alors ce qui me fait dire ça, c'est que en fait, on voit pas le lead time.
[00:13:40] Donc en fait, on est en train de regarder du flux, mais on est pas en train de regarder si en fait si on va vite. Et donc on sait pas, c'est est-ce qu'on va plus vite qu'avant, est-ce qu'on va pas plus vite qu'avant? Non, parce qu'en fait, on s'intéresse pas à mesurer le délai. Or le délai, c'est la métrique qui fait que bah si je suis plus fort, je vais plus vite hein, c'est pas.
[00:13:57] Troisième truc que je me dis, euh c'est en fait dans cette équipe, ils ont vraiment absolument pas l'intention de faire la qualité un jour. Euh Alors pourquoi je me dis ça? Pourquoi je me dis ça?
[00:14:08] Je me dis, en fait, ils ont une théorie foirereuse de la qualité. C'est-à-dire qu'ils se disent que pour faire de la qualité, il faut que je rajoute des phases d'inspection. Et donc ils sont en train de refaire exactement ce que faisait Ford dans les années 50. Mais sauf que comme en fait, on n'étudie pas le passé, ben on reproduit, vous savez, l'histoire de ceux qui étudient pas l'histoire sont condamnés à la répéter.
[00:14:30] Je vais pas expliquer le pourquoi de la qualité tout de suite. Vous tenez le coup ou pas? Qui reste?
[00:14:35] Ouais, vous restez. OK, d'accord. Bon je continue. J'ai prévu de me faire sortir mais je sais pas quand dans le dans dans la conférence. J'ai prévu de me faire sortir mais je sais pas quand dans le dans dans la conférence. Donc c'est pour ça, je regarde les organisateurs. Et ce que je me dis surtout, c'est que ces gens-là, en fait, ils ont peut-être fait une erreur qui est de prendre juste un bout du TPS, qu'ils ont appelé ça le Camban, sans comprendre deux choses, sans comprendre que ça fait partie d'un système global et donc si on tire un bout du système, tu sais, si je prends un souris que j'ouvre et je tire le cœur, il marche plus hein. Donc le ils sont l'erreur là, c'est de prendre un bout du système sans comprendre le l'ensemble. Mais surtout l'erreur de ma fenêtre hein, mais c'est moi qui ai le micro. L'erreur c'est de d'imaginer de d'utiliser ce système sans comprendre son intention. Alors du coup, ça pose la question, bah c'est quoi l'intention du fameux Camban? Ça sert à quoi ce machin là? Alors du coup, ça pose la question, bah c'est quoi l'intention du fameux Camban? Ça sert à quoi ce machin là? Et donc le camban n'est pas une méthode pour accélérer le flux, c'est pas une méthode pour pour améliorer la production. Je vous taquine hein, je vous taquine.
[00:15:38] C'est une méthode pour faire quoi? Alors pour vous expliquer ça, il faut que que je revienne à des conneries que je racontais dans le bouquin gestion de projet Extreme Programming. J'assume, j'assume, mais j'étais jeune, c'était pour l'argent. Euh donc j'avais écrit, je crois qu'en 2000, peut-être 2001, j'avais écrit un truc dans dans un des chapitres, j'avais dit en fait,
[00:15:59] euh du point de vue du client, en fait, on pour par rapport à une équipe de de dev, en fait, on peut te donner de la qualité, un truc nickel qui marche bien, on peut te on peut le faire vite. Ou tu peux avoir une large enveloppe fonctionnelle. Par contre, Coco, tu peux pas avoir les trois. Euh donc ça c'est le genre de conneries que je racontais quand quand j'étais jeune. Euh donc ça c'est le genre de conneries que je racontais quand quand j'étais jeune. Euh en fait, j'ai j'ai j'ai j'ai changé un peu de façon de de réfléchir à ça. Euh le fait d'être bercé euh par le lin un peu trop près du mur, m'amène à voir maintenant la chose un peu différemment, c'est que je je comprends, je modélise l'équation d'avant comme.
[00:16:36] En fait la valeur, c'est la qualité au sens à quel point je je rends service au client divisé par le coût global. Et donc je préfère cette notion de coût global plutôt que délai. Parce que si j'oppose qualité et délai. Ça me donne l'impression que le game c'est d'aller vite. Mais en fait, le le fait d'aller vite est juste une des composantes de le faire pour pas cher. Vous voyez ce que je veux dire? Et si je le capture sous l'angle d'aller vite, ça me ça me ça me pousse à la faute au sens, je vais essayer de prendre des raccourcis sans voir le coût global. Et ce que j'entends par coût global, c'est OK, ça va coûter combien à faire? Est-ce qu'on peut le faire vite pour le coup? Est-ce que est-ce que on va réduire les coûts de maintenance? Est-ce qu'on va réduire les coûts de de de formation des gens qui vont l'utiliser? Est-ce qu'on va réduire le les coûts du support d'entreprise? Vous voyez? Et donc l'erreur selon moi quand on quand on raisonne en qualité délai uniquement sur le dev, c'est que mécaniquement, ça nous emmène à créer des problèmes, à faire croire qu'on va vite pour en fait juste créer d'autres problèmes dans dans l'entreprise, qui fait que on est très fier parce que avec 10 personnes, on a on a chipé le truc très vite, mais on n'a pas vu qu'on a forcé la boîte à recruter 50 personnes au support parce que il y a rien qui marche. qui fait que on est très fier parce que avec 10 personnes, on a on a chipé le truc très vite, mais on n'a pas vu qu'on a forcé la boîte à recruter 50 personnes au support parce que il y a rien qui marche.
[00:17:49] Une fois qu'on a vu ça, ce que j'ai fini par comprendre, c'est que la maîtrise des coûts, la réduction des coûts, c'est c'est ça l'expertise. Et ce que fait un ingénieur, c'est qu'il fait de la réduction de coût tout le temps.
[00:18:00] Alors, c'est peut-être choquant, présenté comme ça. Mais reprenez maintenant la discussion que vous avez quand vous faites les sessions d'estimation.
[00:18:07] Quand vous faites des sessions de conception technique, la nature de la conversation, c'est comment est-ce qu'on fait un truc qui marche, qui marche pour longtemps et pour pas cher. Vous voyez, c'est cette tension là, il faut il faut comprendre que c'est la nature de l'activité de conception. Donc on est tout le temps en train de se battre sur comment est-ce que je rends le service au client et comment est-ce que en rendant ce service au client, je réduis le coût. Et c'est ça le quelque part la métrique de de d'une équipe de def. Vous voyez? Ce qui est intéressant là-dedans, d'ailleurs, c'est que ça nous donne aussi une orientation de développement professionnel. C'est-à-dire que je deviens meilleur parce que j'augmente ma ma productivité, en fait, c'est le vrai terme. Et je le fais parce que je comprends de plus en plus finement le besoin du client. Parce que si j'ai pas compris ce qu'il veut, je fais des trucs un peu trop larges qui coûte très cher et qui reste pour voir ce que je veux dire. Donc je je me développe en tant qu'ingénieur parce que je comprends de plus en plus finement ce qui est important, ce qui est moins important. Et de l'autre côté, je développe ma capacité à trouver des méthodes ingénieuses pour réduire le coût global. Et alors du coup, ça nous donne une feuille de route euh pour ce que fait un CTO. Et alors du coup, ça nous donne une feuille de route euh pour ce que fait un CTO. Donc l'erreur, c'est d'imaginer que en fait, on peut pas avoir la qualité, la vitesse, la fonctionnalité. En fait, c'est faux, c'est qu'on peut avoir les trois. On peut faire un truc de super qualité, très très vite, qui couvre tous les besoins du client. En fait, il faut juste être très très fort. Je vais juste être très très fort. et je le fais parce que je comprends de plus en plus finement le besoin du client. Parce que si j'ai pas compris ce qu'il veut, je fais des trucs un peu trop large qui coûterait très cher et qui reste, vous voyez ce que je veux dire? Donc je me je me développe en tant qu'ingénieur parce que je comprends de plus en plus finement ce qui est important, ce qui est moins important. Et d'autre côté, je développe ma capacité à trouver des méthodes ingénieuses pour réduire le coût global. Et alors du coup, ça nous donne une feuille de route pour ce que fait un CTO. Donc l'erreur, c'est d'imaginer que en fait, on peut pas avoir la qualité, la la vitesse, la fonctionnalité. En fait, c'est faux. C'est-à-dire qu'on peut avoir les trois. On peut faire un truc de super qualité, euh très très vite, qui couvre tous les besoins du client. En fait, il faut juste être très très fort. Euh, j'ai un de mes meilleurs amis, qui est un un ancien collègue aussi, que j'ai rencontré en 98. C'est un 24 ans, je sais pas si vous avez beaucoup de copains depuis 24 ans, mais euh, qui en fait euh, est rentré chez un éditeur dans le monde de la finance. ils avaient fait un premier projet avec six personnes pendant 6 mois pour faire un truc un peu compliqué de calcul de risque sur des volumes très très importants de données en quasi temps réel. Une première équipe de six, c'était plantée. Ils avaient tout jeté, ils avaient arrêté. Ils ont remonté une équipe de quatre qui a essayé pendant deux mois, ils ont arrêté. Ils ont recruté Marc qui l'a fait avec un autre mec en deux mois. Donc la productivité, en fait, elle est elle est mesurable. Vous voyez? Et donc c'est quoi quand une fois qu'on a compris ça, c'est quoi le rôle du dirigeant du manager lean? Le rôle du manager lean, enfin pardon, du tech lead manager tech, qui fait du lean, c'est de entraîner ses gars de façon à ce qu'ils développent leur capacité, leur productivité, leur capacité à bien comprendre le client, à réduire les coûts. Vous voyez? Maintenant la question c'est comment est-ce qu'on fait ce machin là? Et ce qu'on voit habituellement quand quand les gens commencent à se mettre au lin, qui commencent à faire des standards, c'est que ils écrivent des trucs qui ressemblent à ça. Alors, comment est-ce que tu fais une peer review, code review? Euh d'abord, il faut faire ça. Ce qui est vachement intéressant, c'est le c'est la formulation. Il faut faire, tu dois faire ça, tu dois faire ça, tu dois faire ça. Vous voyez ce que je veux dire? C'est par l'outil. Donc je suis en train, les personnes là comprennent pas qu'elles sont en train de former. Elles sont en train de forcer les gens à faire des choses. Vous le sentez ça ou pas? Tu fais ci, tu fais ça, tu fais ça. Et ce qui est intéressant quand on va regarder ce standard, c'est que la partie intéressante y est pas. par exemple, vérifier que le code répond bien aux besoins fonctionnel et qu'il est bien organisé en conséquence. Bah, mais c'est ça, c'est ça le game. Vous voyez? Et donc ce qu'on voit là, c'est des gens et c'est sympa qu'ils essaient de faire ça, ils sont ils sont au début du chemin, je leur en veux pas. Mais ce qui se passe, c'est qu'ils sont un stade de leur compréhension où en fait, ils nous disent bah en fait, je sais pas comment former les mecs, je sais pas comment y prendre. Du coup, ce que j'arrive à faire seulement, c'est dicter des règles. parce que c'est un peu le bazar dans les équipes et j'espère que s'il y en a quelques standards, quelques règles, les gens vont arrêter de faire n'importe quoi. Vous voyez? Et alors du coup, l'idée c'est que si on veut dépasser ça, une fois qu'on a compris que euh la clé de la productivité au sens noble du terme euh c'est la compétence. bah l'idée du dirigeant tech, c'est que ce qui le distingue, ce qui distingue le contributeur individuel du manager, c'est que le contributeur individuel, il sait faire du code. Le manager, il sait former des contributeurs individuels à faire du code. Vous voyez? Parce que sinon si si juste je me retrouve tech lead ou CTO mais je ne sais pas former, je suis juste contributeur individuel qui a un droit de vie et de mort sur les autres.
[00:22:22] Mais j'apporte pas vraiment de valeur. Vous vous voyez le truc? J'en apporte bien sûr parce que je suis plus avancé mais Mais en fait l'idée c'est que j'apprends à être un meilleur euh manager tech, à parce que je développe des des façons de penser sur comment est-ce que je fais monter les gens en puissance. Alors le premier truc à à avoir pour ça, d'où d'où euh le titre.
[00:22:42] Donc la première idée fausse qu'il faut tuer, c'est l'idée que on va transformer les équipes en des petits robots qui font tous pareil. On va trouver les best practices, s'assurer que tout le monde fait les mêmes base practice et enfin, c'est le délire terroriste ça. Enfin, tout le monde fera pareil partout tout le temps. Mais il faut comprendre que c'est pas comme ça que ça fonctionne la formation. Ça marche ça marche en dehors du knowledge work. Sur des activités très répétitives, il y a pas besoin de réfléchir. Oui, on peut mettre un couvercle aux gens, contrôler les mains. Mais en fait, ce truc là ne marche pas pour le travail intellectuel. Pour le travail intellectuel, l'idée c'est que c'est une progression qui se fait de l'intérieur. Pour le travail intellectuel, l'idée c'est que c'est une progression qui se fait de l'intérieur et chacun va devenir la meilleure version de lui-même. Et donc l'idée c'est d'avoir dans comme modèle que en tant que manager tech, mon rôle c'est d'aider les gens à à se développer, en étant tout à fait à l'aise sur le fait que ils vont tous se développer différemment. parce que je suis en train de me faire mon équipe d'Avengers. Ils sont tous bizarres, vous êtes d'accord qu'ils sont tous bizarres. Ils sont tous cassés d'un certain point de vue, ils ont tous chacun sa névrose, mais c'est une névrose différente par personne. Vous voyez? Donc le premier truc, c'est d'arrêter d'imaginer que en fait, on met les gens dans des cases et on les force à faire tout pareil. Et après l'idée, c'est de les faire progresser. Et alors comment est-ce qu'on va les faire progresser? Alors on a un modèle pour ça. Euh le modèle du maître artisan, vous savez,
[00:23:57] euh du craft. Alors quand je dis ça, je je voudrais pas tomber dans l'ornière du software craftsmanship, même si c'est des potes, hein. Mais ce que j'essaie de de de montrer, c'est plus que en fait, on a une façon de transmettre un geste expert. Et ce que je voudrais faire, c'est rentrer un peu dans le détail de comment ça fonctionne. La clé, c'est de faire ce qu'on appelle la pratique délibérée. Donc si vous voulez apprendre à faire de la guitare ou du tennis, l'idée, c'est que vous apprenez parce que vous par une répétition, mais une répétition en essayant de bien faire. Vous voyez un peu la tension, euh, faut imaginer le mec qui fait des services, qui fait des services.
[00:24:32] C'est pas n'importe quelle répétition. Si je si je fais des services au hasard, j'apprendrai pas, je peux en faire des des centaines d'heures. Le truc qui marche, c'est quand je fais mes fameux services, en essayant de faire bien.
[00:24:44] Alors, si on décompose les les les les différentes composantes de de de d'une bonne pratique délibérée, euh il y a plusieurs éléments. Le premier élément, c'est la production. Donc l'idée, c'est que j'apprends en faisant. Alors, une erreur qu'on fait souvent, c'est de se dire, euh un bon, un bon ingénieur, il sait faire des trucs, il a des théories, machin, puis il y a des bons, il y a des mauvais. On peut rien faire avec ça. On peut pas former quelqu'un en disant, bah vas-y, sois meilleur. L'astuce, c'est que j'apprends par le craft, c'est-à-dire que j'apprends en produisant. Et la beauté du truc, c'est que je vois dans ce que j'ai produit, mon niveau.
[00:25:22] Vous voyez? Et donc ce que fait le le le le maître artisan, c'est qu'il produit des choses et il le regarde en se disant, je vois là-dedans ce que je sais faire. Alors, comment est-ce qu'on fait euh comment est-ce qu'on devient un grand écrivain? Bah le grand écrivain, il écrit des bouquins. Comment est-ce que je deviens un grand musicien? Bah, je compose des putains de morceaux et je joue des morceaux et je fais des spectacles. Vous voyez? Et du coup, bah, comment est-ce que je deviens un bon ingénieur? Bah, je fais du code. Par contre, il faut rentrer un peu dans le détail de ce que c'est que que le code. Donc c'est pas faire des user stories ou faire du code en général, pour se développer, il va falloir commencer à avoir une liste assez précise de qu'est-ce que je produis. Vous voyez? Donc le début de prendre en main ça sa sa sa propre progression, c'est de commencer à se dire, je fabrique des routes d'API. Donc le début de prendre en main ça sa sa sa propre progression, c'est de commencer à se dire, je fabrique des routes d'API, je fabrique des tests unitaires, je fabrique des estimations, je fabrique des conceptions techniques. Et l'idée c'est de commencer à voir sa progression dans la qualité des trucs qui sont produits.
[00:26:21] Deuxième truc, c'est que je vais pratiquer en produisant en me comparant en permanence à ce qu'on appelle un standard. Alors, il y a une une tragédie dans le line, c'est que les gens interprètent le standard du line comme on va tous bosser pareil, c'est la base practice que qu'on doit imposer à tout le monde, c'est pas du tout le cas. Ce qu'on appelle un standard en ligne, il faut le voir, c'est un peu le maître étalon. Euh un standard, c'est j'ai un repère qui me permet de savoir si je suis en train de déconner ou pas.
[00:26:43] Vous voyez? Donc l'idée c'est qu'on se met d'accord, pas sur ce qu'il faut faire, on se met d'accord sur qu'est-ce que c'est que OK. En acceptant que bah à chaque fois on essaie de trouver des des compromis. Vous voyez ou pas? Là par exemple aujourd'hui, il y avait des problèmes de de transport, l'équipe organisatrice, elle doit démarrer à telle heure, elle doit démarrer à telle heure, mais la réalité c'est que bah il y a des grèves. Vous voyez ce que je veux dire? On peut pas leur dire qu'est-ce qu'il faut faire. On peut leur donner des repères en se disant, ben, il faut que les gens ils ont quand même une pause. Vous voyez? Donc on pense au standard comme des références. qui permettent aux gens de garder leur leur jugotte et garder leur esprit d'adaptation, sans avoir un fantasme de les faire tous bosser pareil. Et alors, des des des standards, j'en ai montré un avec cette fameuse intention. Et alors des des des standards, j'en ai montré un avec cette fameuse intention. Et donc le la façon dont je me le raconte aujourd'hui, c'est que celui-là il marche pas parce qu'il essaie de contrôler les mains de la personne. Il dit fais, c'est ça qu'il faut que tu fasses avec tes mains. Et pour comprendre quelle serait l'alternative, il faut remonter un peu sur comment comment est-ce que ça fonctionne l'expertise et comment est-ce qu'on fait de la production avec le machin qui est là-haut. et comment est-ce qu'on fait de la production avec le le machin qui est là-haut. Alors la la machine de base de de la façon dont on réfléchit, c'est ce qu'on appelle des modèles mentaux. Donc là par exemple, quand vous voyez l'image, euh vous quand la personne va relâcher son index, vous voyez tout ce qui va se passer. Vous êtes d'accord ou pas? Et en plus de ça, selon l'angle avec lequel il va taper le domino, vous pouvez presque imaginer, est-ce que ça va partir comme ça, comme ça? Vous voyez ou pas? S'il le fait doucement, s'il le fait fort, s'il fait très fort, le truc va rebondir. Vous voyez? Ce qu'on on est tous d'accord, il s'est rien passé, vous êtes d'accord?
[00:28:22] C'est pareil, si je fais ça que j'écarte les doigts, vous savez ce qui va se passer. Si je fais ça, ça va rebondir, vous voyez? Et donc l'idée c'est que la façon dont on réfléchit, c'est qu'on a des modèles.
[00:28:30] qui représentent la façon dont le monde fonctionne. Et donc la notion de standard, la notion de geste qui nous permet de comprendre le line dans le monde de la tech, en fait, ne fonctionne que si on arrive à revenir dans une logique de je comprends le geste expert qui est la façon dont la dans la personne réfléchit. Et euh un exemple dans la tech, c'est de se dire par exemple, bah, il y a quelqu'un qui va dire, bah tiens sur l'Apple là, quand je clique pour poster le formulaire.
[00:28:56] En fait, l'ingénieur, lui, il sait que euh ce truc là va être interprété par le navigateur, qui va envoyer une HTTP request. Vous voyez ce que je veux dire? Donc il a son son ego, euh vous voyez ce que je veux dire? C'est des mécanismes qui tournent dans sa tête.
[00:29:09] ses mécanismes qui tournent dans sa tête. Euh, d'ailleurs, ce qu'on appelle un bug, ça c'est des études très scientifiques qui le qui le démontrent. Euh ce qu'on appelle un bug, c'est que j'ai codé un truc parce que je pensais que en fait non, c'est pas du tout comme ça que ça marche. Vous voyez? Donc ça veut dire que ce qu'on appelle un bug, Vous voyez? Donc ça veut dire que ce qu'on appelle un bug, c'est que j'avais un modèle mental erroné, ce qui ne représentait pas la réalité, c'est-à-dire que j'ai j'ai lâché les doigts, le truc est remonté. Vous voyez? Alors ça c'est important de de de comprendre ça parce que former les gens, c'est euh je on peut pas le faire de l'extérieur, c'est eux qui se forment et en fait c'est c'est des c'est se développer des modèles mentaux de plus en plus riches. Et donc l'idée c'est que une fois que j'ai compris ce que je produis des pièces on va dire très précises, mon apprentissage consiste à me faire des modèles manteaux de plus en plus riches sur chacune des pièces en cherchant des différents trucs. Ce qui va m'intéresser en particulier, c'est toutes les contraintes, ou mieux encore ce qu'on appelle les trade-offs. Euh, pour pour vous compreniez cette notion de trade-off, j'ai un exemple très simple. Euh, je sais pas si si ça arrive encore, mais j'ai vécu dans ma jeunesse le moment où on disait il faut pas faire de méthodes de plus de 25 lignes, il faut les découper. Et puis c'est trop long. Et en fait, ce qui est intéressant, c'est qu'au début, donc j'ai une très grande fonction, puis je vais découper en plein de petites fonctions, et après en fait, comme je passe mon temps à me déplacer dans chaque petite fonction pour essayer de comprendre ce qui se passe, en fait, le code est devenu de plus en plus pourri, de plus en plus difficile à comprendre.
[00:30:35] Donc j'ai un trade-off. Vous voyez ou pas? J'explore le truc. Il y avait un gars sur un un des projets je travaillais avec un avec un copain qui était sur un projet, il disait on est parti sur un truc, on a fait des micro services, on est allé au fond du fond du fond. on est parti sur un truc, on a fait des micro services, on est allé au fond du fond du fond. Mais après on a découvert un truc, c'est que bah en fait le réseau est saturé. Je dis, bah. Oui. Tu pouvais le savoir avant ça, non? Vous voyez ce que je veux dire? Donc l'idée c'est que je gère mon apprentissage parce que je capture ce que je sais, pas sur ce que je dois faire, mais je capture comment est-ce que les choses fonctionnent. Et l'idée c'est que grosso modo, ce que fait un ingénieur qui veut vraiment être fort, c'est qu'il commence à collecter consciemment ses modèles mentaux de qu'est-ce qui marche, qu'est-ce qui marche pas, qu'est-ce que c'est que bien faire, qu'est-ce que c'est que pas bien faire. ce que fait un ingénieur qui veut vraiment être fort, c'est qu'il commence à collecter consciemment ses modèles mentaux de qu'est-ce qui marche, qu'est-ce qui marche pas, qu'est-ce que c'est que bien faire, qu'est-ce que c'est que pas bien faire. Et en fait, une équipe qui veut vraiment apprendre, c'est une équipe dans laquelle c'est pas l'équipe qui le fait, c'est chacun est en train d'avoir son petit carnet où il collecte au fur et à mesure ce qu'il a appris sur la façon dont les choses fonctionnent, sur sa propre interprétation des des trade-off. Donc il capture des modèles mentaux. Euh, je capture des des modèles d'authentification, les forces, faiblesses des uns et des autres. Vous voyez ce que je veux dire? Je gère mon savoir. Pour un petit coup.
[00:31:52] L'autre truc, c'est que une fois que je suis en train de gérer mon savoir, euh je vais m'entraîner à l'enrichir et à et à l'incorporer en fait par la répétition. Et en fait, c'est à ça que sert le le Camban. C'est que le Camban, c'est que je reçois des demandes, des pièces et qui vont me montrer et qui vont me dire, bah il y a du craft à faire dans cette zone là. Et donc je regarde l'astuce avec le Camban un sens, quand chaque personne dans la boîte dans ou dans l'équipe, ne voit pas le truc comme juste encore une todo, mais comme voit chaque tâche qui arrive, comme une opportunité de d'approfondir euh ces ces modèles manteaux, de comprendre comment résoudre ce problème là dans ce contexte particulier. de comprendre comment résoudre ce problème là dans ce contexte particulier. Le dernier le quatrième élément qu'il faut pour faire de la pratique délibérée, c'est qu'il faut le feedback du coach. Parce que si j'apprends à faire un nouveau geste, mais que j'ai pas de feedback externe, je vais développer très rapidement des mauvaises habitudes. mais que j'ai pas de feedback externe, je vais développer très rapidement des mauvaises habitudes et je vais pas me voir faire. Et du coup, pour apprendre vite, si c'est mon intention, il faut que j'ai quelqu'un en face. qui puisse me dire, bah tiens, baisse les épaules, lève le nez. Vous voyez? Alors pour ça, il faut un certain type de manager. Alors, je sais pas si vous êtes familiers avec ce ce modèle. Euh c'est un modèle grosso modo de d'apprentissage, j'arrive dans n'importe quel domaine, je commence par être un incompétent inconscient. Euh c'est-à-dire que c'est ce qui se passe typiquement pour le management. C'est-à-dire que j'en sais tellement peu sur le management que je crois que je fais bien. Vous voyez ce que je veux dire? Et du coup, quand j'en suis là, bah il faut que je vois un vrai manager que je me dise, ah merde, c'est un vrai métier ce truc là. Et du coup, quand j'en suis là, bah il faut que je vois un vrai manager que je me dise, ah merde, c'est un vrai métier ce truc là! Mais en fait, je suis nul. Ouais, bravo parce que du coup tu peux commencer à bosser pour passer à l'étape 2 qui est je vais m'entraîner, m'entraîner, m'entraîner jusqu'à ce que je enfin et donc ça c'est incompétent inconscient. C'est-à-dire que je sais que je suis nul, mais je me soigne, c'est beaucoup mieux, les pires, c'est les incompétents inconscients. Mais je sais si je sais que je suis pas très bon et que je suis en train de me former, c'est très très bien. Et à force, je vais arriver à un stade où je suis compétent mais inconscient.
[00:33:45] C'est-à-dire que j'arrive à faire les trucs avec une très grande dextérité, par contre, je sais pas expliquer pourquoi. Et c'est l'état dans lequel se trouve la plupart des tech leads, des managers techniques, des CTO. Et c'est l'état dans lequel se trouve la plupart des tech leads, des managers techniques, des CTO. C'est-à-dire qu'ils savent faire, mais par contre, ils savent pas expliquer, ce qui fait que quand ils sont devant les devant les gens, ils leur disent bah attends, je t'ai expliqué cinq fois, tu es trop con, qu'est-ce qui t'arrive, dégage.
[00:34:03] Bah non, en fait, c'est que moi je sais pas former. Et donc l'idée c'est que le système de pratique délibérée fonctionne quand j'ai compris en tant que manager que mon métier, c'est qu'il fallait que j'apprenne à former. Et que le niveau des gens de mon équipe, c'est mon niveau de formateur. Vous voyez ce que je veux dire? Et alors pour faire ça, il y a une phase qui est très très très difficile, c'est qu'il va falloir passer de compétent inconscient à compétent conscient, c'est-à-dire que je sais faire du code et je sais expliquer pourquoi. je sais faire du code et je sais expliquer pourquoi. Le le la figure de de de pro de d'extreme programming dans les années 90, c'était Kenbeck. Il m'a fallu très longtemps pour comprendre ça en fait. J'ai pas compris pourquoi l'agilité donnait des trucs un peu moyens en fait at scale. En fait l'extreme programming marchait avec Kenbeck, avec Martin Flower, avec Bob Martin. C'est-à-dire que quand on a les gens qui sont très très forts, bah oui, l'agilité marche. La question c'est comment est-ce qu'on devient très très fort? Mais si vous regardez les gens que je viens de mentionner, qu'est-ce qu'ils font? En fait, ils écrivent leur savoir. Ils réfléchissent. Vous voyez? Donc quand vous lisez le Refactoring de Martin Faller, vous voyez en fait un maître artisan qui est en train d'expliciter sa théorie pour apprendre à l'enseigner. Donc il est en train de s'infliger le quelque part la pratique qui va lui permettre de faire de lui quelqu'un qui sait former les autres. le quelque part la pratique qui va lui permettre de faire de lui quelqu'un qui sait former les autres. Donc il est sur un trac pour devenir manager. Et c'est pareil là que du coup, on comprend à quoi sert le Camban. Donc l'idée du Camban, c'est que je suis le manager, j'ai une image mentale de tous les gens de mon équipe, je connais leurs forces, leurs faiblesses, je sais quel point je suis en train de faire travailler chacun. Et du coup, j'envoie des Cambans à untel, untel. Et du coup, j'envoie des Cambans à untel, untel parce que je sais ce que j'en attends. Vous voyez ce que je veux dire? Je sais que là, j'envoie ça parce que ça va le développer là-dessus. Je sais que là, j'envoie ça parce que ça va le développer là-dessus.
[00:35:50] Le dernière composante d'un d'un système de pratique délibérée, c'est l'envie d'apprendre. Parce que tout ça, je peux répéter, je peux répéter, je peux répéter, si j'ai pas envie. Bah, il va juste rien se passer.
[00:36:02] Et je vais ce qui va se passer aussi, c'est que je vais vivre mon travail. Si si j'arrive au travail sans l'envie d'apprendre, je vais vivre mon travail comme une espèce de routine répétitive qui fait que je vais aller chercher des addictions bizarres, des nouvelles techno, des salaires meilleurs. Vous voyez ce que je veux dire? Faut essayer de combler le le le gouffre de de ce que sont mes journées. Et alors pour une fois qu'on a compris ça, ça éclaire aussi le rôle du manager. Euh l'idée c'est que le manager tech, il a grosso modo trois challenges. Le premier, c'est de d'éveiller chez chaque personne de l'équipe l'envie d'apprendre. Et c'est son job. C'est son job au moins de pas l'éteindre, c'est son job de donner envie aux gens de progresser, de se dépasser. Pour faire ça, le moyen le plus puissant, c'est de le faire en démontrant sa propre son propre acharnement à se progresser. Pour faire ça, le moyen le plus puissant, c'est de le faire en démontrant sa propre son propre acharnement à se progresser. Je suis en train de lire, j'écris, je me forme, je mets à jour mes standards. L'idée c'est que je le montre en tant que leader aux gens de mon équipe parce que je veux les inspirer. Et aussi parce que euh, je me vois pas enseigner des trucs que je ne pratique pas moi-même, ça s'appelle du charlatanisme. Vous voyez?
[00:37:09] Donc l'idée c'est que je n'ai pas de légitimité à demander aux gens de l'équipe de se former ardemment si je suis pas en train de le faire moi. Donc deuxième élément c'est que je je je montre que je suis un rôle modèle d'apprentissage et de de de maîtrise. c'est que je je je montre que je suis un rôle modèle d'apprentissage et de de de maîtrise. Et le troisième sujet, c'est que je gagne un deal, et souvent c'est un truc que les gens voient pas. Et le troisième sujet, c'est que je gagne un deal, et souvent c'est un truc que les gens voient pas. c'est que les pour que le système fonctionne, il faut que la personne en face, la personne de l'équipe m'accepte en tant que coach. Et quand vous allez regarder dans les équipes, bien souvent en fait, les développeurs n'acceptent pas leur tech lead ou leur manager leur manager tech en tant que coach, ce qui fait que ça crée une une tension énorme. Tu devrais faire comme ça, tu devrais faire comme ça, la personne résiste parce qu'en fait, ce qu'on n'a pas craqué, c'est le c'est cet accord qui peut qui peut être implicite, cet accord qui est que en fait, je suis ton prof. c'est cet accord qui est que en fait, je suis ton prof. Vous voyez? Un des trucs dans lequel on est parti avec l'agilité. aujourd'hui je pense que c'est une connerie mais c'est vraiment une une opinion personnelle, c'est d'imaginer que l'apprentissage se fait en équipe. Puis on discute, il se passe des trucs. Mais c'est pas comme ça que font les humains. Bien sûr que ça génère de l'apprentissage hein. Mais le le chemin royal l'apprentissage, c'est je trouve quelqu'un qui fait ça depuis 10 ans plus que moi. Mais le le chemin royal l'apprentissage, c'est je trouve quelqu'un qui fait ça depuis 10 ans plus que moi, je regarde ce qu'il fait et il m'aide à monter, vous voyez? On fait ça dans tous les domaines. Euh.
[00:38:22] Et donc l'idée c'est que il faut en tant que leader que je me fasse accepter par chacun en tant que coach. Il faut que je gagne le fait que la personne n'ait envie de bosser et il faut que j'ai envie d'apprendre pardon et il faut que je gagne aussi l'envie qu'elle m'accepte comme comme source de de progrès. Ah!
[00:38:37] On va pouvoir parler de lin.
[00:38:42] Donc je posais la question tout au début, à quoi sert le Camban? Donc le Camban, il sert à un truc dans le cadre du TPS et c'est quoi le TPS? Donc le TPS, c'est un modèle mental ce que j'utilise en tant que dirigeant pour développer l'apprentissage dans mon activité, dans mon organisation. Et c'est un truc que je fais, que je m'applique à moi, je réfléchis à travers le TPS. Et c'est un truc que je fais, que je m'applique à moi, je réfléchis à travers le TPS et je ça m'aide en fait à transformer le délivery de tous les jours en opportunité d'apprentissage pour tout le monde. Vous voyez, c'est ça l'intention finale. Vous voyez, c'est ça l'intention finale. C'est une méthode pour faire ça. Alors très rapidement en quoi ça ça consiste. Bah le premier truc, c'est que je comprends que. le la finalité de tout ça, c'est on devient meilleur euh parce qu'on crée plus de valeur.
[00:39:30] Donc vous voyez ce que je veux dire, on a une métrique, on a une heuristique, c'est-à-dire que on est une meilleure équipe si on crée plus de valeur. Au moins l'étoile du Nord est est posée. Et qu'est-ce que ça veut dire euh créer plus de valeur? Ça veut dire je un, je comprends de plus en plus finement la qualité parce qu'en fait, on va faire des du code, on va faire des produits qui tape exactement là où il y a besoin et qui mettent pas d'énergie ailleurs. Et en même temps, de l'autre côté, je suis en permanence en train de réduire les coûts. Euh et quand je dis ça, réduire les coûts, c'est choquant dans notre monde, ce qui est triste, mais parce que c'est un génieur en fait, je trouve des solutions ingénieuses. qui fait qu'avec trois lignes de code, je crée énormément de valeur chez le client. Et l'idée c'est que je fais ça au niveau global de l'app, mais j'apprends à le faire petit à petit sur chaque test. Et l'idée c'est que je fais ça au niveau global de l'app, mais j'apprends à le faire petit à petit sur chaque test. Où est la valeur dans un test? Où est la valeur dans un écran? Où est la valeur, vous voyez ce que je veux dire? Et donc c'est c'est une pratique délibérée qui est orientée vers la satisfaction client par l'amélioration de la valeur. Où est la valeur, vous voyez ce que je veux dire? Et donc c'est c'est une pratique délibérée qui est orientée vers la satisfaction client par l'amélioration de la valeur.
[00:40:23] Une fois que je comprends ça, il faut que je m'entraîne et je m'entraîne sur des pièces. Vous voyez? Donc je fais des tâches. parce que c'est mon moyen de de m'entraîner. Et ces tâches là, c'est pour ça que je parlais de time tout à l'heure. Et ces tâches là, c'est pour ça que je parlais de time tout à l'heure, bah j'apprends à les faire de plus en plus vite du point de vue du client parce que c'est comme ça que je vois si je suis en train de progresser. Et alors du coup, c'est là que j'ai besoin du cambant, mais pas d'un cambant organisé comme ça, il va me falloir un cambant qui est organisé par personne. Puisque je suis le coach de l'équipe, ce que je regarde, c'est l'équipe, c'est pas les pièces. Puisque je suis le coach de l'équipe, ce que je regarde, c'est l'équipe, c'est pas les pièces. Je regarde d'abord l'équipe, chaque membre de l'équipe, et après je regarde quelle pièce j'ai envoyé à quel membre de l'équipe. Et je vais aller un cran plus loin, donc c'est du pool, c'est un pool system. Donc pool c'est du prélèvement. L'erreur dans le dans le modèle que je présentais avant, en général, c'est du push, on pousse le truc à l'étape d'après, on pousse le truc à l'étape d'après. Le pool, c'est un peu différent, c'est que en fait, on va venir prélever. c'est que en fait, on va venir prélever. À quoi ça ressemble très très concrètement au quotidien dans l'équipe, on a trois développeurs là. Pardon. On a trois développeurs. On a euh concrètement à droite, là, on a Justine. Donc je sais en tant que tech lead que Justine est en train de travailler sur cette tâche. On a fait le travail ensemble en amont où on a analysé tout ce qu'elle allait faire, tout ce qu'il faudrait faire pour faire cette tâche. Donc on a exercé nos modèles mentaux, on a discuté pour essayer de trouver la façon la moins coûteuse de réaliser le truc, moins coûteuse tout de suite et dans le futur de réaliser le truc. Donc on a exercé nos modèles mentaux, on a discuté pour essayer de trouver la façon la moins coûteuse de réaliser le truc, moins coûteuse tout de suite et dans le futur de réaliser le truc. Et on est tombé d'accord sur le fait que normalement ce truc là, je sais pas, il est 14h, il y en a pour 3h, donc à 17h c'est terminé. Donc faire du pull, c'est que je vais dire à Justine, bah écoute, c'est super, vas-y go. Moi je reviens à 17h. Et je vais revenir à 17h pour prélever la pièce au sens pour voir à ce que tu as fait et pour qu'on puisse avoir une discussion sur la qualité de ce que tu as produit. Parce que ça sera une opportunité de coaching. Et ce que je te demande, C'est euh et du coup c'est l'autre côté, c'est le pendant de de du just in time, de la vitesse, c'est l'auto qualité, le Jidoka. Ce que je te demande, c'est que si tu as la moindre difficulté. Ce que je te demande, c'est que si tu as le la moindre difficulté.
[00:42:24] Mais vraiment, je vais venir à 17h hein, t'inquiète que ça sorte. Par contre, si tu as la moins de difficulté, c'est ta responsabilité de de m'appeler pour que je vienne regarder ce qui se passe et te filer un coup de main. Vous voyez? Et alors je sais pas si vous voyez l'élégance du système, c'est que quand je fais ça, je suis en train de créer un système dans lequel je reçois, je suis sollicité sur tous les trucs où j'ai quelque chose à apprendre aux personnes. Vous voyez? Vous voyez?
[00:42:49] Donc je reste à disposition de l'équipe parce que j'ai j'ai mis en place ce système de pull. J'ai les gens qui m'appellent en permanence, ils m'appellent exactement là où ils ont des difficultés. Ce qui fait que j'ai pas besoin d'être sur leur dos, leur dire, tu en es où, qu'est-ce que tu fais? Vous voyez? J'ai juste à être là. euh pour être dispo quand la personne va va buter sur un va buter sur un problème. Là, on va ce qu'on va faire c'est qu'on va croiser le truc. Là, on va ce qu'on va faire c'est qu'on va croiser le truc, on va on va pardon, on va. euh faire des résolutions de problème. La résolution de problème dans le line, en fait, est est centrale. La résolution de problème dans le line, en fait, est est centrale parce que euh ce qu'on sait d'un point de vue scientifique, euh c'est que les adultes apprennent par la résolution de problème. On parle beaucoup de pédagogie pour enseigner, la pédagogie, c'est la science de l'enseignement aux enfants. Donc les les adultes, ça apprend pas dans une salle en regardant des slides. Les adultes, ça apprend en résolvant des problèmes opérationnels sur le terrain. Donc ce qu'on voit là, c'est comment le système permet de faire émerger les problèmes. pour que les gens résolvent des problèmes et qu'ils apprennent par la résolution de problème. Et on va s'intéresser à deux types de résolution de problème. Et on va s'intéresser à deux types de résolution de problème. On va regarder euh déjà donc si Justine a une difficulté, on va avoir une réflexion sur les conditions. C'est-à-dire que grosso modo, le rôle de la le rôle du contributeur individuel. grosso modo, le rôle du contributeur individuel, c'est de produire de la valeur pour les clients. Dès que je quitte cette cette strate là et que je deviens chef, que je deviens tech lead ou au-dessus. Dès que je quitte cette cette strate là et que je deviens chef, que je deviens tech lead ou au-dessus, en fait, c'est plus moi qui fait ça, ou quand je le fais, c'est juste que je le je me ce que je veux dire, si je suis tech lead et que je code, c'est pas grave. C'est juste que là, je suis pas tech lead, je suis en train de faire contributeur individuel. Mais quand j'ai ma casquette euh tech lead, mon rôle, c'est de créer les conditions pour que les gens puissent aller vite et mon rôle, c'est de les former. Donc premier truc, c'est que quand Justine a une difficulté, j'essaie de me dire dans les conditions. euh ce qu'elle a reçu comme comme input, euh l'outillage qu'elle utilise, la configuration de son environnement, est-ce qu'il y a des trucs qu'on n'a pas compris? Est-ce qu'on est-ce qu'on a quelque chose à apprendre sur comment créer les conditions pour que Justine puisse bosser tranquille sans effort? Est-ce qu'on a quelque chose à apprendre sur comment créer les conditions pour que Justine puisse bosser tranquille sans effort? Deuxième truc euh que qu'on va regarder, c'est euh bah est-ce que c'est plus une question dans le monde des standards ou est-ce que est-ce que du coup Justine un truc qu'il a pas compris? Est-ce que c'est un truc qu'on n'a pas compris, on n'est pas clair sur notre standard? Est-ce que c'est un truc qu'on n'a pas compris, on n'est pas clair sur notre standard? Est-ce que c'est elle qui ne se l'est pas appropriée? Et du coup, je fais de tout ça mon mon système de formation. Et donc ce qu'on voit là, c'est comment le TPS et donc le lin en général est une méthode est parfaitement éprouvée qui marche partout pour consciemment, en fait, transformer l'activité de production en activité d'apprentissage pour faire des maîtres artisans qui ont la capacité d'aller de plus en plus vite pour faire de la valeur. Et c'est ça que ce Toyota essaie de nous dire depuis des années et des années et des années, et en fait, on refuse d'entendre. Parce qu'on est tellement pris dans notre délire terroriste que on a tous l'intention de mettre les gens dans la petite boîte. Mais c'est pas ce qu'il nous dit, il nous dit, bah pour faire des bons produits, il faut que les gens réfléchissent bien. Mais c'est pas ce qu'il nous dit, il nous dit, bah pour faire des bons produits, il faut que les gens réfléchissent bien. Et du coup, il faut concevoir une entreprise qui est qui est faite de telle sorte que les gens sont en permanence en train d'apprendre à mieux maîtriser leur travail, à mieux réfléchir. à mieux maîtriser leur travail et à mieux réfléchir et à devenir plus fort. Et c'est pour ça que euh je pense que la la grande tragédie euh du line dans dans notre monde, c'est d'avoir pris juste un bout pour imaginer que c'était un système de gestion de flux et je pense que c'est tragique à titre personnel parce qu'en fait, on passe à côté bah de d'une aventure humaine euh qui qui vaut vraiment le coup d'être vécue. Et je pense que c'est tragique à titre personnel parce qu'en fait, on passe à côté bah de d'une aventure humaine euh qui qui vaut vraiment le coup d'être vécue. Et du coup, qu'est-ce que j'ai à vous dire? Et du coup, qu'est-ce que j'ai à vous dire? Bah si vous travaillez, je sais pas s'il y en a qui travaillent avec des humains. Mais si vous travaillez avec des humains, si vous êtes manager, j'ai en fait deux deux deux propositions à vous faire. La première c'est de raise de bar sur vous-même et de vous regarder en tant que manager et vous dire, où est-ce que j'en suis et qu'est-ce que je suis en train de faire pour progresser? Et euh si ça vous branche, une deuxième piste, c'est de de de vous mettre à ce macha là que qu'aujourd'hui, donc j'appelle le le line hardcore à la japonaise euh pour qu'ensemble on puisse essayer de de de sortir de de ces projets un peu merdiques. de de sortir de de ces projets un peu merdiques qui donnent l'envie à tout le monde de changer de métier. Merci beaucoup!

Transcription