[Lean Kanban France 2014] Organiser une politique de montée en compétences

Lors de la toujours passionnante conférence Lean Kanban France, édition 2014, j’ai eu le plaisir de présenter une session sur l’organisation de politique de montée en compétences au sein d’une équipe. L’objet de cet article n’est pas de faire un compte-rendu de la session en tant que telle, mais plutôt de mettre par écrit les différents points abordés lors de cette présentation. Nous allons donc voir tout d’abord pourquoi, et ensuite comment, organiser une politique de montée en compétences au sein d’une équipe ou d’une organisation, et ce de manière ciblée, pérenne et efficace.

Pourquoi partager les compétences dans une équipe

Avant d’entamer la mise en place d’une telle politique (et comme on devrait le faire avant d’entamer n’importe quelle action), la première question à se poser est « pourquoi » ? En effet, mettre en place ce type d’action sera forcément coûteux. D’une manière ou d’une autre, la productivité de l’équipe sera dans un premier temps affectée, ce qui peut être difficile à accepter par notre client.

Donc, pourquoi ? Tout d’abord, faisons un constat : les gens, dans nos équipes, sont spécialisés. Que ce soit sciemment, par une décision lors de la constitution d’une équipe, ou par la pratique, les membres de l’équipe acquérant des compétences spécifiques en début de projet puis restant dans leur zone de confort. En soit, ce n’est pas forcément une mauvaise chose. En effet, avoir un spécialiste dans un domaine (technique ou fonctionnel) est toujours rassurant, et l’on peut être certain que notre spécialiste pourra répondre rapidement et efficacement aux problématiques qui lui sont soumises.

Cependant, ce n’est pas forcément une bonne chose, et ce pour au moins trois raisons :

• La motivation. Savoir qu’il va être possible tout au long du projet d’apprendre de nouvelles choses, que ce soit d’un point de vue technique ou d’un point de vue fonctionnel, est un facteur très important de motivation, participant de ce fait à l’efficacité des équipes.
• Le facteur bus. Sous ce nom étrange se cache une théorie un brin morbide mais terriblement révélatrice : si jamais demain, un de vos coéquipiers venait à se faire renverser par un bus, votre projet s’en remettrait-il ? Si vous répondez non à cette question, vous avez un gros problème… Sans allez à de telles extrémités, que faire si cette personne tombe malade ? Ou tout simplement décide de prendre des congés ?
• La perte d’opportunités. Imaginons que dans votre équipe, vous ayez une personne spécialisée sur un module de comptabilité, et une autre sur un module de vente. Vous avez de nombreux développement à faire, et ceux très prioritaires concernent tous la comptabilité, de quoi vous occuper un bon mois. Malheureusement, par manque de compétences dans l’équipe, vous allez devoir réaliser en parallèle des développements beaucoup moins prioritaires, retardant d’autant la réalisation des fonctionnalités prioritaires, et risquant de mécontenter le client ou de rater des opportunités commerciales.

Identifier les connaissances de l’équipe : la matrice de compétences

Il est donc important de partager les connaissances au sein de l’équipe. Attention, il ne s’agit pas d’avoir une équipe de génies tous experts en tout ! Ce ne serait pas réaliste, ni même forcément souhaitable. Il s’agit simplement de couvrir nos risques et d’augmenter nos opportunités.

Pour ce faire, la première étape est de faire un état des lieux. Qu’est-ce que mon équipe est capable de faire ? Pour le savoir, nous allons mettre en place une matrice de compétences. Pour établir une telle matrice, nous allons commencer par lister l’ensemble des compétences, que ce soit techniques ou fonctionnelles, qui sont nécessaires au travail de mon équipe. On peut aussi rajouter des compétences pas encore nécessaires mais qui pourraient le devenir dans un futur proche.

