Remplir le réservoir à ras bord

Topping off the tank

https://seths.blog/2018/12/topping-off-the-tank/ par Seth Godin

Comme l’ère du carburant fossile approche de sa fin, les pompistes (le peu qu’il en reste, ainsi que les pompistes bénévoles qui remplissent eux-mêmes leurs propres réservoirs) persistent à vouloir remplir le réservoir à ras bord.

Après que le déclencheur automatique ait détecté que le réservoir est plein, ils ajoutent dix ou vingt centimes de plus de carburant pour atteindre un chiffre rond.

Pourquoi ?

Ce n’est pas plus rapide. Cela demande du temps pour le faire manuellement.

Ce n’est pas plus profitable. Dix centimes supplémentaires sur un réservoir de 60€ ne justifient pas le temps.

Ce n’est pas plus efficace. Le nombre de kilomètres de plus d’ici au prochain plein est minuscule.

Ce n’est même pas plus facile. La plupart des personnes paient avec une carte de crédit, donc l’arrondi n’aide en rien.

Et…

Cela risque plus probablement d’endommager le véhicule (l’essence sur la carrosserie) et d’endommager la santé du pompiste (avec les vapeurs).

Alors, pourquoi le font-ils ?

Trois raisons

1. Tradition.
2. Montrer au chef et au client que vous bossez dur.
3. Une apparence de contrôle.

C’est la troisième qui est la vraie. Les gens échangent d’énormes quantités de décisions en échange de convenance personnelle, mais pas trop de décisions.

Trop déléguer nous fait ressembler à des automates. Même (ou particulièrement) en travaillant sur des automobiles qui sont des symboles de liberté et de contrôle.

Quelles autres choses cherchons-nous à remplir à ras bord ?

---

Dans le monde du management de projet, n’en va-t-il pas de même ?

N’essayons-nous pas trop souvent de surcharger le contenu de nos livrables de bien plus de fonctionnalités qu’il n’est raisonnable d’en embarquer ?

Ce n’est pas plus rapide. Cela demande plus de temps pour produire la version de notre livrable qui réponde à tous ces besoins dont certains sont probablement moins critiques que d’autres.

Ce n’est pas plus profitable. Comme nous le constatons avec les méthodes Agiles de type Scrum, il vaut mieux limiter le contenu à la durée et à la capacité de production pour obtenir rapidement un produit qui apporte déjà des bénéfices.

Ce n’est pas plus efficace. Produire et tester un livrable beaucoup plus complexe coûte plus de temps et de moyens que plusieurs plus simples.

Ce n’est même pas plus facile. Le suivi des développements et des tests, ou la formation des futurs utilisateurs sont bien plus compliqués.

Et…

Cela risque plus probablement d’endommager le produit (le surplus de fonctionnalités pas toujours critiques ralentit l’adoption par les utilisateurs et accroit les risques de dérapage des délais) et d’endommager la santé des membres de l’équipe projet (en surchargeant leurs plannings et leur mental de choses non critiques).

Alors, pourquoi le faisons-nous encore très fréquemment ?