Réussir son transfert de connaissances dans un projet IT

Les démarches à entreprendre avant de procéder à un transfert de connaissances

Avant d’aborder le sujet principal, il est important de bien cadre le sujet. Pour vous assurer que la passation se déroule dans de bonnes conditions et éviter de négliger les sujets, je vous propose d’établir (et renseigner) la checklist suivante :

• Cadrer la transmission du savoir (contenu, périmètre)
• Évaluer les connaissances et les ressources de l’équipe qui va recevoir les informations. (Compétences et connaissances préalables)
• Lister les sujets par domaine fonctionnel, technique et tests (cartographier le travail à réaliser)
• Mettre en place un document qui comporte le détail du planning pour l’ensemble des semaines (roadmap)
• Mettre en place un document de suivi au cours du processus (pilotage, méthodes de travail et indicateurs de réussite)
• Préparer les documents nécessaires pour les divers ateliers (outiller)
• Faire une première réunion avec toutes les personnes concernées, manager compris (organiser le kick-off)

Comment se déroule le transfert de connaissances ?

Au cours du processus, il est essentiel de garder en mémoire le but premier d’un transfert de connaissances :

Rendre possible à une nouvelle équipe de comprendre, d’utiliser et de maintenir efficacement l’application

Le cadrage du transfert

Il peut prendre en compte plusieurs aspects : la partie fonctionnelle, technique (orienté développement) et la partie sur la stratégie des tests. Il sera important de lister l’ensemble des sujets à évoquer dans chacun de ces domaines afin de ne laisser aucun élément de côté.

Ce cadrage doit également prendre en compte la notion de temps. Pour cette transmission la durée avait été estimée à 3 mois. Durant ces 3 mois, nous devions prendre en compte la formation de la nouvelle équipe mais également la prise en main de l’application par cette nouvelle équipe. L’objectif était de réaliser les dernières évolutions durant cette période de transfert et qu’à la fin l’ancienne équipe n’ait plus qu’à assurer le support applicatif.

Une fois que l’ensemble des sujets sont établis vous pourrez mettre en place un planning (sous le format d’une roadmap par exemple). Ce planning permettra de suivre l’avancement du transfert de savoir et de le réajuster si besoin. Sur ce document, vous pourrez également spécifier les retours de la nouvelle équipe, est-ce qu’elle est confiante sur le sujet ? S’il manque des informations, s’il y a besoin de faire de nouveau un atelier sur le sujet pour l’approfondir, etc.

En amont nous avions pu échanger avec la nouvelle équipe pour mieux comprendre les compétences de chacun et leurs domaines d’activité initiaux. Cela nous a permis d’adapter notre approche lors des ateliers.

Le cadrage du transfert de savoir, la liste des sujets et la prise en compte des connaissances de chacun sont maintenant faits. Pour réellement débuter le sujet, une réunion avec l’ensemble des personnes de l’ancienne équipe et de la nouvelle équipe ainsi que les managers est à prévoir avant même de débuter les ateliers. Le thème de cette réunion sera d’aborder les prochains mois et leurs attentes, marquant ainsi le début.

Les ateliers et la comitologie

Les ateliers peuvent dès à présent débuter. Il n’existe pas de bon ou mauvais planning. De notre côté l’objectif était d’être dans une dynamique de passation de contenu progressive. Il est préférable d’avoir plusieurs ateliers, sans pour autant que ce soit très long. La semaine peut être constituée d’un atelier par jour sur un sujet spécifique (en fonction du planning mis en place plus en amont) et la séance de fin de semaine peut être gardée pour des questions/réponses. Chaque atelier peut durer de 1h à 2h (pas plus, car le risque est de perdre l’oratoire).

Dans mon cas, nous avions chaque jour un atelier à propos d’un sujet spécifique, à l’exception du vendredi. Aucun thème particulier n’était défini préalablement pour le vendredi, afin de réserver ce temps à un échange moins formel. C’était l’occasion d’une session de questions/réponses. Il y avait également la possibilité, à la demande de l’équipe, de voir ou revoir un contenu particulier.

Pour l’ordre des ateliers, nous avons opté pour débuter avec des séances sur des sujets fonctionnels puis dans un second temps nous avons mêlé le fonctionnel avec les parties techniques et stratégie de test.
Commencer par la partie fonctionnelle vise à assurer que chaque membre de la nouvelle équipe dispose des mêmes informations initiales pour entamer le processus de transfert de connaissances.

