Sébastien Ménétrier
Transcription
On va parler de comment, au sein d'une équipe, et pourquoi pas plus tard au sein d'une organisation, mettre en place une politique de montée en compétences, une politique de partage de la connaissance entre les gens. Et on va voir comment on peut faire ça, non pas au fil de l'eau, non pas dans l'urgence quand on a des besoins qui vont nous tomber dessus, mais comment on peut faire ça de manière rationnelle, organisée, bien évidemment priorisée, pour que ce soit efficace.
Alors juste avant de commencer, je vais me présenter très brièvement. Sébastien Ménétrier, je travaille pour la société SOAT, c'est marqué un petit peu partout. Je suis aussi secrétaire du French Cambron User Group. Donc on organise à peu près une fois par mois des soirées. Autour du combat et tout ce qui va avec. Donc n'hésitez pas à vous inscrire sur notre meet-up la prochaine soirée, le 20 novembre. Il y en aura une en décembre autour des Jeux, donc n'hésitez pas à nous rejoindre. Voilà, fin de la parenthèse promotionnelle. Allons-y.
Donc, la première question qu'on devrait se poser d'ailleurs avant d'entamer quoi que ce soit, c'est pourquoi on va faire les choses? Pourquoi a-t-on besoin de mettre en place une politique de partage de la connaissance au sein d'une équipe? Premièrement, un constat.
Le constat, c'est que la plupart du temps, au sein de nos équipes, les gens vont être spécialisés. Alors que ce soit une décision à l'origine de la création de notre équipe, on monte une équipe pour répondre à un projet, on va la constituer avec des spécialistes de tel ou tel techno, des spécialistes de tel ou tel domaine fonctionnel, ou même si on a au début du projet une équipe avec des gens qui sont de niveau à peu près... équivalent, de connaissances à peu près équivalentes, on va par la pratique très rapidement se retrouver avec des gens spécialisés dans nos équipes. Je suis développeur, je commence à travailler sur le module de comptabilité, des nouvelles demandes arrivent sur ce module, très naturellement c'est sur moi que ça va tomber. Et très rapidement, je vais devenir l'expert sur le sujet, et non seulement je vais être l'expert sur le sujet, mais je vais être l'expert à défaut des autres membres de l'équipe. Je vais être le seul à connaître ce sujet.
Donc, on a des équipes avec des gens dedans spécialisés. Bien. Mais est-ce que c'est gênant? Après tout, on a chacun de nos développeurs qui sont dans leur zone de confort. On sait très bien qu'on ne peut pas avoir une équipe avec que des gens spécialistes de tout.
On a des demandes qui arrivent, on a des gens très efficaces pour les régler, ça pourrait être satisfaisant. Ça pourrait, mais ce n'est pas si satisfaisant que ça, parce qu'on va pouvoir identifier au moins trois problèmes autour de ça. Le premier problème, je ne sais pas si vous connaissez cette théorie, c'est ce qu'on appelle le bus factor. Donc le fact. du bus. Alors, c'est un petit peu morbide, mais en gros, posez-vous la question dans votre équipe, si telle personne, demain matin, venant travailler, se fait renverser par un bus. Je vous avais dit, c'est un peu morbide. Si telle personne se fait renverser par un bus, est-ce que mon projet peut survivre? Si la réponse, c'est non, c'est que vous avez effectivement un très très gros risque. Des personnes spécialisées sur un projet, ça représente un risque énorme. Alors, sans aller aussi loin que le fait de se faire renverser par un bus, tout simplement un congé maladie, ça peut vous mettre en péril. Et puis, ces facteurs de... d'absence de sérénité au sein de l'équipe parce que, tout simplement, les gens ne peuvent pas prendre de vacances librement. Voilà, c'est moi l'expert sur le module comptabilité. Ok, je ne prends pas de vacances parce que si jamais il y a un problème, personne ne peut le régler. Sur le long terme, on voit tout de suite que ce n'est pas tenable. D'accord? Donc, une équipe spécialisée, ce sont des risques.
Une équipe spécialisée, c'est aussi des soucis en termes de possibilités. Je m'explique.
Donc on va reprendre notre expert sur un module comptabilité. On a un expert sur un module ressources humaines, sur notre application. Je ne sais pas trop ce qu'a fait cette appli, mais admettons. On a des demandes qui arrivent, on a tout un tas de backlog de demandes à traiter et les demandes prioritaires, ça ne concerne que la compta. Et on en a vraiment beaucoup, beaucoup, beaucoup, de quoi s'occuper un mois ou deux. Sauf qu'on n'a qu'une seule personne qui sait travailler dessus. On va se retrouver obligé d'alimenter notre expert RH avec des tâches non prioritaires, juste parce qu'on n'a pas la capacité à traiter les demandes prioritaires. D'accord? Donc on va... On va moins bien répondre aux besoins de nos clients. Donc ça, c'est le deuxième problème que l'on peut rencontrer, à avoir des équipiers trop spécialisés.
Et puis, on a un autre point qui va nous inciter à mettre en place ces politiques de montée en compétence, c'est que c'est un facteur de motivation, la montée en compétence. Je vous rappelle brièvement le cinquième principe que l'on va trouver dans le manifeste agile. Donc réaliser des projets avec des personnes motivées. Pourquoi on veut motiver les personnes? On sait très bien que les personnes motivées sont plus efficaces, que les personnes motivées vont être plus fidèles à notre projet. Quand je parle de fidélité, c'est-à-dire qu'on est dans des contextes, j'imagine que vous le savez, où il y a énormément de prestataires. Les prestataires, ça peut très facilement partir d'un projet et aller voir ailleurs. Donc en gardant des gens motivés, Voilà, on est plus efficace, plus pérenne, on a un projet qui peut bien se passer sur la durée. Et donc, garantir aux gens qui travaillent sur notre projet, leur garantir qu'ils vont pouvoir monter en compétence et qu'ils ne vont pas stagner uniquement sur le même module, la même techno, la même partie de l'application, Ça va nous aider, c'est un très bon facteur de motivation de nos équipes. D'accord? Donc, réduction des risques, augmentation des possibilités de l'équipe, facteur de motivation de nos équipiers. Donc trois raisons que j'estime pour ma part assez importantes de mettre en place une politique de montée en compétences.
Très bien, mais mettre en place une politique de montée en compétence, ça prend du temps, donc ça prend de l'argent. Ça coûte à notre projet. Si vous dites à votre client, c'est très bien, mais là, cette semaine, j'envoie tout le monde en formation, on ne va rien te livrer, ça risque de bloquer.
Donc, il va falloir trouver un moyen de mettre en place cette politique de montée en compétence qui soit indolore, du moins le plus indolore possible pour notre client, pour les performances de notre équipe. Alors, c'est un investissement une montée en compétence, ça coûtera toujours quelque chose. On va essayer de faire en sorte que ça coûte le moins possible. D'accord? Entre autres, en priorisant les actions, en faisant les monter en compétence dans les endroits qui sont les plus importants. Alors moi, je vais vous proposer, c'est issu de ce que j'ai pu mettre en place dans différentes équipes ces dernières années, c'est un plan en cinq étapes, en cinq actions.
Première étape, on va déjà faire un état des lieux de ce que notre équipe sait, de ce que notre équipe est capable de faire. Deuxième étape, on va regarder ce que notre équipe a envie de faire. Troisième étape, on ne va plus s'intéresser à l'équipe, on va s'intéresser au projet. De quoi mon projet a besoin?
Quatrième étape, on va compiler toutes ces données pour pouvoir organiser la montée en compétences en tant que telle. Et cinquième étape, Étape, on va entretenir cette politique dans le temps. Et puis même, on va essayer, cinquième étape bis, de l'élargir à notre organisation.
Alors, première étape, on va faire un état des lieux. Qu'est-ce que les gens de mon équipe savent faire? Donc on va utiliser un outil que vous avez peut-être vous-même déjà utilisé. C'est un outil qu'on appelle une matrice de compétences. Alors, je vous en montre un exemple tout de suite après, mais basiquement, la matrice de compétences, c'est quoi? C'est lister les compétences nécessaires à mon projet.
Mettre en regard de ses compétences les personnes et regarder qui sait faire quoi, à quel niveau. Bien.
Alors il y a quelques écueils à éviter quand on va créer cette matrice de compétences. La première étape, c'est de lister les compétences dont on a besoin. Le moyen le plus simple de le faire, c'est de réunir tout le monde autour d'une table et puis dire, ok, alors dans votre projet, dans votre contexte, quelles sont vos compétences? De quoi a-t-on besoin? Quand on va parler de compétences, on va tout aussi bien parler de compétences techniques. On a besoin de connaissances en Java, on a besoin de connaissances en WebSphere, en ce que vous voulez. Et on va tout aussi bien pouvoir parler de compétences fonctionnelles. On a besoin de s'y connaître sur le module de comptabilité, le module de ressources humaines. Tel et tel autre module. On peut aussi avoir des choses qui sont un petit peu à la frontière, qui sont plus de l'ordre du savoir-faire. Je sais faire une mise en production. Donc on va commencer par lister l'ensemble de nos compétences. Alors là, on peut aussi faire un petit peu de prospective. On va regarder l'ensemble des compétences qui sont nécessaires à l'instant T sur notre projet. Puis on peut peut-être aussi se projeter. Je pense qu'on va avoir telle ou telle opportunité, qu'on va avoir tel ou tel besoin dans l'avenir. Donc je note les compétences dont je vais avoir besoin bientôt.
Alors, quand vous faites ce relevé de compétences, faites bien attention à la granularité. Je vous donne un exemple. Dire que je m'y connais en Java, c'est peut-être trop large. Java, ça représente énormément de frameworks, de modules, de bibliothèques, de ce que vous voulez. C'est peut-être trop large. Après, rentrer trop dans les détails, ça va peut-être aller trop loin. Donc il va falloir faire attention à la granularité. Alors, il n'y a pas de formule magique. Moi, en gros, ce que j'ai vu qui était efficace sur mes matrices de compétences, c'est de ne pas avoir plus de 30 items différents. 40, grand maximum, vraiment sur les très grosses équipes avec des applicatifs très complexes. Si vous avez plus de colonnes que ça dans votre matrice, c'est peut-être que vous allez un peu trop loin. Il y a peut-être des regroupements à faire. En tout cas, elles risquent d'être plus difficilement maintenables. Bien. Donc maintenant, on a listé nos compétences.
On a listé les personnes de l'équipe, ça, ça ne va pas être le plus dur. Maintenant, l'idée, c'est de voir qui sait faire quoi. Alors, il y a plusieurs manières de le faire. Moi, celle que je vais privilégier, c'est tout simplement de demander aux gens de s'auto-évaluer. D'accord? C'est là où on va avoir, d'une part, la vérité. Parce que moi, en tant que manager d'une équipe, je pense qu'un tel connaît ça. Peut-être que je me trompe, peut-être que j'évalue mal son niveau. Et puis très probablement que la personne en question a des connaissances qu'on n'a pas encore mis en pratique, donc moi je les ignore. Donc on va demander aux personnes de s'auto-évaluer sur leurs compétences. Maintenant, pour que les personnes puissent s'auto-évaluer, ce qui est très important, c'est de leur donner une échelle explicite. Si je vous demande, voilà, alors en Java, vous y connaissez combien entre 0 et 5?
C'est très compliqué à donner. Par contre, si je vous donne une échelle explicite, 0, vous n'y connaissez rien du tout. 1, vous pouvez travailler dessus, mais vous n'êtes pas autonome. 2, vous êtes autonome. 3, vous êtes capable de former sur le sujet. Donc si j'arrive à vous donner une échelle explicite, là, vous allez être capable de vous auto-évaluer.
Donc, une fois qu'on a déterminé notre matrice, on la fait remplir par les membres de notre équipe. Alors éventuellement, dans un second temps, on peut la faire relire par un tech lead ou quelqu'un qui connaît très très bien le projet parce que de temps en temps, les gens ont des fausses idées sur leurs compétences. Donc on peut refaire une passe pour vérifier si tout nous semble cohérent. Pourquoi pas? Donc voilà en gros ce que peut donner une matrice de compétences.
En haut, j'ai mis l'échelle que j'ai utilisée sur ce projet-là.
Donc on a listé les compétences techniques en haut, les compétences fonctionnelles en bas, et les personnes ont été s'auto-évaluer sur tous ces sujets-là.
Donc ça, c'est notre première étape. On fait l'état des lieux de ce qui existe dans notre équipe. vis-à-vis des compétences, encore une fois, dont on a besoin actuellement, et pourquoi pas, dont on pourrait avoir besoin dans le futur. Deuxième étape, maintenant que je sais ce que mon équipe sait faire, je vais voir ce que mon équipe a envie de faire.
La clé pour qu'une politique de montée en compétence soit réussie, c'est le volontariat, c'est de faire monter les gens en compétence. sur des sujets qui les intéressent. Donc, on reprend la même matrice, la même liste de compétences, la même liste de personnes, et on demande aux gens de nous dire, ok, sur quoi vous avez envie de monter en compétences? Et ce qui est important de faire apparaître aussi, C'est de voir sur quoi vous n'avez surtout pas envie de monter en compétence. Il y a des gens qui ne sont pas du tout intéressés par tel domaine fonctionnel, qui ne sont pas du tout intéressés par tel techno. Ok, il faut le savoir, c'est important de le savoir. Et puis bien évidemment, sur d'autres sujets, on va pouvoir éventuellement rester neutre. Donc ça va nous donner, toujours sur le même projet,
ça peut nous donner ce type de matrice de souhait. Donc en vert, les volontés de monter en compétence. En rouge, les« non, ça ne m'intéresse surtout pas, je ne veux pas le faire». On voit que notre ami Thibault n'est pas intéressé par grand-chose.
Et en blanc, OK, on reste neutre. Très bien. Alors, ok, là je me suis intéressé aux gens. Maintenant, je vais m'intéresser au projet. Je vais reprendre ma matrice de compétences et en regardant ça, je vais regarder où sont mes manques. D'accord? Et où est-ce que je suis bien couvert? Alors, ça peut être assez facile. Effectivement, sur telle colonne, j'ai qu'une seule personne qui connaît. J'ai potentiellement un manque, potentiellement un risque. Sur telle autre colonne... J'ai plein de monde qui connaît. Ok, je n'ai pas de risque.
Pas d'opportunité à détecter. Bon, ce n'est pas forcément aussi binaire que ça. Des fois, effectivement, tel module, je n'ai qu'une seule personne qui le connaît, mais je sais très bien que ce n'est pas un module critique et je sais que j'ai une demande tous les deux mois sur le sujet. Une seule personne, ok, c'est suffisant pour le moment. A l'inverse, telle autre compétence, j'ai la moitié de mon équipe qui la connaît, mais je sais que mon projet va par là, donc j'ai besoin de faire monter d'autres personnes en compétence. Donc ce n'est pas mathématique de déterminer où je vais faire mes montées en compétence, ça nécessite bien évidemment d'avoir la connaissance du projet, la connaissance du contexte et d'être capable de se projeter un petit peu dans l'avenir. J'ai plein plein de monde qui connaît, ok j'ai pas de risque.
Pas d'opportunité à détecter. Bon, c'est pas forcément aussi binaire que ça. Des fois, effectivement, tel module, j'ai qu'une seule personne qui le connaît, mais je sais très bien que c'est pas un module critique et je sais que j'ai une demande tous les deux mois sur le sujet. Une seule personne, ok, c'est suffisant pour le moment. A l'inverse, telle autre compétence, j'ai la moitié de mon équipe qui la connaît, mais je sais que mon projet va par là, donc j'ai besoin de faire monter d'autres personnes en compétence. Donc ce n'est pas mathématique de déterminer où je vais faire mes montées en compétence, ça nécessite bien évidemment d'avoir la connaissance du projet, la connaissance du contexte et d'être capable de se projeter un petit peu dans l'avenir.
Donc je vais pouvoir déterminer. Généralement, ce que je mets en place, c'est que je vais déterminer mes trois prochaines montées en compétences prioritaires.
Et puis après, c'est tout simple. Je regarde où je vais monter en compétences. Je regarde ma deuxième matrice. Je vois qui a envie de monter en compétences sur le sujet. C'est parfait. Je n'ai plus qu'à mettre un nom en face de chaque montée en compétences.
Alors attention aux frustrations que ça pourrait générer. Premièrement, quand vous mettez en place ce type de système, il faut déjà être bien clair vis-à-vis des gens de votre équipe. Tout le monde ne pourra pas monter en compétence sur tous ses souhaits. C'est juste pas réalisable, on n'a pas forcément le budget pour. Donc voilà, on ne pourra pas tout faire. Et puis, deuxième frustration possible,
Attention à ne pas faire monter en compétence toujours les mêmes personnes. Essayez de répartir dans le temps les montées en compétence sur les différents équipiers. Après, évidemment, si vous avez quelqu'un comme Thibault qui ne veut monter en compétence sur rien du tout,
pas grand-chose à faire, on va l'exclure de la montée en compétences, tant pis. Mais voilà, attention à bien gérer les frustrations possibles que ça pourrait déclencher au sein de votre équipe. Donc là, on voit, c'est la partie qui était en bas de la matrice de compétences. C'est là où moi, j'indique à chaque fois la priorité des compétences sur lesquelles je veux monter. Je mets tout simplement 3+, 2+, 1+, et à chaque fois qu'une montée en compétence est faite, je rajoute une nouvelle compétence dans le scope de mes montées en compétences.
Bien.
Donc, on sait ce sur quoi on a besoin de monter en compétence, on a priorisé, on a mis les personnes en face. Parfait. Maintenant, comment on va concrètement organiser cette montée en compétences? Alors, il y a plein, plein, plein de manières de faire. Je ne vais pas rentrer trop dans les détails, on va balayer quelques manières de faire. D'ailleurs, moi, je serais très intéressé dans la phase questions-réponses qui suivra, si vous avez des remarques, des recettes, des choses qui marchent très bien dans vos équipes, Ça pourrait être intéressant d'en discuter ensemble.
Donc comment on organise cette montée en compétences? Premièrement, on peut aller regarder à l'extérieur de l'équipe.
On peut tout simplement faire des formations. On peut faire venir un expert. Alors que ce soit un expert interne à notre boîte, on va demander l'aide d'un architecte, ou alors faire venir un consultant extérieur.
Alors ça, c'est très très bien, mais c'est potentiellement coûteux, surtout si on fait intervenir des éléments extérieurs à l'équipe. Envoyer toute une équipe en formation de deux jours, Ça a un coût dans notre budget.
Donc ça peut être efficace, mais c'est coûteux, donc c'est à manipuler vraiment avec précaution. Il y a un autre élément qui est assez souvent négligé au final, et qui pourtant lui n'est pas du tout coûteux, C'est, je ne sais pas si vous connaissez les Innovation Games de Lucoman, qui sont tout un tas de techniques d'animation, de réunion, qui nous permettent de créer de l'innovation. Entre autres, il y a un exercice que j'aime beaucoup, qui est décrit dans ce livre, qui s'appelle Me and My Shadow. Et très basiquement, Me and My Shadow, c'est aller voir comment les autres travaillent. D'accord? Je m'assois à côté et je regarde. Pour apprendre le fonctionnel, pour apprendre le métier qu'il y a derrière le produit sur lequel on travaille, si on a accès à nos utilisateurs finaux, allons les voir travailler, tout simplement. Je viens deux heures, je m'assois à côté de toi, je regarde comment tu utilises mon produit. Et je ne te dérange pas. Éventuellement, s'il y a des points que je ne comprends pas, je te demande de m'expliquer. Mais j'interviens le moins possible. Je regarde mon produit, à quoi il sert. Le module de contact, qu'est-ce qu'il fait exactement? Comment? Tu t'en sers. D'accord? Et là, je vais pouvoir monter en compétence assez facilement et à un coût assez faible.
Je vais pouvoir monter en compétence sur toute la partie métier. Ok? Donc, pour organiser nos montées en compétences, on peut effectivement aller regarder à l'extérieur de notre équipe. Maintenant,
Pour monter en compétence, on peut aussi regarder tout bêtement à l'intérieur de notre équipe et partager la connaissance au sein de notre équipe. Alors, je vous ai remis l'échelle que moi j'utilise habituellement. Donc, zéro, aucune connaissance sur le sujet. Un, connaissance partielle mais pas autonome. Deux, autonome sur le sujet, 3. Confirmé, capable de former des gens sur le sujet, 4. Expert, je suis le référent sur mon sujet dans l'équipe, voire à l'extérieur de l'équipe.
Donc tout va dépendre de quel gain de niveau on veut faire. Donc ce qu'on peut faire par exemple, je veux passer d'un niveau 0 à un niveau 1, on peut se contenter de faire une formation théorique, une présentation commentée du code, de l'architecture, une démonstration de l'utilisation d'un module métier. Pour passer du niveau 0 au niveau 1, formation, démonstration, présentation.
Et donc, le« me on my shadow» que je mets un peu à la frontière entre l'interne et l'externe, ça dépend du contexte.
Passer du niveau 1 au niveau 2, c'est-à-dire s'autonomiser sur le sujet, il faut pratiquer. Mais pour pratiquer, quand on n'y connaît pas grand-chose, le plus simple, c'est de pratiquer avec quelqu'un. Donc, un excellent moyen de faire, c'est du pair programming. Par exemple. D'accord? Alors, je pense que vous êtes un certain nombre à être familier avec la notion de pair programming. Pour ceux qui ne connaissent pas, c'est très simple. On va être deux devant un clavier, d'accord? À travailler sur un unique sujet. Et on fait passer le clavier de l'un à l'autre régulièrement. OK?
Et donc la personne qui code peut expliquer ce qu'il est en train de faire, la personne qui est à côté peut poser des questions sur pourquoi tu fais les choses comme ça. Qu'est-ce qui te passe par la tête là en ce moment? Pourquoi tu es en train de faire cette chose? Donc du pair programming, ça, ça marche plutôt pas mal.
Je vais me permettre une toute petite digression d'ailleurs. Donc là, on est en train de parler. Mon cas d'école, c'est j'arrive dans une équipe déjà constituée et j'essaye de répartir la connaissance sur ce qui existe déjà. Le pair programming, c'est un outil extrêmement puissant que vous pouvez aussi utiliser. Avant que vous ayez besoin de partager la connaissance, vous avez un nouveau module qui arrive, vous avez des choses très compliquées à faire dessus, faites du pair programming d'entrée de jeu. Ça sera toujours moins coûteux de faire le partage de connaissances dès le début que de le faire un petit peu plus tard. Je vous conseille très fortement, sur les points épineux que vous pourriez rencontrer dans vos projets, d'entrée de jeu, mettez-vous au pair programming.
Fin de la parenthèse. D'autres possibilités de monter en compétence de niveau 1 au niveau 2, c'est de faire des dojos. D'accord? Alors les dojos, c'est tout simplement une personne... Explique des choses, plusieurs personnes sont devant à écouter, un unique ordinateur, un clavier, on fait tourner le clavier, on programme ensemble et on apprend des choses ensemble. D'accord?
Alors le dojo, on va souvent, pas forcément, mais on peut le faire sur des sujets théoriques, pas forcément sur des vrais éléments de notre application. On va apprendre des choses.
Quelque chose qui est à la frontière du dojo et du pair programming, c'est ce qu'on va appeler le mob programming. On travaille tous ensemble sur une unique fonctionnalité. D'accord? Donc ça, ça marche pas mal aussi. Je vais me permettre de faire de la publicité pour un ami sur le blog de SWAT. Si vous ne connaissez pas le mob programming, il y a un article très didactique sur le sujet que je vous enjoins très fortement à lire. C'est assez intéressant.
Passer du niveau 2 à du niveau 3, donc on est déjà autonome, mais on veut vraiment monter en compétence sur le sujet.
On n'a pas besoin d'un encadrement aussi précis que du pair programming, mais on peut faire par exemple ce qu'on appelle du mentoring. Du mentoring, c'est je vais prendre un sujet sur lequel je ne suis pas encore très très confort, une personne qui connaît va m'expliquer un petit peu globalement les pièges à éviter, l'architecture dans laquelle il faut évoluer, les points d'attention, tout ça, voilà. Ok, je vais bosser en autonomie sur le sujet, et ensuite, relecture de code avec la personne à côté de moi, et on voit, on commente, etc. Et on apprend.
De manière générale, faire du code review aussi, ça nous permet de monter en compétences.
Enfin, devenir expert. Devenir expert, il faut pratiquer. Et éventuellement, là, on va aussi pouvoir sortir de l'équipe et regarder des communautés de pratique hors de notre équipe, plus largement dans notre organisation.
Donc voilà un certain nombre de possibilités qu'on peut mettre en place pour faire du partage de connaissances et de la montée en connaissances. Bien évidemment, ce ne sont pas les seuls. Je ne vous ai mis là que quelques exemples que moi j'applique assez régulièrement sur mes projets.
Alors, c'est très bien tout ça.
Mais concrètement, on fait ça sur quel tempo? Il ne faut pas oublier qu'on a un client en face qui nous attend. On doit livrer des choses, on doit produire de la valeur. D'accord? Donc sur quel tempo? Donc le premier point, on en a déjà parlé. c'est qu'on va prioriser. Est-ce qu'on a des urgences déjà? Est-ce qu'on a des gros gros risques qu'il faut à tout prix juguler? Est-ce qu'on a des opportunités qui arrivent très rapidement et qu'il faut vraiment être capable de prendre en compte? Donc on va prioriser les choses. Une fois qu'on a priorisé, on va... Moi ce que je mets en place, pour une fois il y a d'autres manières de faire, mais moi ce que j'aime bien mettre en place c'est des sessions. De monter en compétence. Alors, suivant la taille des équipes, je vais programmer une ou deux sessions par semaine de monter en compétence. Des sessions d'entre deux heures et une demi-journée, ce qui est à peu près la même chose suivant le rythme de vos équipes, après ça vous voyez. Donc on va mettre en place des sessions de montée en compétences. Et ces sessions de montée en compétences, moi je les trace pour être certain de ne pas les oublier, pour être certain que pris dans la panique, ah oui tiens on devait travailler sur tel sujet mais je n'ai pas eu le temps. Je les trace. Donc là je vais me servir du management visuel. Je peux utiliser des post-it d'une couleur particulière, je peux mettre un... Mettre un maniette d'une couleur particulière pour dire, là, attention, sur ce sujet-là, on va faire de la diffusion de connaissances. Bon, ça, on trouve les manières de faire, mais on le trace et on ne l'oublie pas.
Éventuellement, quand on va trouver le bon tempo, quand on va mettre en place ce genre de choses, on peut avoir des pressions externes qui vont nous dire« Ouais, c'est gentil, mais pendant que tu fais ça, tu n'es pas en train de livrer de la valeur, ou du moins tu ne la livres pas aussi vite que ce qu'on attend. » Donc là-dessus, éventuellement, un bon relais, c'est de s'appuyer sur les ressources humaines. Ce qu'on fait, monter les gens en compte. Encore une fois, on participe à la motivation des gens. Donc ça peut être extrêmement intéressant de s'appuyer sur les ressources humaines. Et un dernier point d'attention sur le sujet, on a dit, donc on a des personnes qui apprennent, et puis on a des personnes qui vont apprendre aux autres. Alors là aussi, petit point d'attention. Ne vous focalisez pas, ne vous appuyez pas toujours forcément sur les mêmes personnes. Ok? Alors, là encore, il n'y a pas de règle absolue. Il y a des gens qui vont adorer diffuser leur savoir. Il y a des gens qui ne vont pas beaucoup aimer. Donc voilà, faites attention. Dans une entreprise de binomage, le sachant, il faut qu'il soit volontaire et il faut qu'il soit motivé pour le faire. Sinon, ça ne va pas très bien se passer. Donc attention aussi.
À ce point-là.
Bien.
Donc maintenant c'est bien, on sait qui, on sait quoi, on sait sur quel rythme. Donc maintenant, on y va, c'est parti. Donc je vous l'ai dit, un des bons moyens pour que ça marche dans le temps, c'est de le tracer et de l'afficher. On utilise la puissance du management visuel pour s'assurer que c'est fait effectivement. Alors attention sur ce management visuel, j'ai rencontré ça très rarement, mais je l'ai déjà rencontré. Il y a des gens qui n'aiment pas que ce soit affiché, qui sont en train d'apprendre des choses, parce que ça sous-entend qu'ils ne connaissent pas. Donc, il faut des fois faire attention avec quelques susceptibilités. C'est quand même assez rare.
Pour que ça marche dans le temps, il faut aussi que vos matrices soient à jour. Ah oui, on a des gens qui montent en compétences. Donc la matrice de compétences, forcément, elle évolue. Et puis on a des nouvelles colonnes qui vont peut-être apparaître, on a des nouvelles compétences dont on va avoir besoin. Donc il faut maintenir nos matrices. Et puis on ne va pas les maintenir, ce n'est pas moi, responsable d'équipe, qui vais les maintenir. Je sais qu'il y a eu telle montée en compétences, ok, j'augmente. Ma compétence? Non, bien évidemment je le fais remplir par tout le monde parce qu'il y a des montées en compétence dont je ne vais pas forcément avoir conscience. Les gens montent en compétence aussi par eux-mêmes. Donc voilà, maintenir, challenger la liste des compétences pour que ça puisse durer dans le temps.
Et donc une fois qu'on a pu mettre tout ça en place, on est maintenant rentré dans un cercle vertueux où nos équipes vont pouvoir s'améliorer. Donc on est clairement dans de la pure amélioration continue. Et on va pouvoir aller un step plus loin et pourquoi pas diffuser. On a des gens qui sont montés en compétence, on a des gens qui savent faire des choses. Eh bien, allons partager ça avec les autres équipes. Et comment? Par exemple, allons animer des dojos dans les autres équipes. Et là, ça va être un échange de bons procédés. Je viens animer un dojo sur tel sujet dans ton équipe, tu viens animer un dojo sur tel sujet dans mon équipe, et on va pouvoir comme ça diffuser la connaissance. La répartir au sein de toute notre organisation. Et donc, on réduit d'autant nos risques, on amène de la sérénité dans nos équipes. Très prosaïquement, les gens peuvent prendre des congés quand ils veulent, sans mettre le projet en péril. Mine de rien, c'est important.
On augmente les possibilités de nos équipes, on augmente les opportunités qu'on va offrir à nos clients, et puis on a des gens largement plus motivés, et donc ils vont mieux travailler. Voilà ce que j'avais à vous dire sur le sujet. J'espère que ça vous a intéressé. Et puis, si vous avez des questions sur tout ça, si vous avez envie de partager avec nous ce que vous, vous mettez en place, ou éventuellement les freins que vous, vous avez pu rencontrer sur des mises en place,