S’unir pour réussir
En SSII, la réalisation d’un projet dépend de plusieurs facteurs pas toujours maîtrisés par le Chef de Projet. Mais parmi tous ces facteurs, s’il y en a un seul à maîtriser, c’est l’équipe.
En introduction
Tout d’abord, cet article ne fait que traduire ma vision de ce qu’est une équipe, en particulier dans le cadre de la réalisation d’un projet informatique. L’expérience du Chef de Projets doit permettre de s’adapter à chaque équipe et donc de remettre en cause cet article.
Mon constat
Après plusieurs projets, j’ai été, par la force des choses, contraint de reconnaître que la réussite d’un projet ne peux pas s’appuyer que sur une méthodologie sans faille, une conception impeccable ou la seule volonté d’un Chef de Projets. Comment trouver les leviers qui permettent d’agir sur les facteurs de réussite d’un projet ? Après avoir essayé de répondre à cette question, je me suis retrouvé devant une sorte d’évidence qui malheureusement nous échappe souvent. C’est l’équipe toute entière qui fait le projet et qui pèse en grande partie sur l’issue de ce projet.
Comment tirer le meilleur de son équipe ?
1. Arrêter de classer les intervenants. Un Chef de Projets n’est pas “mieux” qu’un ingé, qu’un expert ou autre. C’est un rouage de la machine, et chaque membre de l’équipe est un rouage de la machine.
“Chef de projet est un métier, Ingénieur en développement est un métier, l’un sans l’autre personne se fait rien”
2. Respecter et se faire respecter Les règles, comme chaque membre de l’équipe doit être respectés. Quand ce n’est pas le cas c’est le rôle de chacun que de faire la remarque. Le respect au sein d’une équipe permet de limiter les conflits.
3. Instaurer des règles Pour fonctionner, il faut instaurer des règles. De cette manière, pas de surprise. Ces règles doivent être partagées avec les différents intervenants, mais l’une des premières règles, c’est de respecter ses engagements.
4. A chacun ses responsabilités et ses engagements Chaque intervenant doit avoir des responsabilités. Peu importe son poste ou rôle dans l’équipe et peu importe son ancienneté. La responsabilisation des membres d’une équipe permet d’identifier rapidement les personnes responsables, des autres. Associé aux responsabilités, les engagements permettent de sceller des contrats inter-équipe. Avec des responsabilités et des engagements partagés cela permet de matérialiser des “pactes” précis, sur des périodes courtes entre chaque membre de l’équipe.
“Je m’engage à te donner des spécification lundi — et vu que je suis responsable, tu peux me faire confiance”
Attention, il est impératif de ne pas confier des responsabilités qui dépassent les pouvoirs d’action d’un membre, et inversement de laisser un membre s’octroyer, de manière consciente ou pas, des responsabilités qu’il n’aura pas les capacités d’assumer.
5. Identifier les points forts de votre équipe Nous ne choisissons pas toujours (voir jamais) notre équipe. C’est normal et le défis c’est d’identifier rapidement les points forts connus (et inconnus) de l’équipe et de les mettre à profit. Attention par contre aux évidences trompeuses. Quelqu’un de bon en test, ne doit pas être le seul à tester sous peine de déresponsabiliser les développeurs.
6. Trouver des challenges Chaque membre doit être challengé. Rester dans son espace de confort à l’inconvénient d’encourager la routine, qui entraîne des erreurs d’inattention.
“Je fais ça à chaque fois et ça marche, pas de raison que ça change”
Se mettre devant quelques difficultés mesurées permet de progresser et de lutter contre la routine. Une nouvelle techno, une nouvelle méthodo un nouvel outil…
7. Partager les réussites et les échecs Régulièrement, il faut échanger sur les réussites et les échecs du projet. Il ne faut pas masquer (sauf cas exceptionnel) des problématiques. Vu que chacun est responsabilisé il est normal de partager les bonnes choses et les moins bonnes. Cela permet d’ajuster et de progresser.
8. Souder Une fois tous les membres identifiés, il faut souder l’équipe. La solution qui me semble la plus simple, est de donner un ou plusieurs objectifs communs et partagés. Pour un projet, on peux citer la satisfaction du client, le respect des délais, des charges, du budget etc… Mais attention à adapter ces objectifs à votre projet !
En conclusion
Oui, bien sûr. Je ne parle pas de tout le reste. Il y a beaucoup de choses à dire sur ces aspects presque “psychologiques”. Cet article pourra se compléter et s’affiner avec le temps car quand on parle de relation humaine, rien n’est acquit ou figé. Seule l’expérience vous permettra de constituer une équipe de “bouffeurs de codes”, “d’avaleurs de bugs”, une équipe bardée de réussites et fière de son travail. A vous donc de trouver vos méthodes…