Il n’y a pas de méthodes fixes pour la conduite des ateliers, l’objectif principal est que, à la fin, la nouvelle équipe ait bien assimilé la thématique. Pour cela, au cours de chaque atelier je vous propose de :

• Mettre en place un document de support : Il permettra d’avoir un support mais également de résumer le sujet qui a été évoqué.
• Enregistrer l’atelier : Dans le cas où vous seriez à distance ou bien si vous faites une démonstration d’un outil. Les enregistrements sont toujours utiles et surtout ils permettent de conserver l’information et d’y revenir à tout moment.
• Déposer l’ensemble des documents, enregistrements, fichiers dans un répertoire partagé : (par exemple SharePoint). Pour plus de clarté vous pouvez créer un dossier par atelier avec la date de celui-ci et le titre du sujet. Dans ce dossier y déposer tous les éléments qui le concernent (document de support, vidéo, fichier, jeux de données, procédure, etc.)
• Par la suite la nouvelle équipe pourra s’y référer si elle en a besoin (ce sera plus efficace pour retrouver les informations).

Pour compléter le planning et s’assurer que tout se passe bien au cours des mois, il est préférable de mettre en place une réunion spécifique sur le suivi du transfert. Elle permet de faire un point sur les divers ateliers et de s’assurer de la compréhension et de l’avancement des sujets.

Cela peut être une occasion de rectifier le planning (naturellement à la fin de chaque atelier il est préférable de s’assurer que l’équipe a compris, s’ils ont des questions et s’il est nécessaire d’avoir un second atelier sur le sujet).

Le suivi, peut être mis en place toutes les 2 semaines. Dans cette réunion pourra être convié l’ensemble de l’équipe, si vous le souhaitez. Mais cet échange concerne davantage les managers, product manager et product owner (libre à chacun de choisir qui doit être présent). Il ne sera pas nécessaire que cette réunion soit longue, une demi-heure sera suffisante. Cela permettra de faire un récapitulatif des semaines précédentes et de passer sur le document de suivi (mis en place en amont) pour indiquer si chaque sujet est approuvé.

Quelques éléments clés

Il est crucial de rester focalisé durant cette période, car le transfert de connaissances ne se limite pas à la tenue d’ateliers pour former l’équipe future en charge de cette tâche. C’est aussi garantir que l’application soit dans des conditions adéquates. Cela se traduit plus concrètement par :

• Une documentation à jour :

Dans les projets agiles, on voit malheureusement trop souvent des personnes négliger l’importance de la documentation (une mécompréhension des valeurs du Manifeste Agile). Cependant, c’est un élément crucial, comme j’ai pu le constater lors de ma dernière expérience. Dans le cadre de cette transition, nous nous sommes retrouvés sans documentation, ce qui nous a obligés à rétrospectivement examiner tout ce qui avait été mis en place au cours des cinq dernières années.

• Garantir que les éléments dans le développement soient clairs et qu’il n’y ait pas de code inutile.

Au cours de ma mission, nous avons été confrontés à un cas où une fonctionnalité n’avait jamais été déployée en production et n’avait plus de pertinence dans le contexte actuel. Par conséquent, il a été décidé de supprimer ce morceau de code. Si nécessaire, la nouvelle équipe pourra reprendre l’analyse de ce sujet.

• Communiquer officiellement sur la nouvelle équipe en charge de l’évolution de l’application
• La gestion des budgets en cours
• L’aboutissement des sujets en cours pour éviter toute complication pour la nouvelle équipe

Pour terminer sur cette partie, nous avons fait en sorte durant ces 3 mois qu’il y ait une évolution continue du transfert de savoir. Dans un premier temps l’accent a été mis sur l’apprentissage, permettant à la nouvelle équipe de développer toutes les compétences nécessaires en termes de fonctionnalités, de techniques et de stratégies de test. Ensuite, nous avons mis l’accent sur le travail en binôme pour favoriser une montée en compétences plus fluide. Cela implique notamment de prendre en compte certaines user stories pour mieux comprendre le code existant, rédiger de nouvelles user stories et élaborer des tests d’acceptances en vue des tests fonctionnels. Enfin, le troisième et dernier point consiste à faciliter la prise en main progressive de l’application par la nouvelle équipe jusqu’à ce qu’elle en maîtrise parfaitement tous les aspects.

