Apprendre à gérer une courbe d'apprentissage

X – C'est bon j'ai fini ma tâche, est-ce qu'on peut la regarder ensemble pour la valider ?

Moi – Bien sûr...

Moi, confiant après 5 minutes à relire le code – C'est tout bon, on peut l'ajouter dans le dépôt source.

X – Je fais un merge avec la branche principale et après je pousse tout sur le serveur central. C'est bien ça ?

Moi – Exact, il suffit de bien suivre la petite procédure interne (checkout, rebase, merge, dcommit, push) qui t'explique chaque étape dans le wiki interne.

X – Je me souviens bien de ces procédures, je les ai d'ailleurs suivi pour installer le code source sur mon ordinateur au départ.

X, contrarié – Par contre là, ça ne marche pas : je n'ai rien fait de particulier et pourtant Git me dit que j'ai des commits d'avance ! Ce n'est quand même pas de ma faute si ça ne marche pas du premier coup...

Moi, sarcastique – As-tu vérifié s'il n'y avait pas un petit lutin ou pire un farfadet sous ton clavier ? Peut-être qu'ils ont laissé des traces de leur passage ? Des miettes de pain peut-être ou des gouttes de lait ?

X – Ce n'est pas ce que je voulais dire...

Moi – Alors qu'est-ce que tu voulais dire ?

X, vexé – Que je ne sais pas ce que j'ai fait et que je comprends encore moins pourquoi ça ne marche pas... Mais que le code est bon.

Moi – Sauf qu'en l'état le code ne sert à rien : impossible de le fusionner dans le dépôt central.

X – Mais qu'est-ce que je peux faire alors ?

Moi – La première étape, c'est peut-être d'assumer que tu as fait une erreur et que tu es en train d'apprendre. Tu débutes chez nous, c'est normal. J'irai même jusqu'à dire que savoir trouver de l'aide fait parti de l'apprentissage.

X – Tu veux dire que je dois lire toute la documentation de Git pour comprendre comment résoudre ce problème ?

Moi – C'est une piste. Tu peux aussi repartir d'une installation complètement vierge. Tu peux également demander à un développeur senior de te montrer comment il s'en dépatouillerait. Tout dépend de ce que tu veux apprendre et à quelle vitesse surtout.

X – Mais qu'est-ce que je dois faire alors ?

Moi – Gagner en humilité et en expérience ! Et pour ça, ces trois chemins sont valables. Probablement même qu'il y en a d'autres...

X, impatient – Tu ne me diras donc pas lequel il faut que je prenne.

Moi – Je ne peux pas le faire pour toi : les adultes apprennent moins bien quand on leur montre trop précisément chaque étape. Ils ont déjà un tas de modèles mentaux à leur disposition, des modèles qui les ont aider devenir ce qu'ils sont, des modèles qui ont déjà fait preuve de leur efficacité. Si tu ne sais pas quel chemin prendre, l'expérience douloureuse d'un choix sera bien meilleure conseillère à terme : c'est peut-être le plus facile.

X – Parce que tu penses que ça peut être plus rude ?

Moi – Si tu feins de ne pas le savoir - peut-être qu'un de tes réflexes te suggère d'ailleurs très légitimement de "retourner la question pour ne pas être pris en défaut" -, alors il te faudra d'abord casser, affiner ou ajouter un modèle mental. C'est loin d'être si évident. Et là encore, personne ne peut le faire à ta place.

Le jidoka pour créer de la robustesse de l'intérieur

Moi — Est-ce qu'on peut regarder comment tu as corrigé ce ticket ?

X — Facile : dans la version mobile, en bas de la page, il manquait toujours l'historique d'un contact. Et maintenant c'est tout bon : regarde bien, cet historique est bien présent. C'était un problème dans l'API.

Moi — Et peut-on regarder le code qui correspond ?

X — Toujours aussi facile : avec le numéro de ticket, on va vite retrouver le numéro de commit.

Un château de cartes plus grand que son concepteur

X, tapant quelques commandes dans son terminal —Voici le diff avec la version juste avant le commit.

Moi, dubitatif — Et quand tu écoutes ce code, qu'est-ce qu'il te dit ?

X, gêné — Qu'il lui manque son test unitaire.

