Gérer des projets… sans chef·fe de projet

Pas de chef·fe de projet, vraiment ?

Lors de nos premières rencontres avec un prospect, nous prononçons souvent cette phrase :

« Notre particularité, c'est qu'on n'a pas de chef de projet. Ce sont les développeurs qui seront à vos côtés, tout au long de la phase de build ».

C'est une phase qui peut faire peur, à plusieurs titres :

• Pour les clients, d'abord, qui peuvent craindre de ne pas avoir d'interlocuteur privilégié ;
• Pour nos futures recrues techniques, qui peuvent ne pas avoir de grande aisance en face d'un client, surtout quand il s'agit de vulgariser le métier ;
• Pour nos confrères, qui n'ont pas l'habitude de ce type d'organisation.

Fort heureusement, ces craintes sont très vite levées car nous nous appuyons sur 2 grandes forces : notre équipe et nos méthodes.

Une équipe de concepteurs, avant d'être des développeurs

Chez Elao, nous ne recrutons pas des exécutants, machines à dépiler des tickets. Notre valeur est dans la conception d'une solution maintenable et évolutive, ce qui ne peut se faire que quand il y a un fort niveau d'implication de la part de l'ensemble de l'équipe.

Au risque d'énoncer une évidence : plus une équipe intervient tôt dans un projet, plus elle se sent impliquée.

Nous n'avons pas de chef de projet car nous voulons à tout prix éviter l'effet « passe-plat » de l'interlocuteur unique pour le client et partager la responsabilité du projet sur toutes ses parties-prenantes. Par ailleurs, on s'affranchit ainsi de la crainte de voir partir en congés la personne qui a toute la connaissance du projet et la relation privilégiée avec le commanditaire.

Notre méthode

Un projet de constrution d'application dure, chez nous, entre 3 et 6 mois. Pendant cette phase, qu'on appelle « la phase de build », une équipe technique (deux à trois développeurs et une intégratrice) est dédiée au projet. Dédiée, ça veut dire qu'elle passe 80 % de son temps staffée sur ce projet (les 20 % restant, c'est pour traiter la maintenance ou les évolutions sur les autres projets, faire de la veille, avancer sur des projets de R&D internes…).

Cette phase de build est toujours précédée d'une phase d'avant-vente, évidemment, et d'une phase de préparation. La plupart du temps, les développeurs arrivent très tôt dans le projet, au moment des estimations de l'avant-vente, afin que nous puissions rapidement cerner les besoins et les technos à mettre en face.

Tout au long du projet, et dès les premiers échanges, les développeurs sont en direct avec le client, afin qu'ils aient un maximum d'informations pour faire les meilleurs choix techniques et des propositions fonctionnelles pertinentes.

Les équipes ayant toutes les bonnes clés sont plus pertinentes sur la proposition fonctionnelle et sur la priorisation des tâches. Elles ont ainsi une vision directe sur la création de valeur pour le projet pour un budget donné.

Alors oui, parfois il serait plus « productif » / « rentable » de n'engager les développeurs que sur de la production, mais c'est sans compter sur l'appétence de l'équipe à aller comprendre, creuser, entrer dans le métier du client afin de comprendre comment satisfaire les utilisateurs. Au final, l'expérience nous a montré que le gain d'efficacité est réellement palpable. Et ça, c'est bon pour le budget du client, qui s'offrira plus de fonctionnel et moins de points de synchro.

Et parmi les autres gains sensibles : tout le monde prend du plaisir, car chacun peut avoir un impact réel sur le projet, au quotidien. Et à l'arrivée d'un nouveau client, cela permet aux développeurs de naturellement se positionner sur les projets qui leur font envie.

Pas de chef de projet, mais des « facilitateurs »

Chez Elao, les seuls postes qui pourraient se rapprocher d'un rôle de gestion de projet sont ceux de facilitateurs, dont je fais partie avec Xavier.

Notre mission, c'est de mettre de l'huile dans les rouages quand c'est nécessaire. Ce dernier point, « quand c'est nécessaire » est très important, car la plupart du temps, ça roule tout seul et c'est tant mieux. Quand les développeurs ont une question, ils la posent directement au client et vice-versa.

Notre intervention est importante en phase de préparation, c'est-à-dire celle qui précède la phase de build, notamment parce que les développeurs ne sont pas encore dédiés au projet. Ils sont sollicités régulièrement lors de cette phase mais on ne leur demande pas une plongée à temps plein, qui serait contre-productive à ce stade.