Et l’Agilité dans tout ça ?

Pour plusieurs motifs, le transfert de connaissances a manqué d’agilité. Avec le recul de ces trois derniers mois, j’ai observé à plusieurs reprises que nous aurions pu aborder les choses différemment en faisant preuve de plus d’Agilité.

Cette partie est une prise de conscience sur tous les éléments qui ont pu être mis en place, en aucun cas elle ne remet en question ce qui a été cité en amont. Elle offre une perspective plus dynamique sur ce qui aurait pu être instauré pour enrichir la démarche en s’inspirant de différentes approches Agiles.
Lorsqu’on reprend l’ensemble des points qui ont été cité dans la première partie, nous pouvons dès le départ voir que plusieurs sujets peuvent être mis en place sous forme de backlog et de users stories.
Si nous utilisons JIRA, nous pouvons créer deux swimlanes, une pour la partie projet et une deuxième pour la partie transfert de connaissances.

En utilisant ces outils nous pouvons notamment :

• Mettre en place un backlog avec l’ensemble des sujets et établir un storymapping pour définir la roadmap du projet
• Rédiger des users stories pour chaque sujet et les prioriser dans les différents sprints
• Les sprints seront présents pour rythmer les 3 mois et pourront permettre d’avoir un suivi à un instant T, mais également un meilleur prévisionnel face à un projet qui comporte un grand nombre d’inconnues (rythme d’appropriation, absence de documentation, dynamiques d’équipes et bien d’autres).
• Un sujet sera considéré comme étant compris par l’ensemble de la nouvelle équipe une fois qui sera terminé/validé (en accord avec la Definition of Done). En construisant sa propre Definition of Done, l’équipe est maître du transfert de connaissances et de la définition des éléments essentiels à atteindre pour le réussir. Tant que la Definition of Done n’est pas respectée, cela pourra signifier que d’autres ateliers sont nécessaires.

Matrice de compétences

Par la suite, afin de bien orienter notre discours et analyser les points manquants nous aurions pu mettre en place une “matrice de compétence” (team competency matrix). Cette matrice a pour but de permettre à l’ensemble des membres de l’équipe de s’auto-évaluer en fonction de différents domaines de compétences. Dans cette matrice nous aurions pu définir celles-ci autour des maîtrises fonctionnelle, technique et de stratégie de tests.

Ces domaines pourraient alors regrouper les éléments suivants :

• Fonctionnel : Agilité Scrum, rédaction d’une user story, priorisation des sujets, mise en place d’une roadmap, analyse d’un nouveau produit, découpage du besoin etc.
• Technique: IntelliJ, Grails, Micronaute, JAVA, MEP, tests unitaires, GIT, Postman, etc.
• Stratégie de test : Squash, tests d’acceptance, tests détaillés au niveau fonctionnel, mise en place de la stratégie de test, etc.

Pour chaque sujet, les membres de la nouvelle équipe auraient exprimé leur auto-évaluation. En regard avec le niveau de maîtrise nécessaire estimé sur chacun de ces domaines cela aurait permis de mieux orienter nos ateliers et notre communication. Dans ma dernière expérience, nous n’avons pas poussé le niveau de recherche de la connaissance aussi loin.

Processus de transfert du savoir

Tout au long du processus du transfert de savoir, il ne s’agira pas uniquement de faire des ateliers théoriques. Il y aura également la pratique. C’est un domaine sur lequel nous pouvons travailler en pair (comme pour le pair-programming). Dans ce cadre nous pourrions nous assurer de mettre en binômes des membres de l’ancienne équipe avec la nouvelle. Au côté d’une personne plus expérimentée la montée en compétence de la nouvelle équipe sera bien plus rapide et facile. Cette méthode peut être mise en place pour l’ensemble des parties (fonctionnelle, technique et stratégie de tests).