X — Pourtant on a fait une revue de code avec ma responsable.

Moi — Mais devant moi, tu as directement pointé le problème.

X — Je connais la règle : avec une correction de bug, toujours ajouter un test unitaire. Avec chaque évolution du code en fait, y compris avec une nouvelle fonctionnalité.

Moi — C'est donc que j'ai raté une étape dans la transmission, peut-être avec ta responsable.

X — Ou peut-être qu'on était pressé ce jour-là, je ne m'en souviens plus.

Moi — Reste que le jidoka est un des deux piliers du Lean.

X — Le jido-quoi ?

Moi — C'est le pilier qui préconise de construire la qualité dans le produit, en détectant les anomalies dans le processus.

X — Naïvement, je dirais que c'est précisément ce que nous avons fait en corrigeant le problème, non ? On n'avait pas forcément besoin d'un test test unitaire en plus...

Moi — Sauf qu'en refusant de faire le test unitaire correspondant, tu as bloqué deux choses : d'une part la démonstration que tu avais bien compris la racine du problème (et pas juste les symptômes), et d'autre part la vérification automatique si le problème devait se reproduire plus tard.

X — J'ai quand même une question : est-ce que tu savais qu'il y avait ce problème dans ce commit avant que nous commencions ce gemba ?

Moi — Bien sûr que non, je sais juste d'expérience qu'on finira par trouver un premier problème. Et qu'il mérite toujours qu'on y passe du temps. Les problèmes suivants finiront toujours par remonter un peu plus tard.

X — Alors ce jidoka, recouvre-t-il autre chose que les tests unitaires chez nous ?

Moi — Avec 206864 tests unitaires, c'est sur qu'on ne peut pas les rater : l'effet de masse joue à fond. Mais il y a aussi tous nos tests d'intégrité : est-ce que les fichiers qui doivent être dupliqués sont bien identiques ? est-ce que tous les fichiers de langue contiennent strictement les même chaînes de traduction ?

X — C'est donc pour ça qu'on m'avait demandé un petit script qui puisse identifier les fichiers qui n'ont pas été modifiés depuis 5 années !

Moi — Certainement : ça veut peut-être dire qu'ils sont devenus inutiles. Et dans ce cas, autant les supprimer : c'est toujours ça de surface en moins pour des attaques de cybersécurité.

X — Tu as d'autres exemples ? On ne m'a jamais parlé de ce type de tests dans mon cursus universitaire.

Moi — Voici une anecdote : un client nous appelle parce qu'un champ qu'il a activé sur les utilisateurs n'est pas accessible dans l'export Excel de ces même utilisateurs. On ajoute le champ en question dans l'export Excel, il est content. L'affaire aurait pu en rester là. Sauf qu'on se dit qu'il y a peut-être d'autres champs qui ne sont pas présents dans cet export. On ajoute donc un nouveau test d'intégrité et on découvre qu'il y avait bien 3 autres champs dans le même cas. Personne ne s'était jamais plaint jusqu'à présent. Et désormais si un développeur devait oublier d'ajouter un nouveau champ dans l'export, il recevrait un message d'échec via l'intégration continue. Le processus est devenu beaucoup plus robuste.

L'ordre des mauvaises nouvelles

X — On se calme. On respire.

Moi — Ma réunion vient à peine de se terminer : est-ce que tu sens encore l'électricité dans l'air ?

X — Je peux surtout voir que ta respiration n'est pas aussi tranquille que d'habitude. Que ta décontraction n'est pas là. Et que ta chemise dépasse de ton jean.

Moi — Encore et toujours ce regard...

X — Et on n'arrête jamais d'apprendre : ce n'est pas si souvent que je te vois dans cet état.

Quand les mauvaises nouvelles pleuvent

Moi — Peut-être que je n'ai pas l'habitude des réunions, mais là je n'en pouvais plus : j'ai mis les pieds dans le plat, en créant un malaise bien profond. Un malaise qui s'est à peine dissipé quand l'ordre du jour initialement prévu a repris son cours.

X — Il me semble pourtant que tu étais au dernier Lean Tour à Lille, n'est-ce pas...

Moi, taquin — Je sais que tu sais que je l'ai organisé et même qu'on s'y est croisé.

