Mieux travailler ensemble : un référentiel commun contre le gaspillage de temps

Votre équipe est compétente, votre logiciel tourne, et pourtant tout prend plus de temps que prévu. Pas à cause d’un problème identifiable, plutôt d’une somme de petites choses : une question qui attend sa réponse ou qu’on se repose plusieurs fois, un ticket compris de travers, une relecture qui discute de la forme, une consigne passée à l’oral qui arrive déformée. Une accumulation de petites pertes qui, à long terme, produisent des écarts gigantesques.

Ce temps se perd à deux endroits : dans des pratiques non optimales, qui font refaire, attendre ou chercher, et dans des incompréhensions entre personnes, quand un mot n’a pas le même sens pour celui qui demande et celui qui réalise. Un référentiel commun traite les deux. C’est un ensemble de conventions écrites, partagées, qui retirent la négociation du chemin. Et il n’est utile qu’à une condition : qu’il vive, c’est-à-dire que chaque gaspillage repéré devienne une règle ou un outil, écrit là où tout le monde le lit et l’utilise au quotidien.

Cet article explique comment nous nous y prenons, à parts égales entre pratiques de développement et pratiques de gestion de projet, parce que c’est le même mécanisme qui joue des deux côtés. Il se termine sur ce qui, chez moi, a rendu cette chasse au gaspillage aussi ancrée et a forgé les pratiques que vous retrouvez chez SmartBooster.

Ce qu’une équipe gaspille sans le voir

Le lean a nommé les gaspillages d’une usine il y a longtemps. Transposés à une équipe qui fabrique du logiciel, quatre d’entre eux reviennent partout :

L’attente. Une question posée sans réponse bloque une journée. Une validation qui traîne bloque une livraison. Le travail n’est pas perdu, il est immobilisé et non acquis.
La reprise. Un ticket compris de travers se développe deux fois. Une règle métier découverte après coup se corrige dans du code déjà livré. C’est le gaspillage le plus cher, parce qu’il inclut tout ce qui a été fait avant de s’en rendre compte.
La surqualité au mauvais endroit. Une revue de code qui passe vingt minutes sur des espaces et des guillemets a consommé l’attention qu’elle aurait dû mettre sur la logique. L’effort existe, il est mal placé.
Le transport d’information. Une consigne passée de bouche à oreille se déforme à chaque relais, et chaque relais y passe du temps. Notre page sur la communication le dit simplement : une information transmise de personne à personne se déforme et coûte le temps de tout le monde.

Ces quatre gaspillages ont un point commun : ils ne se voient pas dans un budget, ils se voient dans un délai et dans une frustration. Et une frustration est un gaspillage humain aussi réel que le gaspillage financier, parce qu’elle use l’attention et la motivation, deux ressources qui ne se refacturent pas.

L’hésitation : le gaspillage qui se multiplie

Il en existe un cinquième, plus discret, et c’est celui que je combats le plus : l’hésitation. Le développeur qui ne sait pas s’il peut prendre une décision et attend de la faire valider. Le chef de projet qui redemande une confirmation déjà donnée, parce qu’elle n’est écrite nulle part. La réunion convoquée pour trancher quelque chose que tout le monde savait déjà. Chaque hésitation prise isolément coûte quelques minutes. Le problème, c’est qu’elle se propage de manière démesurée.

Une hésitation en produit une autre : celui qui attend une validation en bloque un autre, qui redemande à un troisième, et la question remonte jusqu’à quelqu’un qui n’aurait jamais dû en entendre parler. Une équipe où chacun doit revalider ce qui est évident travaille bien en dessous de sa capacité, et l’écart grandit avec la taille de l’équipe.

Construire un référentiel commun

Un référentiel commun n’est pas un règlement, c’est un socle sur lequel nous pouvons nous reposer. C’est une collection de décisions actées de manière claire, écrites, pour que chacun puisse les retrouver et les faire vivre.

Ce qui me frappe dans cette démarche, c’est que chaque pratique de développement a son équivalent côté gestion de projet et communication humaine. Ce sont souvent les mêmes patterns (ou motifs en français) qui s’appliquent.

Définir un formatage clair

Côté code. Un formateur automatique décide de la forme à notre place : indentation, guillemets, ordre des attributs, retours à la ligne. PHP CS Fixer le fait pour notre code PHP, Prettier pour notre code JavaScript et Vue.js, et les deux tournent avant même que le code soit soumis. Le résultat n’est pas un code plus joli, c’est un sujet en moins : plus personne ne débat de la forme en relecture, et une merge request arrive déjà propre sur ce point. Ce que nous avons choisi comme règles et pourquoi nous avons retenu ces outils plutôt que d’autres est documenté dans notre standard-bundle, la configuration que chaque projet embarque.