Evidemment pour la partie technique, on pourra organiser du pair-programming entre une personne de l’ancienne équipe et une personne de la nouvelle équipe. Cela permettra à la personne de la nouvelle équipe de mieux comprendre l’organisation du code. Mais le pairing ne s’arrête évidemment pas à la partie technique et peut tout aussi facilement s’appliquer aux domaines fonctionnels (entre responsables métiers). C’est quelque chose que nous avions en partie fait, mais pour lequel nous aurions pu adopter une approche plus structurée (et systématique).

Pour faciliter encore le transfert de compétence, on peut également s’appuyer sur le principe des « 3 amigos », qui implique la tenue d’ateliers avec le Product Owner (PO), un ou plusieurs développeurs, et un testeur. Réunir métier, technique et test permet d’assurer une compréhension globale des sujets abordés. Pour chaque atelier prévu dans les divers sprints c’est un élément qui aurait pu être mis en place afin de ne pas compartimenter les sujets. C’est également une approche que nous aurions pu adopter préalablement (avant le démarrage des ateliers) afin de collaborer sur la construction des user stories pour les différents sujets.

En ce qui concerne le suivi du transfert de connaissance nous aurions pu également utiliser les cérémonies Scrum même s’il s’agit d’un sujet non technique.
Par exemple nous aurons :

• Le Daily : il permettra que chacun échange sur les sujets évoqués la veille et le jour j de remonter les difficultés ou alertes rencontrés et plus généralement de s’assurer de la bonne compréhension de nos différents sujets.
• Le refinement : il aura pour but de passer en revue les users stories qui sont prêtes et vérifier que les sujets sont complets et compréhensibles par tous les membres des équipes.
• Le sprint planning : pour la préparation du prochain sprint en présence de l’ancienne et de la nouvelle équipe. Plus précisément la composition du prochain sprint sur les sujets qui seront évoqués.
• Le sprint review : il aura pour but de clôturer le sprint et de vérifier que toutes les users stories ont été validées, ce qui aura pour signification que les ateliers de ce sprint été compris et que nous pouvons passer au prochain.
  Cette réunion fera notamment office de suivi du processus.

• La rétrospective : à la fin d’un sprint, organiser une rétrospective en présence de l’ancienne et de la nouvelle équipe afin d’échanger sur le ressentie du sprint qui vient de s’écouler, remonter les difficultés particulières (compréhension, temps, sujets), mais également analyser si nous pouvons nous améliorer dans le transfert de savoir dans les prochains sprints et comment.

Mes conseils et préconisations

À la suite de l’expérience que j’ai pu avoir au cours de ma mission, j’ai pu retenir plusieurs éléments.
Vous trouverez ci-dessous une liste de conseils « à faire » et « à éviter » pour mener à bien ce processus.

Cette liste n’est pas à suivre à la lettre, elle est proposée pour conseiller les personnes.

Les éléments que je vous recommande de mettre en œuvre

Documenter : que ce soit au début du projet ou au cours du projet, il est important d’avoir de la documentation et de s’assurer que celle-ci soit à jour. Je souhaite appuyer sur ce point car c’est un élément essentiel. Sur les projets, il n’est pas rare que la composition de l’équipe change au fur et à mesure.

Pour un nouvel arrivant il est plus facile de monter en compétence en ayant accès à de la documentation sur l’application. Autrement de la lenteur est à prévoir dans l’appropriation du savoir.

Dans notre cas présent, la documentation est un socle clé pour la nouvelle équipe. Répertorier les règles de gestion au fur et à mesure, est un point essentiel pour lequel je recommanderais même d’avoir une page ou un document spécifique avec l’ensemble des règles de gestion mise en place pour l’application. C’est une information utile au quotidien aussi bien pour les profils fonctionnels que les développeurs et l’accès à l’information doit être la plus simple possible.

Pratiquer : Vérifier que les membres de l’équipe comprennent l’application en faisant des cas pratiques.

Au cours du processus il est essentiel de faire des ateliers afin que la nouvelle équipe puisse avoir toutes les connaissances sur l’application. Pour la suite, il est également crucial, de permettre une bonne prise en main de l’application. Au cours du processus des développements, la nouvelle équipe doit commencer à animer différentes cérémonies agiles et analyser les nouveaux sujets au plus tôt. Au début l’ancienne équipe montrera comment faire, puis fera avec la nouvelle avec pour objectif final de ne plus être qu’en support de la nouvelle équipe, si elle en éprouve le besoin (c’est une approche shu-ha-ri).

