Gaspillages 3 et 4 : Transferts et attentes

Chaque fois que le travail passe d'une personne ou d'une équipe à une autre, le contexte se perd.

Le chef de produit rédige les exigences. Il connaît la douleur de l'utilisateur, les contraintes commerciales, les compromis de priorité. Il transmet cela à un designer.

Le designer lit les exigences, pose des questions de clarification (dont certaines auxquelles le chef de produit ne peut plus répondre parce que le contexte s'est estompé), et crée des maquettes. Il transmet cela aux développeurs.

Les développeurs lisent les exigences et les maquettes, posent des questions de clarification (dont certaines auxquelles ni le chef de produit ni le designer ne peuvent plus répondre), et construisent quelque chose. Ils transmettent cela à l'AQ.

L'AQ teste par rapport aux exigences, trouve des problèmes, et retransmet aux développeurs.

À chaque transfert, de l'information se perd. Au moment où la fonctionnalité atteint les utilisateurs, elle ressemble à peine à ce que le chef de produit comprenait initialement des besoins des utilisateurs. Et chaque transfert a pris du temps — parfois des jours d'attente dans les files.

Les transferts sont l'endroit où le contexte va mourir.

La majeure partie du délai est du temps d'attente, pas du temps de travail. Une tâche qui prend 2 heures de travail actif peut avoir un délai de 2 semaines. Où va le reste ?

• Temps de file : Attente dans les backlogs pour la priorisation
• Attente de révision : PR qui restent sans révision
• Attente d'approbation : Décisions bloquées dans la gestion
• Attente de dépendances : Bloqué par d'autres équipes
• Attente d'environnements : Impossible de tester parce que la préproduction est cassée
• Attente d'information : Questions sans réponse
• Attente de planification : Réunions qui ne peuvent pas avoir lieu avant la semaine prochaine

Chaque attente introduit un délai et nécessite souvent une refamiliarisation lorsque le travail reprend. Vous lisez le code, comprenez le contexte, êtes interrompu, et devez reconstruire ce contexte plus tard.

L'efficacité du flux mesure le temps à valeur ajoutée en pourcentage du délai. Dans la plupart des organisations logicielles, elle est de 5 à 15 %. Cela signifie que 85 à 95 % du temps, le travail attend, il n'est pas travaillé.

Équipes interfonctionnelles : Rassemblez toutes les compétences nécessaires pour livrer de la valeur dans une seule équipe. Produit, design, développement, tests — tous ensemble. Les transferts deviennent des conversations.

Spécialistes généralistes : Des personnes qui ont une expertise approfondie dans un domaine mais peuvent contribuer dans d'autres. Quand le travail s'accumule en révision, les développeurs peuvent aider à réviser. Moins de files.

Programmation en binôme et en groupe : Deux personnes ou plus travaillant ensemble éliminent les transferts au sein du travail. La révision est intégrée. Le transfert de connaissances est continu.

Collaboration en temps réel : Remplacez les transferts asynchrones par une collaboration synchrone. Au lieu d'écrire une spécification, ayez une conversation. Au lieu de signaler un bogue, allez voir le développeur et montrez-lui.

Éliminez les approbations : La plupart des étapes d'approbation n'ajoutent aucune valeur — ce sont des mécanismes de contrôle issus d'environnements à faible confiance. Remettez en question chaque approbation : Quelle valeur cela ajoute-t-il ? Pourrions-nous obtenir le même bénéfice autrement ?

Automatisez les transferts : Si le travail doit être transféré, automatisez la file. Pipelines CI/CD qui déploient automatiquement. Robots de PR qui notifient immédiatement les réviseurs. Intégrations Slack qui font remonter le travail bloqué.

L'objectif n'est pas de travailler plus vite — c'est d'attendre moins. Attaquez les 85 %, pas les 15 %.