Nous nous assurons que tout soit prêt pour le développement : que le périmètre du projet soit suffisamment mûr et clair pour aboutir à des spécifications ou des maquettes graphiques. Par ailleurs, notons bien que ces livrables ne sont jamais « découverts » par les développeurs au dernier moment. Ils sont présents pour les construire, les valider, se projeter dessus pour les estimer.

Le facilitateur prend tout son sens quand le projet atteint sa phase de « run », c'est-à-dire quand le périmètre initial a été mis en production et qu'il n'y a plus assez de fonctionnalités pour alimenter une équipe technique à temps plein. Nous sommes là pour garantir que tous les projets en run aient la même attention et que tous les besoins clients soient traités. En outre, c'est aussi un excellent moyen de libérer les développeurs de la charge mentale du projet, et leur permettre d'en accueillir un autre sereinement.

C'est là que nous pilotons plus finement les plannings, avec projection à moyen / long terme, là où l'équipe de production a une vision naturellement plus court-termiste. On adore ce moment où l'on fait le tetris avec les plannings entre les nouveaux projets (build) et nos clients fidèles (run). Je ne suis pas sûre que les développeurs partagent cet enthousiasme :D

Les risques

Plus de difficultés à recruter ?

Notre organisation interne nous pousse à chercher des développeurs qui ont envie de traiter en direct avec le client, d'assister à des ateliers de brainstorming fonctionnel, de participer à des réunions de chiffrage, de se projeter sur des éléments qui sont parfois encore un peu nébuleux.

Ce n'est pas toujours facile de trouver ce genre de perle, d'autant plus dans un marché tendu comme celui du recrutement dév :) Par chance, la plupart de notre équipe technique est là depuis longtemps (<3) et pousse naturellement les nouvelles recrues à prendre confiance et à monter en compétences, petit à petit, sur ces sujets.

Quand la responsabilité est partagée, personne n'est responsable ?

Non, on dirait plutôt : quand la responsabilité est partagée, tout le monde est responsable. Par contre, il est nécessaire, pour mettre tout ça en place, d'avoir déjà une forte culture de partage dans l'équipe. En effet, les clients n'ont pas toujours la rigueur d'historiser leurs besoins en créant un ticket, par exemple (même si on essaie de les inciter :) ). Il est nécessaire que chaque membre de l'équipe sache prendre le relai sans attendre que quelqu'un d'autre prenne le point.

Cela dit, un projet a toujours son « lead technique », c'est-à-dire le développeur qui sera le plus souvent en frontal des différents sujets. C'est lui qui assure la cohérence technique du projet et a la plus grande vision fonctionnelle de ce dernier. Dans les faits, le lead est souvent pris de manière naturelle par un membre de l'équipe et dans la grande majorité, quasiment toute l'équipe est en capacité de la porter en fonction du projet / client.

Pour que cette organisation fonctionne, il est crucial que chaque membre de l'équipe se sente légitime avec le client, responsable de l'information qu'il détient et qu'il ait le réflexe de la partager ou de l'historiser systématiquement. C'est toute la clé pour que cette organisation fonctionne.

Le maître-mot est donc : partager, partager, partager, pour que tout le monde ait le même niveau d'information à tout moment (y compris le client).

TL;DR

Il n'y a pas de recette magique. Notre culture de proximité du client est forte et complètement ancrée dans notre ADN et c'est ainsi que nous construisons notre équipe.

Si l'on devait être objectif, voici les pour et contre d'une organisation sans chef·fe de projet :

Avantages

• Toute l'équipe est impliquée de manière forte ;
• Aucune perte d'information ;
• Pas de « passe-plat » avec une seule personne ayant la connaissance du projet ;
• Peu de « points de synchro », tout le monde a toujours le même niveau d'info ;
• Faire bénéficier au client de la diversité de l'équipe ;
• Chaque membre de l'équipe peut avoir un impact réel sur le projet ;
• Les facilitateurs restent proches du projet en cas de grain de sable dans les rouages.

Inconvénients

• Le client peut avoir besoin de se reposer sur un seul interlocuteur (auquel cas les facilitateurs rentrent plus fortement dans le projet pour accompagner le client) ;
• Des difficultés à recruter des développeurs réellement « concepteurs » et avec une appétence pour le fonctionnel et l'envie de comprendre le métier du client ;
• Il peut vite y avoir foule (5-6 personnes) lors des ateliers.

Vous en voyez d'autres ?