X — Alors tu te souviens peut-être des leçons de Reynald Debaut-Henocque, il y avait 8.

Moi — Attends voir un peu... Mon préféré si tu n'as pas de problème, alors c'est qu'il y a un problème. Ah oui, et aussi mieux vaut tester quelque chose que ne rien faire.

X — À ce rythme, ça va nous prendre trois plombes...

Moi, hilare — Je me disais bien que je n'avais pas fini de digérer les conséquences des découvertes en neuro-pédagogie présentées par les équipes de Arc.

X, sérieux — Je t'offre donc une séance de rattrapage, il y avait aussi avoir des rêves, des objectifs et des vision, ne jamais être satisfait, connaître sa place, n'abandonnez jamais à mi-chemin et ne pénalisez jamais vos subordonnés.

Moi — Clairement j'en avais oublié plus que la moitié. Mais ça n'en fait toujours que 7.

X — J'espérais que tu te souviennes de la dernière, c'est celle qui m'intéresse aujourd'hui.

Moi — La race des senseïs est quand même pénible : avoir les réponses et ne pas les donner. Ou donner celles qui sont tout juste adjacentes...

X — J'avoue, j'ai regardé la vidéo il n'y a pas si longtemps pour écrire cette liste sur mon calpin : elle est quand même intéressante, dans la veine du Toyota Way.

Moi, soulagé — J'ai retrouvé : bad news first.

X, pompeux — Les mauvaises nouvelles d'abord.

Moi — Tu veux dire que j'aurais dû court-circuiter l'ordre du jour ? Et commencer la réunion par le point litigieux ?

X — Même pas. Le meilleur moment pour planter un arbre, c'était il y a 20 ans. Le deuxième meilleur, c'est tout de suite.

Moi, las — C'est reparti pour un tour.

X, taquin à son tour — Je sais que tu sais que je n'ai pas besoin d'en dire plus et que tu réfléchira tranquillement avant de faire mieux la prochaine fois, et même mieux que moi d'ailleurs : je n'ai pas choisi d'être indépendant pour rien.

Apprendre à entendre Lean

X — C’est sympa de me parler Lean de temps en temps. Et même de m’inviter à des conférences ou à des ateliers épisodiquement. Mais vraiment je n’en peux plus du vocabulaire japonais tout le temps.

Moi — Malheureusement on ne peut pas faire l'impasse : le Lean a été inventé et affiné au Japon, tout au long de son développement industriel, au sein d’une entreprise en particulier, Toyota.

X — N’empêche qu’à chaque conférence ou webinaire, je dois me farcir un nouveau mot sans traduction. J’ai eu droit à kaizen, puis andon, puis jidoka. Pour ceux que j’ai retenus… Je suis certain que j’en ai oublié en route. Ah si, le dernier en date était « Genchi Genbutsu ».

Ce qui sort de la bouche
Ce qui sort de la bouche

Moi — Sans oublier « Hoshin Kanri » ou « Nemawashi ».

X — Arrête, je suis déjà perdu : c’est dommage, je sens pourtant bien qu’il y a des trucs intéressants dans le Lean.

Moi — Je te propose de faire un pas de côté : est-ce que tu sais que presque tous les sodas en grand surface sont « kasher », en particulier aux Etats-Unis ?

X — Quel rapport ?

Moi — Je vais y venir… Nassim Nicholas Taleb appelle ça la tyrannie de la minorité : quand la majorité est indifférente à un sujet, une minorité exigeante peut imposer ses préférences assez facilement à toute une population. Et par ailleurs une minorité trop conciliante se fondera dans la masse, tandis qu’une majorité sensible bloquera toute évolution.

X — Et tu penses que le Lean est une de ces minorités ?

Moi — Pas qu’un peu : dans le monde de l’entreprise, la pensée dominante se transmet à coups d’injonction financière et de court-termisme froid, grâce à des cohortes de détenteurs d’un MBA.

X — Et la question du vocabulaire serait une forme d’intolérance ?

Moi — Complètement assumée.

X — Tu veux dire que vous bloquez l’accès au Lean avec des mots japonais de manière délibérée ?

