Une équipe produit qui ne livrait plus

Mission conduite avec l'équipe de Cœur du Web, l'agence que j'ai fondée. Le client a accepté d'être nommé.

Ce que la direction voyait

Trois symptômes, toujours les mêmes. Les développeurs avançaient sur des sujets qu'aucun product owner n'avait vraiment arbitrés. La direction recevait des comptes rendus qui n'éclairaient aucune décision. Et les utilisateurs internes voyaient leurs demandes s'empiler sans réponse. Aucun des trois ne relève de la compétence des équipes.

Vu du bureau du dirigeant, le tableau est déroutant : tout le monde travaille, personne ne chôme, les réunions ont lieu. Ce qui manque n'est pas visible depuis là. Ce sont les décisions qui ne se prennent pas, et qui repartent d'un point d'avancement au suivant sans que personne ne s'en aperçoive. Un projet qui glisse de cette façon ne donne pas l'alerte, il s'enlise silencieusement. J'ai décrit ailleurs les signaux qui permettent de le repérer avant qu'il ne soit trop tard.

La phrase que le dirigeant a fini par prononcer résume la situation mieux que n'importe quel audit : il ne savait plus quoi exiger. Pas quoi demander, quoi exiger. La nuance compte : on peut demander n'importe quoi à une équipe, on ne peut exiger que ce dont on a défini la forme à l'avance.

Le diagnostic, qui n'était pas technique

La pile technique n'a pas été touchée. Le JavaScript et l'hébergement cloud en place sont restés exactement ce qu'ils étaient pendant toute la mission. Ce qui a été refondu, ce sont les rituels, l'organisation et le pilotage produit.

C'est la partie contre-intuitive de ce genre de mission, et celle qui rassure le moins un dirigeant : il attend souvent qu'on lui désigne un coupable technique, une dette, un choix d'architecture malheureux. Il n'y en avait pas. Une équipe qui n'avance plus a rarement un problème de compétence. Elle a un problème de cadre, et le cadre ne se répare pas en réécrivant du code.

Ce diagnostic a une conséquence directe sur le devis : il n'y avait pas de chantier de développement à vendre. La mission portait sur l'organisation, ce qui la rendait plus courte et moins chère qu'une refonte, et beaucoup plus inconfortable à annoncer.

Reposer un cadre avant de toucher au produit

Trois chantiers menés en parallèle, aucun spectaculaire.

• Un pilotage produit lisible. Le backlog a été repriorisé sur la valeur métier plutôt que sur le volume des demandes internes. Un tableau de bord unique, lisible par la direction comme par les développeurs, a remplacé les rapports parallèles.
• Une équipe remise en mouvement. Sans réorganisation, sans départ. Chacun a su ce qu'il livrait dans la semaine. Les blocages devaient remonter sous vingt-quatre heures, pas à la revue suivante. Les démonstrations sont devenues publiques.
• Des points courts. Les réunions fleuves ont laissé place à des points hebdomadaires brefs, dont sortait une décision écrite.

Rien là-dedans ne s'invente : ce sont les mécaniques ordinaires du pilotage de projet, appliquées vraiment plutôt que affichées. La difficulté n'est pas de les connaître, elle est de les tenir les semaines où personne n'en a envie.

Recruter celui qui allait me remplacer

Le rôle n'était pas de rester. Un product owner interne a été recruté pendant la mission, puis accompagné plusieurs semaines dans sa prise de poste : transfert du contexte, des outils et des relations avec les utilisateurs internes.

C'est le point sur lequel je serais le plus intransigeant si c'était à refaire. Une direction produit de transition qui ne prépare pas sa sortie devient une dépendance de plus, et le problème initial se reconstitue à l'identique le jour où le prestataire s'en va, en pire, parce que l'équipe a désappris à décider.

Le recrutement a donc commencé avant que la mécanique soit réglée, pas après. Le futur product owner a vu le désordre, pas seulement le résultat rangé. Il a hérité d'un contexte qu'il comprenait, y compris ce qui avait coincé et pourquoi.

À quoi se reconnaît une sortie de mission propre

Trois marqueurs, vérifiables : le relais est internalisé à cent pour cent, il n'existe aucune prestation récurrente résiduelle, et l'équipe continue sans que personne n'ait à rappeler l'intervenant.

L'équipe produit a recommencé à livrer, non pas en doublant la cadence mais en cessant de tourner en rond. Le product owner interne est aux commandes. Il n'est resté ni contrat de maintenance déguisé, ni accès dont je serais seul détenteur, ni document que je serais seul à savoir lire.

Je le formule sans détour parce que c'est le point où beaucoup de missions de pilotage échouent commercialement pour réussir humainement, ou l'inverse : un intervenant qui prépare son propre départ vaut mieux qu'un consultant qui s'installe. Le même principe vaut quand vous externalisez le pilotage de votre projet : la question à poser au premier rendez-vous est celle des conditions de sortie.

À propos de l'auteur

Laurent Tulpan

Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il reprend des équipes et des projets pour le compte de ses clients, face aux agences comme en interne, pour des grands comptes comme pour des PME (TF1, SFR, Orange, SNCF). Découvrir son approche.