Gaspillages 5 et 6 : Changement de tâche et défauts

Chaque fois que vous changez de tâche, vous payez une taxe.

La recherche montre systématiquement que le changement de contexte coûte 15 à 25 minutes pour retrouver une productivité complète. Pas pour commencer à travailler — pour atteindre la même profondeur de concentration que vous aviez avant l'interruption.

Si vous changez de contexte 4 fois dans un après-midi, vous pourriez passer plus de temps à vous réorienter qu'à réellement travailler.

En fabrication, ce gaspillage s'appelle « transport » et « mouvement » — déplacement inutile de matériaux ou de personnes. En logiciel, c'est le déplacement inutile de l'attention.

Sources de changement de tâche :

• Trop de travail en cours : Jongler avec plusieurs projets signifie des changements constants
• Interruptions : Messages Slack, tapes sur l'épaule, « questions rapides »
• Réunions : Chaque réunion est un changement de contexte aller-retour
• Courriels/notifications : Vérifier constamment fragmente l'attention
• Priorités floues : Ne pas savoir sur quoi travailler mène à l'agitation

Le coût n'est pas seulement le temps — c'est la qualité. Le travail superficiel produit des résultats superficiels. Le travail en profondeur nécessite une concentration soutenue. Le changement de tâche empêche le travail en profondeur.

Les défauts sont un gaspillage pour des raisons évidentes : ils nécessitent une reprise de travail. Mais le coût réel est pire qu'il n'y paraît.

Les défauts trouvés tard coûtent exponentiellement plus cher que les défauts trouvés tôt. Un bogue détecté en développement peut prendre 10 minutes à corriger. Le même bogue trouvé en test peut prendre une heure (reproduction, diagnostic, correction, nouveau test). Trouvé en production, il peut prendre des jours (investigation, communication client, correction d'urgence, post-mortem).

Les défauts engendrent des défauts. Corriger un bogue sous pression introduit souvent de nouveaux bogues. La base de code devient un champ de mines. Les développeurs ralentissent. La qualité se dégrade en spirale.

Les défauts détruisent la confiance. Après suffisamment d'incidents en production, chaque changement nécessite une approbation extensive, des tests extensifs, une validation extensive. Le processus s'alourdit pour se protéger contre les défauts que le processus crée.

Le gaspillage caché : l'inspection et les tests. Si vous avez des défauts, vous avez besoin d'une AQ extensive. L'AQ est un gaspillage nécessaire — elle n'ajoute pas de valeur, elle ne fait qu'attraper le gaspillage créé par les défauts. Intégrez la qualité, et vous aurez besoin de moins d'inspection.

Pour le changement de tâche :

Limites de travail en cours : L'intervention la plus directe. Si vous ne pouvez travailler que sur une chose à la fois, vous ne pouvez pas changer de contexte. Terminez avant de commencer.

Communication groupée : Vérifiez le courriel/Slack à des intervalles définis, pas constamment. Faites savoir aux gens quand vous êtes disponible et quand vous ne l'êtes pas.

Temps sans réunion : Désignez des blocs pour le travail concentré. Protégez-les farouchement.

Priorités plus claires : Si les gens ne savent pas sur quoi travailler, ils s'agitent. Rendez les priorités explicites et stables.

Pour les défauts :

Développement piloté par les tests : Écrivez les tests d'abord. Intégrez la qualité dès le départ, ne l'inspectez pas à la fin.

Programmation en binôme : La révision en temps réel attrape les erreurs avant qu'elles ne deviennent des bogues.

Intégration continue : Trouvez les bogues d'intégration immédiatement, quand le contexte est frais et les corrections peu coûteuses.

Arrêtez et corrigez : Quand vous trouvez un bogue, corrigez-le maintenant. Ne l'ajoutez pas à un backlog pour qu'il vieillisse. Le principe du cordon andon de Toyota.

Post-mortems sans blâme : Quand des bogues s'échappent, comprenez pourquoi sans blâmer. Corrigez le système qui a permis le bogue, pas seulement le bogue lui-même.