Moi — « Bloquer » est un peu excessif. C’est surtout un moyen de préserver l’essentiel : les spécificités du Lean. Tiens par exemple, le « Karakuri » : au départ c’est une petite poupée qui bouge toute seule, grâce à la gravité et à des systèmes ingénieux. C’est désormais un axe majeur des efforts de Toyota sur le chemin de sa propre décarbonation : chaque année il y a des compétitions internes avec des voyages au Japon pour les meilleurs. Les connotations d’un mot comme « marionnette » ou « poupée » rendent le concept difficilement abordable en France sans le détour par le mot japonais.

X — Mais pourquoi tout le temps et partout ?

Moi — Tu oublies le fameux « Just-in-Time », inventé par les japonais eux-même parce que ça « sonnait » bien. Puis détourné en pas-de-stock-chez-moi par des consultants, oubliant l’intérêt du stock tampon et négligeant les pertes de compétence.

X — Je sens que je ne vais pas réussir à te faire changer d’avis.

Moi — Tu bosses dans le développement logiciel, est-ce que tu te fais autant de tracas avec les « commits », « mock objects » et autres « pull requests » ?

X — Tu triches : c’est le vocabulaire d’une très large majorité de développeurs à travers le monde.

Moi — N’empêche que si tu veux devenir développeur, tu dois apprendre ces mots-concepts.

X — Tu veux dire qu’il faut accepter de redevenir débutant pour faire du Lean ?

Moi — Cela ne m’étais jamais apparu aussi clairement, mais maintenant que tu le dis, oui ! Trois fois oui même. C'est même l'intérêt principal que j'y trouve.

Pour qui est ce tableau ?

Moi — Excuse-moi de ce contre-temps, j’ai été pris par un coup de fil impromptu.

X — C’est surtout à moi de te remercier : tu n’étais pas obligé de me faire la faveur d’un accueil dans tes bureaux. Et puis je n’ai pas perdu mon temps : comme tu m’en avais donné l’autorisation, je me suis promenée à travers ton obeya.

Moi — C’est vrai qu’il y a de la matière avec des zones pour chaque kaizen, celle pour la Chief Engineer, celle de nos « gembas code » réguliers et mes propres tableaux de pilotage financier.

X — Je te confirme qu’on voit bien que ceux-là vivent : il y a des post-its, des traces de feutre ou de crayon gris.

Moi, curieux — Alors ? Je sens que tu as vu quelque chose qui te chiffonne.

X — Il y a bien cette zone là-bas : vous y avez scotché un tas de captures-écran. Vous avez obtenu une belle grille, plutôt harmonieuse, mais il n’y a aucune trace de vie. D’où ma question : qui la maintient dans ce coma artificiel ? Et plus important encore : pour qui ?

Des tableaux dans le vent
Des tableaux dans le vent

Moi — Je vais répondre à tes questions, mais laisse-moi faire un bref aparté : je suis toujours bluffé quand un sensei passe dans des bureaux et « voit » un truc aussi important et aussi rapidement.

X — En même temps, c’est à ça qu’on s’entraine tous les jours.

Moi — Donc pour revenir à ta question : lors de sa veille régulière, notre responsable communication en profite pour alimenter ce mur de la concurrence avec principalement des captures-écran de leurs sites web. Il nous a beaucoup servi pour affiner son périmètre quand elle est arrivée dans l’équipe. Et il me servait aussi dans mon rôle de Chief Engineer.

X — Et pourquoi ce mur est-il mort alors ?

Moi — Alors qu’elle prenait la mesure de son poste et qu’elle gagnait en confiance et en autonomie dans ses tâches, mon rôle aussi a changé : si je reste bien le gérant de No Parking, la casquette de Chief Engineer pour Opentime s’est déplacée sur la tête d’un autre membre de l’équipe.

X — Et tu l’aurais privé de ce qui te nourrissait !

Moi, espiègle — Vas-y tu peux y aller ! J’ai compris… Et je suis déjà en train de réfléchir comment redonner vie à ce mur depuis 5 minutes.

X, intriguée — Alors !?

Moi — Je sens qu’on va reparler « émotions » avec la Chief Engineer. Cela fait bientôt un an qu’on tourne autour : ce mur de la concurrence nous offre un beau terrain d’exploration pour un prochain gemba. Il devrait au passage changer de propriétaire.