Quand la théorie ne rime pas avec pratique...

Le métier de chef de projet est donc comme toute autre expérience, il y a la théorie VS la pratique

En théorie, dans les grandes phases d’un projet nous retrouvons :

• le cadrage,

• la conception,

• le développement,

• la recette,

• la mise en production (peu importe la méthodologie)

En pratique, c’est une vraie aventure où nous devons à la fois avoir l’âme d’un Mac Gyver, d’un 4×4 tout terrain mais aussi d’un homme-orchestre.

À tous moments, nous devons trouver des solutions à des problèmes inattendus, auxquels nous n’aurions jamais pensé être confrontés (et pas toujours liés directement au projet).

1. Le cadrage, une phase de négociation à tous les niveaux

Avant de débuter le projet , il faut un planning, un budget et surtout un devis signé par le client.

En théorie, nous ne nous soucions pas vraiment du staffing.
En pratique, nous cherchons d’abord la disponibilité des ingénieurs et des chefs de projets les plus pertinents pour notre sujet. Nous négocions avec les managers, CTO, les responsables d’équipe…bref, nous testons plusieurs stratagèmes. On essaye de séduire les ingénieurs/chefs de projet en leur parlant du projet en avance de phase. C’est à ce moment là que nous enfilons notre casquette de commercial, et que nous dégainons notre arsenal de négociateur. Une fois que nous avons notre équipe, nous préparons un kick-off pour présenter le métier du client, les grandes fonctionnalités et le planning à l’équipe. Il faut motiver les troupes, les fédérer, mais surtout leur donner envie !

2. La conception, une phase de découverte et de réflexion

Une fois le kick off passé, c’est là que l’aventure commence vraiment …

Il y a d’abord la conception, quand nous découvrons le métier de notre client, ces enjeux, les personnalités des uns et des autres. Il faut avoir une touche d’empathie, de la psychologie, et de la patience (beaucoup beaucoup beaucoup de patience) pour décrypter les besoins des clients, les non-dits et les subtilités de chacun pour survivre à cette phase.

En théorie, nous détaillons les fonctionnalités : pas de grandes surprises.
En pratique, nous retrouvons occasionnellement quelques “cadavres”. Mais dans tous les cas c’est quand même le moment que nous préférons. Nous réfléchissons à la meilleure solution, nous décortiquons le métier du client, nous apprenons, nous découvrons… Mais c’est là que tout se décide et se dessine : l’architecture, les maquettes, les solutions techniques, les règles de gestion, les spécifications…Toute la documentation.

3. Le développement, la production du livrable

Ensuite vient la phase de développement : nous découpons les fonctionnalités en tâches, en sous tâches, en sous sous tâches….
En théorie, on utilise un dashboard (agile ou pas).
En pratique aussi, mais il va falloir batailler pour maintenir les statuts des tickets jiras (Gestionnaire de demande/tâche) à jour.
En théorie, nous devons le faire tous les jours.
En pratique, nous attendons que ça soit bien le bazar pour motiver tout le monde et perdre une heure ou deux pour tout remettre en ordre.
En théorie, nous mettons tout sur l’environnement de développement, puis en recette.
En pratique, nous perdons quelques commits (modifications) que nous retrouvons sur un autre environnement.

Il y a également les longues journées d’avant démo avec la commande de japonais pour tenir le choc …sinon c’est pas drôle…

Le début du “harcèlement” des ingés :

• “Tu as push sur quelle branche ?”

• “Ta MR est validée ?”

• “Tu as testé sur quel environnement ?”

• “Ton jira est à jour ?”

• “Tu en as encore pour combien de temps ?”

• “Tu peux déployer ?”

4. La recette, une étape de validation et de vérification

Il y a aussi les choses que nous constatons en phase de recette qui impliquent : une refactorisation du code sur une fonctionnalité essentielle la veille d’une livraison, une montée de version d’une librairie qui nous impose de retester toute l’application, etc.

En théorie le client doit créer des jiras.
En pratique il envoie quelques fois des mails ou appels pour nous signaler les problèmes qu’il a pu rencontrer. Et charge au chef de projet de rassembler les informations pertinentes et reformuler dans un jira pour les ingénieurs.

En théorie les personnes qui réalisent la recette ont participé à la conception du projet ou ont lu les spécifications.
En pratique certains testeurs ne connaissent pas le scope retenu et nous sollicite pour leur expliquer les fonctionnalités, ou nous remontent des cas d’erreurs qui n’en sont pas.

On peut également se retrouver dans des cas où nous n’arrivons pas à reproduire les éléments relevés par les testeurs à cause de problème :

• de droits utilisateurs
• d’environnements non totalement ISO production (jeux de données, architecture, configuration des machines, taille du disque ou de la mémoire qui diffèrent…)
• des problèmes d’OS sur les mobiles
• de taille d’écran qui varie d’un appareil à un autre

Là, on stresse un peu…On cherche, on s’interroge, on teste, on sollicite les ingénieurs… Heureusement tout finit souvent par s’arranger rapidement.

5. La mise en production : installation et déploiement de la solution

Puis vient le moment de la mise en production : on a le palpitant quelque peu perturbé…
C’est un mélange de fierté et de délivrance. Le reflet des mois passés à travailler ensemble à construire quelque chose qui devient réalité.

C’est le moment de réunir l’équipe pour faire un REX (retour d’expérience) :
Pour apprendre de nos erreurs, voir ce qu’on peut améliorer, ce qu’on doit garder et ce qui a bien fonctionné. Et c’est aussi l’occasion d’organiser un pot !

On parle trop souvent des choses qui ne vont pas mais il y a aussi beaucoup de bons moments :

• La cohésion d’équipe : quand tout le monde reste en fin de journée pour une livraison,
• Les transmissions de connaissance où les plus experts expliquent aux plus novices,
• Les grands enfants qui jouent avec un nerf et qui mettent les miens à rudes épreuves,
• Les passionnés qui proposent des améliorations auxquelles personne n’avait pensé,
• Les amitiés et les chamailleries qui mettent de l’ambiance,
• Les petits déjeuners d’équipe,
• Les sorties team-building,
• Les apéros improvisés qui finissent à pas d’heure….

Voilà, je crois que j’ai résumé une partie de nos aventures. Il faut surtout garder à l’esprit qu’il n’y a pas mieux que la pratique pour comprendre la théorie. Il n’y a pas de recette idéale, la gestion de projet n’est pas une science exacte.

Au fil du temps, on se fait notre propre théorie car elle évolue au fur et à mesure des expériences et cela devient donc plus facile de la mettre en pratique.

Il faut essentiellement s’avoir s’adapter, innover car les technologies, les besoins, les clients et les équipes changent constamment. Chaque projet est différent mais quoi qu’il en soit, on apprend toujours !

Note pour plus tard

Nous avons oublié de parler du mercato des équipes, les “Je ne peux pas, j’ai poneys”, la règle de “pas de mise en prod le vendredi”, les décisions qui ne sont jamais tranchées, la TMA (Tierce Maintenance Applicative), de la fameuse danse de la joie quand la deadline est décalée…Mais ça sera pour un prochain épisode…;)