Passation, "I always follow the rules"

Montée en compétence difficile? Voici quelques guidelines utiles!

La montée en compétences sur un projet tout comme l’arrivée au sein d’une nouvelle équipe impliquent des passations de connaissances parfois importantes. Il est alors facile de se retrouver avec des “trous dans la raquette” au niveau des informations et processus de travail. L’idée de cet article est de donner, à la manière de Zombieland, quelques conseils et règles à suivre lors d’une passation afin de garder le bon cap.

#1 Infos are like your cardio

La première étape, après avoir rencontré les différents membres de l’équipe, est de bien identifier les principaux intervenants du projet. La construction d’un produit implique souvent plusieurs entités d’une même entreprise possédant chacune des problématiques propres. Il est alors important d’identifier les personnes qui seront en mesure de fournir la bonne information. L’idée n’est cependant pas d’apprendre un organigramme par cœur, mais d’identifier, dans un premier temps, la ou les personnes avec qui vous serez amenés à travailler le plus souvent.

#2 A little process never hurts anybody

Connaître les processus de travail existants, ainsi que les pratiques de travail ou les workflows, donne un bon aperçu des priorités de l’équipe. Une colonne “Revue de code” dans le board de l'équipe, par exemple, montre l’importance portée à s’accorder sur des conventions de rédaction du code. De même, la “Definition of ready” permet au Product Owner de comprendre les attentes et exigences de l’équipe en termes de définition du besoin. Cette connaissance peut aider à déceler de potentiels axes d’amélioration.

#3 Spec up

Une fois les référents identifiés et le mode de travail acquis, il est temps de rentrer plus en détail dans le fonctionnement du produit. Pour cela, il est bien d’avoir un accès à la plateforme de test pour pouvoir jouer différents scénarios fonctionnels, ainsi qu’une description des différentes fonctionnalités de l’application la plus à jour possible (Backlog Produit, spécifications fonctionnelles, story map...). Ces informations offrent au Product Owner une première idée de la vision du produit, de son fonctionnement.

#4 Check the back seat

Lors de la récupération d’un projet (changement de sous-traitant par exemple) ou de l’arrivée sur un projet, il est important de faire une sorte d’audit de l’existant. Le nombre total d’anomalies ou encore de la présence de tests (tests fonctionnels automatisés par exemple) permet, entre autres, d’évaluer la santé du produit. Cette analyse permet d’identifier de futurs chantiers tant techniques que fonctionnels à mettre en place : automatisation des tests, redéfinition d’une feature ou d’un parcours client, amélioration de l’expérience utilisateur.

#5 With a bug, you know your way out

Cette règle va souvent de paire avec la #3, une bonne manière d’appréhender le fonctionnel est souvent d’y rentrer via les anomalies. En effet, une anomalie est décrite par une action réalisée en entrée et un fonctionnement attendu bien défini en sortie. L’analyse d’une anomalie permet de creuser plus en profondeur une fonctionnalité, de comprendre le problème auquel elle répond ainsi que les contraintes qu’elle comporte.

#6 The buddy system

Une chose importante lors d’une passation est de s’assurer que l’on ne s’égare pas. Il est essentiel de faire des points réguliers avec un membre de l’équipe ou du métier. Pour un Product Owner ces points de synchronisation quotidien ou hebdomadaire avec un référent fonctionnel sont l’occasion de poser certaines questions (organisation, contexte, vocabulaire...), ils permettent de se focaliser sur les sujets prioritaires à court terme. Pour un développeur ce point peut, par exemple, consister à travailler en pair programming régulièrement pour assurer un bon transfert de connaissances.

#7 Don’t be a hero

Cette règle triviale est essentielle lors d’un transfert de connaissances : il faut avancer sur seul un sujet à la fois et éviter à tout prix le multitasking. Essayer d’aborder tous les sujets de front est le meilleur moyen de s’égarer et perdre de vue l'objectif. Lors de la récupération d’un projet par exemple, la durée du transfert est bornée. Il est donc très important de se concentrer sur la compréhension des fonctionnalités les unes après les autres par ordre de priorité. Traiter plusieurs sujets en parallèle risque de vous faire rater certaines contraintes fonctionnelles cruciales.

#8 Enjoy the little things

Enfin, même si certains produits peuvent paraître plus complexes ou en “moins bon état” que d’autres, il est toujours intéressant d’identifier les points forts d’un produit. Qu’il s’agisse d’une usine logicielle bien en place ou d’une fonctionnalité phare “sexy”, ces points forts permettent de vous motiver, vous intéresser et sont sources d’inspiration pour les améliorations d’autres facettes du projet.

Ces règles, comme "the list of rules" de Zombieland, ne sont pas absolues mais elles forment de premières guidelines permettant d’être autonome et de monter en compétence plus sereinement sur de nouveaux projets.