Côté équipe. Nos templates de documents et le vocabulaire partagé font exactement la même chose avec les mots. « Rapidement », « urgent », « simple », « une petite mise à jour » : ce sont des mots vides de sens, non parce qu’ils ne disent rien, mais parce que chacun les remplit avec son propre sens. Notre playbook liste ceux qui reviennent le plus, et ce qu’il faut définir à la place. Retirer ces mots d’une demande retire une négociation qui aurait eu lieu, souvent trop tard, au moment de la livraison.

Détecter les erreurs au plus tôt

Côté code. L’analyse statique lit le code sans l’exécuter et signale ce qui va casser : un type incohérent, une méthode qui n’existe plus, une donnée non vérifiée qui arrive jusqu’à une requête. PHPStan le fait à son niveau le plus strict sur tous nos projets, Psalm suit les données non fiables jusqu’aux endroits où elles deviennent une faille. L’erreur est vue sur le poste du développeur, avant l’exécution, avant la revue et avant la production. Chaque étape franchie sans la voir aurait multiplié son coût.

Côté équipe. La trame de ticket joue le même rôle avec la demande. Un ticket porte un objectif, une description découpée et des cas de test préparés avant de développer, cas d’erreur et cas limites en premier. Une incompréhension repérée à l’écriture du ticket coûte dix minutes de discussion. La même, repérée à la livraison, coûte le développement entier, plus la correction, plus la confiance.

Savoir qui a fait quoi, et pourquoi

Côté code. Chaque branche porte l’identifiant de son ticket, et chaque commit aussi. Notre convention de commit tient en trois règles : tout commit est lié à un ticket de gestion de projet, son message dit l’objectif de la modification, et il ne paraphrase pas le code, git diff est là pour ça. Deux ans plus tard, un développeur qui ouvre un git blame sur une ligne étrange retrouve le ticket, le besoin et la personne qui l’a exprimé, sans demander à personne. C’est de la traçabilité dans les deux sens : du besoin à la ligne de code, et de la ligne de code au besoin.

Côté équipe. Le cycle de vie d’un ticket fait la même chose avec le travail en cours. Six étapes, et pour chacune une condition d’entrée écrite : un ticket ne passe à « à faire » que s’il est complet et budgété, à « en cours » que si la personne assignée a relu et confirmé qu’elle peut travailler. À tout moment, chacun sait à quelle étape il intervient et ce qui manque pour passer à la suivante. Personne ne demande « où en est-on ? », la réponse est sur le tableau.

Le bon feedback par le bon canal et au bon moment

Côté code. La merge request est le moment du retour sur le code, et elle a ses règles : un historique nettoyé avant de soumettre, une description qui dit ce qu’il faut regarder, des retours traités commit par commit. Le retour arrive quand le travail est prêt à le recevoir, ni avant, quand il est inutile, ni après la livraison, quand il coûte le plus.

Côté équipe. Le point projet est le moment du retour sur le projet, et la communication a ses règles pour tout le reste : une question qui demande réflexion se pose en avance et par écrit, une interruption est une décision et pas un réflexe, parce que reprendre une tâche interrompue coûte bien plus que les deux minutes de l’interruption. Et quand un échange ne produit plus rien, chacun a le droit de dire stop. Ce droit n’est pas une impolitesse, c’est une règle née d’un gaspillage constaté.

L’essentiel à comprendre : une convention est une décision qui a déjà été prise. Quand elle est écrite, personne n’a besoin de la revalider, et l’hésitation n’a plus de place où s’installer. C’est la raison pour laquelle nous investissons autant dans nos outils, nos documentations et nos méthodes de travail : ce ne sont pas des contraintes, ce sont des décisions dont l’équipe n’a plus à s’occuper.

Un référentiel qui vit : la démarche lean

Un référentiel figé meurt en quelques mois. Les règles que personne ne peut plus expliquer se contournent, puis s’ignorent, et l’équipe revient aux habitudes individuelles. Ce qui fait tenir un référentiel commun, c’est l’amélioration continue, au sens que le lean lui donne : des petits pas, fréquents, décidés par ceux qui font le travail.

Concrètement, chaque gaspillage repéré produit une règle ou un outil, en petit pas, écrit et daté :