Une fois cette liste établie, on va demander à chaque membre de l’équipe de s’évaluer sur chacun des points. Pour qu’une auto-évaluation soit efficace, il faut que l’échelle proposée soit explicite. Voici, par exemple, celle que j’utilise le plus souvent :

0 – Aucune connaissance sur le sujet

1 – Connaissances de base sur le sujet

2 – Autonome

3 – Capable de former sur le sujet

4 – Expert, référent sur le sujet

Identifier les envies de l’équipe : la matrice de souhaits

Maintenant que nous savons ce que notre équipe sait faire, nous allons nous intéresser à ce qu’elle a envie de faire. En partant de la même liste de compétences, nous allons créer une matrice de souhaits. On va demander à chaque personne de noter les compétences sur lesquelles elle a envie de monter en compétence. On laissera sans annotation les compétences sur lesquelles on n’a pas d’avis particulier. Et on a aussi tout à fait le droit de ne pas rester neutre, et d’indiquer explicitement les compétences sur lesquelles on n’a pas du tout envie d’en apprendre d’avantage.

Attention à votre discours lorsque vous faites remplir une matrice de souhaits : il est capital de bien préciser à votre équipe que tous ne pourront pas forcément monter en compétence sur l’ensemble de leurs centres d’intérêt. Si vous n’êtes pas tout de suite très clair sur ce sujet, vous risquez de faire naître des frustrations.

Identifier les besoins du projet

En parallèle de la création de la matrice de souhaits, le responsable d’équipe va pouvoir identifier les risques et les besoins de son projet à partir de la matrice de compétences. L’objectif est d’identifier les endroits où il va être prioritaire d’organiser les montées en compétences. On privilégiera en premier les endroits où des risques majeurs sont détectés, pour s’intéresser dans un second temps aux possibilités d’augmentation des capacités de l’équipe.

Attention, identifier les besoins n’est pas forcément trivial : en effet, vous allez parfois avoir une seule personne compétente sur un sujet, ce qui est potentiellement risqué, mais parfois c’est un risque totalement acceptable car il s’agit d’un sujet totalement mineur de votre projet. A l’inverse, vous pouvez vous retrouver avec plus de la moitié de votre équipe compétente sur un sujet donné, et estimé que ce n’est pas encore suffisant, en partant du principe que la grande majorité des développements à venir porteront sur ce sujet.

Qui / quoi / comment ?

Nous savons maintenant ce que notre équipe sait faire. Nous savons ce que les personnes ont envie d’apprendre. Nous connaissons aussi les manques les plus importants de notre projet. Comment organiser tout ça pour mettre en place notre montée en connaissance ?

Le premier point est d’identifier, à partir de la matrice de souhaits, qui nous allons faire monter en compétence sur quel sujet. Pour ce faire, plusieurs paramètres sont à prendre en compte. Tout d’abord, essayer de répartir les montées en compétences sur l’ensemble des membres de l’équipe. Evitez de tout focaliser sur une ou deux personnes. Ensuite, comme nous le verrons par la suite, la montée en compétence requiert souvent la participation d’un membre de l’équipe possédant la connaissance nécessaire. Assurez-vous donc que ce n’est pas toujours la même personne qui se retrouve sollicitée, ou, si vous ne pouvez pas faire autrement, que cette personne soit volontaire pour ce rôle. Certaines personnes sont en effet très friandes du rôle de mentor.

Maintenant, il va nous falloir réfléchir au rythme à mettre en place. En effet, comme on l’a dit, monter en compétence coûte cher. Pendant qu’une personne travaille sur un sujet qu’elle ne maîtrise pas, elle est forcément moins productive que lorsqu’elle officie dans son domaine de prédilection. De même, elle sera souvent accompagnée d’un « sachant », qui lui aussi se retrouvera moins productif. La montée en compétence est un investissement, et comme tout investissement, elle a un coût. Il va donc falloir faire en sorte que ce coût soit le moins élevé possible.

