Quand vous arrivez dans un pays étranger dont vous ne connaissez pas la langue et que vous souhaitez échanger avec des locaux, quel est votre premier réflexe ? Ok, parler avec les mains. On ne va pas se mentir, ça n’est pas le plus pratique.
Quel est votre deuxième réflexe ? Aller sur Google translate (ou acheter un dictionnaire pour les amoureux du papier), apprendre le vocabulaire de base, puis apprendre progressivement en vous imprégnant de la culture locale.
Eh bien, pour travailler avec des techs en tant que chef de projet, c’est la même chose. Pour comprendre ce qu’ils font et pouvoir échanger avec eux, il faut s’y intéresser. Il faut mettre en place des bonnes pratiques qui vous permettront de mieux communiquer.
C’est le premier chantier que j’aie mené en arrivant chez Padok : acquérir les bases. J’ai commencé par lire des articles pour comprendre ce qu’on fait concrètement, quelles sont les actions régulières que les techs réalisent, sur quoi on travaille... J’ai participé à des formations internes, j’ai un glossaire que je mets à jour régulièrement à mesure que j’apprends et des notes que j’enrichis.
Et surtout : je pose des questions. Il n’y pas meilleur moyen pour comprendre un sujet que d’aller demander directement à un expert de vous le vulgariser. Petit à petit, vous allez de plus en plus comprendre les discussions et pouvoir challenger ce qui est fait. Et c’est là que vous commencerez à prendre du plaisir dans votre rôle de chef de projet tech.
S’il faut comprendre et savoir challenger ce qui est fait, personne n’attend d’un chef de projet tech qu’il devienne expert technique. Et justement, à mon sens, sa valeur ajoutée repose sur le fait qu’il ne se perdra pas dans des détails. Il demandera aux techs de vulgariser, et de prendre du recul sur ce qu’ils produisent.
Partant du principe qu’un tech et un chef de projet ne parlent pas forcément la même langue, et que l’avancement d’un projet peut être subjectif, il y a deux bonnes pratiques pour obtenir de la visibilité :
Cette option est intéressante, car elle permet de comprendre la tendance d’avancement et d’être informé des difficultés au plus vite afin de les débloquer rapidement.
Le fait d’échanger régulièrement crée également de la confiance. Vous serez plus à même de comprendre comment se sent l’équipe vis-à-vis du projet.
Le risque cependant est de vous laisser embarquer dans les problèmes quotidiens. Et cette option ne vous donne pas de visibilité à long terme. C’est pourquoi elle doit être complétée par la deuxième option.
L’objectif est ici d’avoir un même référentiel sur lequel on peut s’appuyer pour discuter de l’avancement du projet. Il est à construire avec toutes les parties prenantes afin de s’aligner sur les éléments importants et pertinents. Et surtout, il demande de s’accorder sur un fonctionnement qui fasse coïncider les enjeux de tous.
S’il demande trop de temps, il sera difficilement adopté par une équipe tech qui a déjà une énorme charge de travail. S’il est trop léger, il n'aura pas de valeur ajoutée pour le chef de projet. Et s’il fait doublon avec des outils existants, il n’apportera peut-être pas de valeur et dans ce cas, il vaut peut-être mieux adapter l’existant.
Chez Padok, par exemple, afin d’avoir un delivery rapide et de donner le plus de visibilité possible à un client sur un projet, on met en place des outils à différents niveaux de suivi et on essaye d’estimer le plus possible nos tâches.
En arrivant sur un projet, on va définir ses succès (ses objectifs) et la stratégie technique à mettre en place pour les atteindre. On va découper cette stratégie en macro, des “sous-succès” à accomplir. Enfin, on va lister toutes les actions concrètes à effectuer pour réaliser ces macros.
La réussite d’un projet est difficile, voire impossible à mesurer en regardant le projet dans son ensemble. En la découpant en briques, on obtient des tâches de plus petite taille qu’on peut estimer, et donc suivre plus régulièrement.
Dans certaines entreprises, le tech est vu comme un exécutant plutôt qu’un spécialiste. On va lui assigner un projet en lui donnant un minimum d’informations lié à son domaine sans se préoccuper de lui transmettre les enjeux business.
Au contraire, s’il y a une chose à faire au début d’un projet, c’est donner tous les éléments au tech pour qu’il puisse vous aider au mieux. Plus il connaîtra le projet, plus il pourra faire des propositions qui apporteront de la valeur au client.
S'il n'est pas au courant des enjeux business, il n'accordera peut-être pas le bon niveau d'importance à certaines de ses tâches. Aussi, le tech a également des contraintes de son côté et le fait de les partager permettra d’articuler au mieux le projet.
Quand bien même vous êtes dans une entreprise bienveillante, il peut arriver qu’il soit difficile de trouver la bonne posture de chef de projet tech. Face à une équipe expérimentée vous n’oserez pas trop vous imposer. Au contraire, face à une équipe peu investie dans le projet, vous pourrez avoir du mal à les secouer par peur de ne pas avoir la légitimité de le faire.
Voici quelques tips sur la manière de réagir en fonction des situations :
Dans ce cas-là, le mot d’ordre est : adaptation. Il n’y a rien de pire que d’arriver frontalement avec sa méthodologie en poche et l’imposer. Pour trouver sa place, le mieux est d’y aller progressivement, en commençant par voir comment l’équipe travaille :
C’est normalement le cas le plus simple. Vous pourrez ici proposer une méthodologie de travail, pourquoi pas en agile, en tenant compte de la culture de travail de chacun : est-ce qu’ils ont l’habitude de travailler en autonomie ? Est-ce qu’il faut les accompagner au jour le jour ?
Les bonnes pratiques sont nombreuses. Votre enjeu principal sera de créer une relation de confiance dans l’équipe, et que celle-ci comprenne votre rôle et se tourne vers vous en cas de difficultés.
Si vous mettez en place ces quelques astuces, vous devriez pouvoir pallier assez rapidement les enjeux et rentrer dans la partie vraiment intéressante du métier à mon sens : apprendre et gérer des problèmes.
Me voilà (enfin) arrivée au bout de mon retour d’expérience de chef de projet tech ! Je crois que me diriger dans la tech après une école de commerce a été ma meilleure décision. J’appréhende doucement le monde de la tech et si je n’ai pas été saisi d’une violente envie d’apprendre à coder, ça me permet d’apercevoir l’envers du décor de tout ce qu’on utilise aujourd’hui.
Voici un petit résumé des tips à retenir pour réussir à être chef de projet tech :
Etape 1 : Comprendre l’environnement et apprendre les bases de la tech
Comment ?
Etape 2 : Créer une bonne relation avec l’équipe tech
Comment ?
Etape 3 : Cadrer votre projet pour obtenir de la visibilité
Comment ?
N’hésitez pas à me faire part de vos retours sur cette série d’articles et à partager vos tips pour gérer des projets tech !