Vous avez recruté. L’équipe technique a doublé en dix-huit mois, la masse salariale suit, et pourtant la roadmap n’avance pas plus vite qu’avant. Chaque fonctionnalité prend des semaines, chaque demande simple se heurte à une raison de ne pas la faire tout de suite, et vous n’osez plus poser la question de peur de passer pour celui qui ne comprend rien à la technique.
C’est une situation différente du projet confié à un prestataire, et elle est plus difficile, parce que vous ne pouvez pas changer d’équipe. Mais elle a une cause mesurable, et une mesure suffit souvent à la révéler.
Le problème n’est presque jamais la vitesse, c’est la répartition
La question qu’on pose spontanément est « pourquoi mes développeurs vont-ils si lentement ». C’est la mauvaise question, et elle conduit à des réponses toxiques : mettre la pression, découper les tickets plus finement, ajouter du reporting.
La bonne question est où va le temps. Dans la quasi-totalité des équipes où rien ne sort, le temps est bien travaillé, mais réparti sans que personne ne l’ait décidé. Les corrections urgentes, les demandes de dernière minute, la remise en état de code ancien, les tâches nouvelles et visibles s’entremêlent, chacun arbitre dans son coin, et il devient impossible de dire pourquoi une semaine a produit ce qu’elle a produit.
La conséquence est double. Vous perdez la visibilité, donc vous ne pouvez plus décider. Et l’équipe perd le sens, parce que le travail invisible, qui est souvent le plus utile, n’est jamais reconnu.
La mesure qui change tout, et qui coûte une heure
Il existe une mesure simple, que n’importe quelle équipe peut mettre en place en une heure, et qui n’exige aucune compétence technique de votre part. On l’appelle parfois le budget d’ingénierie : la répartition du temps de l’équipe entre quatre catégories.
- Les anomalies. Corriger ce qui est cassé.
- La dette technique. Remettre en état ce qui freine, avant que ça ne bloque.
- Les nouvelles fonctionnalités. Ce qui apporte une valeur directe au métier.
- Les améliorations continues. Automatisation, performance, outillage, montée en compétence.
La mise en place tient en trois gestes. Dans l’outil de suivi que l’équipe utilise déjà, chaque tâche reçoit une étiquette parmi ces quatre. On regarde la répartition une fois par mois. On l’ajuste en fonction de la stratégie, et non de l’urgence du moment.
Une répartition saine ressemble, très grossièrement, à quarante pour cent de fonctionnalités, vingt de dette technique, trente d’améliorations et dix d’anomalies. Les chiffres exacts importent peu ; ce qui compte est de les connaître et de les décider.
Ce que la mesure révèle presque toujours
Quand on regarde pour la première fois, trois situations reviennent.
Les anomalies dépassent trente pour cent. L’équipe passe son temps à réparer. Ce n’est pas un problème de rigueur, c’est le symptôme d’un produit construit trop vite, souvent sous une pression de délai que vous avez vous-même exercée. Ajouter des développeurs n’y changera rien : ils passeront eux aussi leur temps à réparer.
La dette technique est à zéro. C’est apparemment une bonne nouvelle, et c’est presque toujours le contraire. La dette existe, elle n’est simplement pas déclarée : elle se paie en lenteur diffuse sur toutes les autres tâches, et personne ne peut nommer le coût. La part d’anomalies grimpera dans six mois.
Tout est étiqueté « nouvelle fonctionnalité ». Cela signifie que l’équipe a compris que c’était la seule catégorie valorisée par la direction, et déclare tout dedans. Vous avez alors une mesure inutile et, plus grave, une équipe qui a appris à ne pas vous dire la vérité.
Le rôle que vous jouez sans le savoir
Deux réflexes de dirigeant, tous deux compréhensibles, alimentent directement le problème.
L’urgence permanente. Quand chaque demande arrive marquée urgente, plus rien ne l’est, et l’équipe arbitre à votre place, au fil des interruptions. Un projet qui change de priorité toutes les deux semaines n’avance pas plus vite qu’un projet arrêté, il coûte simplement plus cher.
La délégation complète du jugement technique. Beaucoup de dirigeants non techniques s’en remettent entièrement à leur développeur le plus expérimenté. C’est confortable, mais un très bon développeur n’est pas un directeur technique : son métier est de construire, pas d’arbitrer entre le métier, le produit et la dette, ni de dire non à une demande qui vient de vous. Lui confier ces arbitrages, c’est lui demander un travail pour lequel il n’a été ni recruté ni formé, et vous priver du contre-pouvoir dont vous avez besoin.
Trois questions à poser cette semaine
Aucune ne demande de compétence technique, et chacune produit une information exploitable.
« Sur les quatre dernières semaines, quelle part du temps est allée aux corrections ? » Si personne ne sait répondre, vous venez d’identifier le premier chantier, et il ne coûte rien.
« Qu’est-ce qui nous ralentit aujourd’hui, et que nous pourrions réparer une fois pour toutes ? » Les équipes connaissent la réponse, souvent depuis longtemps. Elles ne la disent pas parce que ce travail n’a jamais été reconnu comme légitime.
« Qu’est-ce que je vous demande qui ne sert à rien ? » Celle-ci est inconfortable, et c’est la plus rentable. Attendez-vous à un silence, puis à une réponse qui vaut plusieurs semaines de développement.
Quand un regard extérieur est nécessaire
Il y a un cas où ces questions ne suffisent pas : quand la confiance est déjà abîmée. Si vous soupçonnez que les réponses sont arrangées, ou si votre équipe soupçonne que la question est un procès, la conversation ne produira rien d’utile.
C’est précisément à ce moment qu’un tiers change la donne, à une condition : qu’il n’ait rien à vendre au bout. Un prestataire qui audite votre équipe et qui, par ailleurs, vend des développeurs, trouvera qu’il vous manque des développeurs. Ce n’est pas de la malhonnêteté, c’est de l’arithmétique.
Et c’est aussi vrai à l’intérieur : personne dans votre organisation n’a intérêt à conclure que l’équipe est trop grande, que le projet est trop gros, ou qu’il faut arrêter quelque chose. Y compris vous.
Un état des lieux en une heure, par quelqu’un qui ne vous vendra ni développeurs ni mission : adostin.fr.