Il n’y a pas un unique bon rythme, tout est dépendant de la taille de votre équipe, de votre contexte, et de l’éventuelle urgence à pratiquer les montées en compétence. Néanmoins, pour donner un exemple, j’ai tendance à partir sur un rythme de deux sessions de montée en compétence par semaine, chaque session faisant entre 2h et une demi-journée. J’utilise d’autre part le tableau blanc de l’équipe pour tracer ces sessions et m’assurer qu’elles aient bien lieu quoiqu’il arrive.

Nous allons maintenant évoquer différentes manières d’organiser les montées en compétence, en repartant de l’échelle que nous avons présentée précédemment. Bien évidemment, il en existe d’autres.

Passage du niveau 0 à niveau 1

Le premier pas dans un nouveau domaine de compétence passe par la formation. Il peut s’agir tout d’abord d’une formation donnée par un intervenant extérieur. Néanmoins, cette solution est plutôt coûteuse. L’autre possibilité est d’utiliser les compétences internes à l’équipe. Une présentation formelle d’un module, une présentation illustrée d’une architecture, une lecture commentée du code peuvent permettre d’acquérir les premières bases de connaissance sur un sujet donné.

L’autre possibilité, plus orientée sur les compétences fonctionnelles, est d’aller voir, sur le terrain, comment le métier travaille. Aller passer deux heures à côté d’un utilisateur final, le voir utiliser un module spécifique de notre outil, va être extrêmement formateur.

Passage du niveau 1 à niveau 2

Pour gagner en autonomie sur un sujet, le pair-programming peut être un excellent moyen. L’idée est de faire travailler sur un seul poste, avec un unique clavier, une personne connaissant bien le sujet et un apprenant. Régulièrement, on fait changer le clavier de main, la personne qui tient le clavier expliquant ce qu’il fait à son voisin, celui-ci pouvant commenter ou poser des questions.

Sur un mode un similaire, on peut aussi penser au mob-programming (sur le sujet, je vous renvoie sur ce très bon article).

Si les compétences au sein de l’équipe font défaut, on peut aussi envisager de se faire accompagner par un expert externe à l’équipe sous forme par exemple d’un coding dojo.

Passage du niveau 2 à niveau 3

Un des moyens pour passer du niveau 2 au niveau 3 est de travailler sous forme de mentoring. Au moment de prendre un nouveau sujet, le sachant va discuter avec l’apprenant pour lever les difficultés, discuter des pièges éventuels, noter les points d’attention. Il laisse ensuite l’apprenant travailler en autonomie. A la fin de la session de travail, il vient valider avec lui son code par une relecture en sa compagnie.

De manière plus globale, généraliser le pair review (c’est-à-dire la relecture du code que l’on a produit par un autre membre de l’équipe plus compétent sur le sujet) est une excellente manière de progresser sur un sujet.

Entretenir la montée en compétence

Une fois la politique de montée en compétences mise en place, il va falloir s’assurer que ce cercle vertueux s’entretienne dans le temps. On l’a dit précédemment, l’utilisation du management visuel est un bon moyen de s’assurer que les décisions prises dans ce sens seront suivies. Un autre point à ne pas oublier est de régulièrement mettre à jour nos matrices : les compétences des gens vont s’améliorer (du moins on l’espère !), les envies peuvent changer, de nouveaux besoins ou de nouvelles opportunités vont apparaître dans le projet… Régulièrement (une fois par trimestre par exemple, plus fréquemment au besoin), nous pourrons ainsi mettre à jour nos indicateurs.

L’étape suivante étant de sortir du cadre strict de votre équipe : vous allez pouvoir diffuser vos compétences dans votre organisation, en organisant par exemple des présentations ou des coding dojo pour des membres d’autres équipes, qui pourront venir vous rendre la pareille, diffusant ainsi la connaissance à une vaste échelle, en réduisant les risques et en augmentant les opportunités et la motivation de manière générale.

© SOAT
Toute reproduction interdite sans autorisation de la société SOAT