Le piège de l'utilisation
Pourquoi être occupé à 100 % ne signifie pas être efficace à 100 %, et comment la marge de manœuvre améliore le flux.
1L'intuition est fausse
Cela semble évident : pour maximiser la productivité, gardez tout le monde occupé. Si les développeurs sont inactifs, vous gaspillez de l'argent.
Cette intuition est fausse pour le travail intellectuel.
Une utilisation élevée (80 % et plus) entraîne :
- De longs temps d'attente
- Une incapacité à absorber la variation
- Aucune capacité pour le travail d'amélioration
- L'épuisement professionnel
Les mathématiques sont brutales. À mesure que l'utilisation approche 100 %, les temps d'attente approchent l'infini. Un système à 99 % d'utilisation a des files d'attente considérablement plus longues qu'un système à 80 %.
2Notions de base de la théorie des files d'attente
La théorie des files d'attente montre que le temps d'attente explose à mesure que l'utilisation augmente :
À 50 % d'utilisation : Le temps d'attente est à peu près égal au temps de service À 80 % d'utilisation : Le temps d'attente est 4 fois le temps de service À 90 % d'utilisation : Le temps d'attente est 9 fois le temps de service À 95 % d'utilisation : Le temps d'attente est 19 fois le temps de service
C'est parce que la variabilité des arrivées et des temps de service crée des files d'attente. Lorsque vous n'avez aucune marge de manœuvre, vous ne pouvez pas absorber la variation.
Exemple concret : S'il faut 2 heures pour réviser une PR, mais que le réviseur est à 90 % d'utilisation, la PR attend 18 heures dans la file d'attente avant que la révision ne commence. Temps total : 20 heures pour une tâche de 2 heures.
Le paradoxe
La marge de manœuvre ne vous ralentit pas — elle vous accélère. Un système à 75 % d'utilisation livre souvent plus rapidement qu'un système à 95 % parce que les files d'attente sont plus courtes.
3Types de marge de manœuvre
La marge de manœuvre n'est pas la même chose que l'inactivité. Il existe des utilisations productives de la marge de manœuvre :
Réduction des files d'attente : Lorsque les limites sont atteintes, la marge de manœuvre permet aux gens d'aider à éliminer les goulots d'étranglement.
Travail d'amélioration : Dette technique, automatisation, améliorations des outils. Cela accélère le travail futur.
Apprentissage : Formation, expérimentation, développement des compétences.
Réactivité : Capacité à gérer les demandes urgentes sans tout perturber.
Collaboration : Aider les coéquipiers, programmation en binôme, partage des connaissances.
Les équipes à 100 % d'utilisation n'ont pas de temps pour tout cela. Elles ne font que traiter des éléments de travail dans une file d'attente. Elles deviennent plus lentes avec le temps parce qu'elles n'investissent jamais dans l'amélioration.
4Le paradoxe de l'amélioration
« Nous n'avons pas le temps d'améliorer notre processus. »
C'est le symptôme le plus courant du piège de l'utilisation. Les équipes sont tellement occupées à faire le travail qu'elles ne peuvent pas améliorer la façon dont elles font le travail.
Mais l'amélioration des processus est la façon d'augmenter durablement la capacité. Sans cela :
- La dette technique s'accumule
- Les outils restent obsolètes
- Les gens ne développent pas leurs compétences
- Les mêmes problèmes se reproduisent
Le cycle :
- Équipe à 100 % d'utilisation
- Pas de temps pour l'amélioration
- Les problèmes persistent, le travail devient plus difficile
- Plus de temps passé à éteindre les feux
- Encore moins de temps pour l'amélioration
- Finalement, la capacité diminue
Briser le cycle :
- Créer délibérément de la marge de manœuvre (les limites de TEC aident)
- Protéger le temps pour l'amélioration (par exemple, allocation de 20 %)
- Traiter le travail d'amélioration comme non négociable
L'équipe fonctionne à 70-80 % d'utilisation. Lorsque les sprints sont légers, elle rembourse la dette technique, automatise les tests, améliore son pipeline CI. Le trimestre suivant, la même équipe livre plus avec moins d'effort.
L'équipe fonctionne à 100 % d'utilisation en permanence. Pas de temps pour les améliorations. La qualité du code se dégrade. Les bogues augmentent. L'équipe travaille plus dur pour livrer la même quantité. Finalement, les gens démissionnent.
5Communiquer cela aux parties prenantes
« Pourquoi les développeurs ne codent-ils pas parfois ? »
Cette question vient de la pensée axée sur l'utilisation. Voici comment recadrer :
Concentrez-vous sur le débit, pas sur l'utilisation. « Nous complétons 10 fonctionnalités par sprint. Préféreriez-vous que nous complétions 8 fonctionnalités mais que tout le monde ait l'air plus occupé ? »
Expliquez le temps d'attente. « Lorsque nous sommes à 100 % de capacité, les demandes urgentes attendent 2 semaines avant de commencer. À 80 %, elles commencent dans les 2 jours. »
Montrez les mathématiques. « Le trimestre dernier, nous avons passé 30 % du temps sur des correctifs d'urgence. Ce trimestre, nous avons passé 20 % sur la prévention, et les correctifs d'urgence sont tombés à 10 %. Gain net : 10 %. »
Utilisez des analogies. « Une autoroute à 100 % de capacité est un stationnement. Une autoroute à 80 % de capacité circule. Laquelle ramène les gens à la maison plus rapidement ? »
L'objectif est de déplacer la conversation de « Les gens sont-ils occupés ? » à « Le travail circule-t-il ? »
Si les parties prenantes résistent, proposez une expérience limitée dans le temps : « Essayons une allocation de 80 % pendant un trimestre et mesurons les délais de livraison. » Les données battent l'argument.
- Une utilisation élevée fait exploser les temps d'attente (théorie des files d'attente)
- La marge de manœuvre permet la réactivité, l'amélioration et la collaboration
- 100 % d'utilisation signifie 0 % de capacité pour l'amélioration ou l'urgence
- Concentrez les conversations sur le débit, pas sur l'utilisation