1) Passer de technicien à chef de projet
Et oui, que vous soyez développeur ou non, il est possible comme Thibault qu’un jour le poste de chef de projet vous soit proposé. Vous pouvez refuser mais si ça vous tente, pourquoi ne pas s’y préparer ? À minima comprendre la gestion d’un projet, le travail du chef ou chargé de projet est tout simplement un atout aussi important que simple pour mieux communiquer.
À la suite d’un arrêt maladie, Thibault a été pressenti pour remplacer le Chef de projet en place, de grands pouvoir mais aussi de grandes responsabilités… (pour les fans de spiderman, un petit commentaire clin d’œil en bas d’article me fera plaisir) 😉 .
Sa société lui a fait confiance pour ce poste à responsabilités, nul doutes que les appétences et compétences de Thibault ont favorisé ce choix. Avoir une connaissance du métier et de la technique est un point fort lorsqu’il s’agit de coordonner des acteurs techniques, de différents niveaux et différents horizons. Parler « le même langage » est un plus, mais ne fait pas tout… comment se former à la gestion de projet quand on est en poste ?
2) Se former à la gestion de projet
Sacré défi à relever non ? C’est donc la tête dans les bouquins que Thibault se forme pour devenir chef de projet à plein temps, mais également en suivant la formation PRINCE2. Elle fait partie des formations les plus connues (il existe également PMP).
Certification en poche, il est prêt à aborder les projets en utilisant les méthodes adaptées en fonction de la taille des projets.
Voilà donc une deuxième notion importante, qui n’est d’ailleurs pas spécifique au monde de la gestion de projet : formez-vous !
Une des causes d’échec de projet et de nommer des personnes à des postes à responsabilité, en pensant que leur compétences actuelles sont transposables directement dans le nouveau poste… avec un salaire plus haut et de la bonne volonté… »ça va le faire…. » : grave erreur…
3) Les méthodes de gestion de projet
Sans plus de suspens… 🙂 :
La méthode du cycle en V a beaucoup été décriée dans le monde du développement logiciel, elle n’est pourtant pas à mettre à la poubelle ! Chaque méthode a ses avantages et ses inconvénients, mais surtout sont efficaces si et seulement si elles sont employées pour les bonnes raisons, avec les bonnes personnes et dans le bon contexte.
En génie logiciel, SCRUM et KANBAN se démarquent par leur approche « Agile » en ajoutant plus de flexibilité aux méthodes de gestion de projet empiriques, qui peuvent apporter des limitations dans un monde où la technologie évolue aussi vite que le besoin du client…
Bien sûr cette flexibilité a des contreparties à prendre en compte sous peine de voir avancer le projet droit dans le mur (demande de nouvelles fonctionnalités sans en abandonner d’autres, avec toujours le même budget initial… tensions à prévoir…).
Des cycles courts (de une à deux semaines), une validation client en amont par les utilisateurs, et par fonctionnalité livrées… voilà des bonnes pratiques qui permettent d’ajuster les corrections nécessaires dès le départ, en garantissant de coller au besoin client. Ainsi le logiciel se construit au fur et à mesure, dans un climat de sérénité et de confiance, quand le projet est bien piloté 😉
En le voit bien, l’agilité est d’abord une philosophie avant d’être une méthode… à prendre en compte lors de la création des équipes donc, et mettre en place l’accompagnement lorsque c’est nécessaire (y compris du client) 🙂
Quand choisir SCRUM ou KABAN ?
Ce sont deux méthodes agiles qui vont permettre de responsabiliser les acteurs.
SCRUM va donner un cadre plus important que KANBAN, de façon plus normée. Un peu plus de réunions, plus de reporting à faire. C’est une méthode idéale pour ceux qui ne sont pas familiers avec l’agilité.
KANBAN a l’avantage de faciliter la gestion de projet sur lesquels on a des difficultés à caler des échéances ou a estimer le travail qui reste à faire. À la différence de SCRUM où les cycles courts ont une taille définie, KANBAN va séquencer les tâches les unes à la suite des autres pour « tirer » le maximum de productivité (versus les fonctionnalités).
Point importants à prendre en compte lors du choix :
- La maturité de l’équipe avec l’agilité
- Quelle est la taille du projet (préférer KANBAN pour les petits, SCRUM pour les plus grands)
4) Comment organiser des grands projets
La nature est ainsi faite, quand quelque chose fonctionne, on souhaite l’appliquer partout. Planter un clou avec un marteau est chose facile, voir plaisante, que faire quand après avoir enfoncé 10 clous avec un marteau on se retrouve devant une vis ?
Il en est de même avec les méthodes projet, ce qui fonctionne bien avec 5 personnes, doit être abordé différemment avec 100 personnes…
Thibault préconise donc de compartimenter en équipe des 10 personnes (environ) réparties en fonctionnalités avec les méthodes qu’elles souhaitent mais en disposant d’une personne référente au dessus qui prend un peu de hauteur et compile toutes les données pour avoir un avancement réel du projet.
5) Comment travailler avec un client qui n’est pas agile ?
C’est le cailloux dans la chaussure… il va pourtant falloir marcher main dans la main…
Là encore Thibault nous apporte un conseil plein de bon sens : il faut se dire les choses dès le début, se mettre d’accord et formaliser le fonctionnement au départ pour éviter les surprises à l’arrivée (ou en chemin)…
Le contrat est important, il peut être important de définir comment vont se dérouler les négociations nécessaires pour la définition du périmètre (en cours de route).
La réunion de lancement aura son importance, les comptes rendu de réunion également.
Une des clefs (en or) est de pouvoir s’assurer que chaque acteur à bien compris les actions et enjeux au départ du projet, ainsi qu’a chaque jalon projet.
La définition d’un mode opératoire sur l’organisation, les rôles et responsabilités de chacun en termes de livrable (client et fournisseur) au départ du projet est également une bonne pratique. En somme :un manuel de bonne conduite distribué (et validé par) chacun 🙂
6) Comment devenir chef de projet « sur le tas »
On l’a vu un peu plus haut, s’investir personnellement via des livres mais également suivre des formations pour assurer « les basiques ».
À cela s’ajoute une force qui peut être également un handicap : son passé…
Si vous êtes technique et que vous devez piloter une équipe technique, il est important de résister à son envie de « faire à la place de » et d’endosser le rôle de facilitateur plutôt que de faiseur… pas facile de retrouver ses marques, mais quel bonheur de voir une équipe qui avance en harmonie !
La relation à l’équipe quand on est soi-même technique pourrait faire l’objet d’un article complet, c’est d’ailleurs ce que j’ai fait sur le premier blog de Thibault « réinventer son travail » avec l’article Un manager doit-il être technique pour piloter une équipe opérationnelle ? Vous pouvez aller y faire un tour 😉
7) Comment TOYOTA a su se réinventer
Envie de savoir d’où viennent ces fameux Post-it ? Comment Toyota a amélioré la gestion de ses stocks, de ses coûts associés et mis en place une méthode qui résonne encore aujourd’hui dans le monde d’IT ?
Je vous invite à lire l’article invité de Thibault qui parle justement de cela : dans « La méthode Kanban, Scrum, que des Posts-it ?«
Conclusion
En grand merci a Thibault pour cette interview de qualité où les notions abordées vous permettront d’aborder sereinement le monde du développement logiciel avec des clefs en main concernant la gestion de projet et qui sait, peut être un jour devenir chef de projet ? 😉
Vous pouvez retrouver Thibault dans l’espace amitié avec les liens vers ses deux blogs :
? Inscrivez-vous à la newsletter ainsi qu’a ? la chaîne Youtube pour ne rien rater de cette belle aventure qu’est “coder pour changer de vie“.
A bientôt,
Nicolas.
De grands pouvoir mais aussi de grandes responsabilités… merci Tonton de spiderman ! 😉
Sur le point 2 pour se former, je conseillerai 2 livres qui ont été des vrais révélations pour moi :
– Le chef de projet efficace de A. Fernandez
– Gérez vos projets de T. Pairis
Je suis intéressé par tout autre lecture soi sur le domaine de la gestion de projets, soi sur l’IA.
Peut-être une section Bibliographie a créer dans l’article ?
Bonjour Evren,
Merci pour les conseils de lecture. Concernant la gestion de projet, j’ajouterai :
En Français:
– La boîte à outils du chef de projet, de Jérôme Maes & François Debois
En Anglais (mon langage de préférence pour les ouvrages de non fiction):
– Scrum : The art of doing twice the work in half the time, de Jeff Sutherland
– Project Management for the unofficial project manager, de Kory Kogon, Suzette Blakemore, James Wood
– The fast forward MBA in project management, de Eric Verzuh
– Leading Change, de John Kotter (s’intéresse plus particulièrement à la gestion du changement, qui fait partie intégrante de la gestion de projet)
Merci Evren ! Pour l’IA j’avais rédigé une pause café sur le sujet pour se détendre 🙂 https://coder-pour-changer-de-vie.com/intelligence-artificielle-3-conseils/
Des sujets très intéressants en effet, à traiter avec autant de sérieux que l’engouement qu’ils génèrent, je prends note !
Belle journée,
Nicolas