Côté code, une règle adoptée devient une configuration livrée avec chaque projet, et une décision d’outillage devient une note de décision publique dans le standard-bundle. Quand nous avons retiré un outil de contrôle qui faisait deux fois le même travail qu’un autre, la raison est écrite, datée, et lisible par quiconque se posera la question dans deux ans.
Côté équipe, une situation qui a coûté du temps devient une page ou un paragraphe du playbook. Le droit au stop en est un exemple. Les mots vides de sens en sont un autre : la liste s’allonge chaque fois qu’un mot a provoqué un aller-retour qu’une définition aurait évité.

Et la règle inverse existe : une convention que personne ne peut expliquer se retire. Un référentiel commun n’est pas fait pour grossir. Au contraire, comme notre code, il doit être assez spécifique pour obtenir le niveau de qualité recherché tout en étant assez condensé pour ne pas contenir de superflu.

Notre playbook et nos outils sont des projets vivants, améliorés en continu par l’ensemble de l’équipe, au fil de nos apprentissages.

L’objectif à atteindre : mieux travailler ensemble et avancer

« Mieux travailler ensemble », c’est l’expression si chère à notre ancien client et ami le Docteur Denis Lamboley, spécialiste en santé préventive et gestion du stress.

Pendant six ans, nous avons fait évoluer avec sa pépite Wellscan, un outil de diagnostic mesurant la qualité de vie et la performance au travail en cartographiant les forces et faiblesses d’une personne et d’une organisation.

Facteurs managériaux et organisationnels, charge de travail, relations et ambiance au travail, RPS, burnout et plus spécifiquement l’index de Flow et le boreout : autant de sujets passionnants sur lesquels Wellness-Management nous a fait progresser, avec un impact grandement positif sur SmartBooster.

Ce que nous en avons gardé tient en une conviction : le gaspillage humain est aussi réel que le gaspillage financier. Une réunion inutile, une demande réexpliquée trois fois, une décision qui attend, coûtent en attention et en motivation avant de coûter en heures. Un référentiel commun protège aussi cela, et c’est peut-être sa raison la plus solide.

Conclusion : notre référentiel est partagé en public

Tout ce que cet article décrit est en ligne. Le playbook SmartBooster est notre référentiel commun rendu public : la mission qui le motive, la façon dont nous communiquons, et le parcours d’une demande du ticket à sa clôture. Le standard-bundle en est la partie code, embarquée dans chaque projet que nous livrons, et symfony-docker la partie environnement : le même poste de développement pour toute l’équipe, prêt en une commande, pour que personne ne perde une journée à configurer sa machine ni ne découvre en production un écart qui n’existait pas chez lui.

Ce n’est pas un document de plus. C’est la somme de nos décisions déjà prises, pour que nos clients et les équipes avec qui nous travaillons partent du même endroit, sans avoir à renégocier ce qui est évident. Vous pouvez le lire avant de nous contacter, et vous en servir si cela peut avoir un impact positif sur votre quotidien.

Post-scriptum : les origines cachées

Je dois bien avouer que cette recherche de l’optimisation et ce rejet clair du gaspillage sont deux sujets très présents chez moi, bien plus que chez la majorité des gens.

Mes parents étaient restaurateurs et aussi loin que je me souvienne, j’ai toujours vu mon père optimiser la gestion de ses achats avec un seul objectif : ne jeter aucune nourriture. Par économie d’abord, mais également par respect de ce qui avait été produit et du travail que ça représentait. Dans une cuisine bien gérée, aucune nourriture ne devrait aller à la poubelle (sauf les retours d’assiette des clients, bien sûr). Cela s’anticipe en amont, dans la commande, pour prévoir les bonnes quantités, puis s’ajuste au quotidien en fonction du flux réel de clients, et enfin se rattrape en étant créatif pour sublimer des produits arrivant proche de la péremption.

Cela a développé chez moi une vigilance au gaspillage qui ne s’est jamais éteinte, et qui s’est déplacée de la nourriture vers ce qu’une entreprise de logiciel consomme : du temps, financier et humain. Un développeur qui attend, une réunion qui tourne à vide, une fonctionnalité développée deux fois, un programme non optimisé qui gaspille des ressources machine, je les vois comme mon père voyait une cagette abîmée. La différence est que le temps ne se voit pas dans une poubelle. Il faut un référentiel commun pour le rendre visible, et une équipe qui a envie de le protéger.

C’est la ressource la plus précieuse que nous ayons, la seule qui ne se rachète pas. Tout ce que nous faisons pour mieux travailler ensemble a ce seul but : la valoriser au maximum dans le respect de chacun.