Piloter : Mesurer la pertinence du transfert de connaissances et son efficacité. Si besoin réajuster au cours de la transmission les ateliers, en ajouter ou bien revoir le plan du déroulement de chaque atelier. Bien prendre en compte les attentes de la nouvelle équipe et ne pas hésiter à ajouter des ateliers spécifiques sur des sujets à leur demande.

Communiquer : Créer la confiance et établir une relation de proximité même quand on se trouve dans le cas où la nouvelle équipe est située dans une autre ville ou pays (comme ça pu être le cas dans mon projet). S’il est possible de faire un déplacement, n’hésitez pas. Il peut même être judicieux d’en organiser un minimum de 2 (début et fin de projet). Le fait d’avoir toutes les personnes au même endroit facilite les échanges et la compréhension des sujets.

Les éléments qui sont à éviter :

Le défaut de connaissance : Un manque de connaissances sur l’application peut engendrer un travail supplémentaire conséquent. Il est essentiel avant de débuter le transfert de connaissances de s’assurer que chaque personne qui compose l’équipe initiale a une connaissance acceptable sur l’application.

Le défaut de soutenabilité : Attention au rythme des ateliers dans la semaine. Nous étions au rythme d’1 atelier par jour. Ce qui signifie que dans la semaine nous étions à 5 ateliers, 4 sur des sujets précis et 1 (en fin de semaine) sur des questions, réponses, retours sur un sujet spécifique. C’est une cadence qui était relativement soutenue. Avec le recul, un atelier tous les 2 jours auraient pu être tout aussi cohérent.

Le défaut de disponibilité : Il se peut que la nouvelle équipe n’ait pas été mise en place spécifiquement pour l’application qui arrivera chez eux prochainement en gestion. Certaines personnes ne sont potentiellement disponibles qu’à 50 % quand d’autres le sont à 100 %. C’est un élément à prendre en compte, et il faudra ajuster le planning en conséquence.

Dans le meilleur des mondes, la nouvelle équipe doit être disponible à 100 %. A minima il faudra s’assurer que toutes les personnes qui la composent soit présentes à l’ensemble des ateliers.

Le défaut de contexte :  Pendant le transfert de connaissances la vie ne s’arrête pas par ailleurs. Il est important de bien garder en tête la globalité des sujets à traiter en parallèle (qui n’ont pas forcément de lien direct avec la passation). Il faut y prêter attention, car cela peut demander autant d’investissement que le transfert de connaissances. Ces différents sujets annexes ne doivent pas impacter le transfert. Il est donc nécessaire d’y prêter attention dès le début et avertir les différentes personnes ou services que certains sujets seront dépriorisés du fait du processus de transfert de connaissances en cours.

L’aboutissement du transfert de compétences

Mener à bien un transfert de connaissances sur une application est un processus complexe mais qui se révèle essentiel pour assurer une transition fluide et efficace des connaissances au sein d’une nouvelle équipe. À travers ce processus, nous avons identifié plusieurs éléments qui ont contribué à la réussite de celui-ci, la formation et l’accompagnement, la communication, la cohésion d’équipe et pour terminer la surveillance de la bonne compréhension des sujets.

En résumé, le transfert de connaissances d’une application informatique à une autre équipe est un processus stratégique qui exige une planification minutieuse, une documentation approfondie, une formation adéquate et une collaboration continue pour garantir le succès de la transition et la continuité. Et même s’il ne s’agit pas d’un projet technique, rien n’interdit d’utiliser une approche Agile. Bien au contraire, les principes d’expérimentation, adaptation et amélioration, ainsi qu’une forte communication seront de forts accélérateurs d’un transfert réussi !

Les sources :

• Pour faire un rappel du Manifeste Agile : Découvrez le manifeste agile
• La méthode Shu-Ha-Ri : Shu Ha Ri, L’art martial de l’agilité, ou les étapes de maturité des équipes agiles
• La méthode des 3 amigos : Tout savoir sur les 3 Amigos de l’Agilité !
• Explication du story-mapping : Réussir tes ateliers de Story Mapping
• La matrice de compétence : Matrice de compétence d’équipe
• La definition of done : La « definition of done », un impératif de la qualité du produit
• Le pair programming : Pair programming : coder en binôme, bonne ou très bonne idée ?