Productivité
Victor — appelons-le Victor — est développeur. 🤓
Dans son travail, il trouve toujours des moyens d'aller un peu plus vite. ⏱
Le moyen le plus simple d'aller un peu plus vite consiste à remettre la lenteur à plus tard : reporter à une date ultérieure la résolution d'un problème, au besoin en transférant la responsabilité ou le risque vers un acteur distant ou futur. 🌀
Exemples :
Victor voit qu'il pourrait factoriser son code, ça prendrait 10 minutes et supposerait de lancer les tests… qu'on a pas sur ce module… Un copié-collé, ça passe. 😇
Victor vient de terminer une tâche un peu longue, un morceau de bravoure en vérité, qui optimise la gestion de la persistence. Idéalement, il faudrait qu'il demande une revue, mais les revues, ça prend du temps. Imaginez que ses coéquipiers lui disent qu'il faut tout revoir ! Sans compter les débats interminables sur le design… 🤺
Victor a reçu une demande de changement, à traiter si possible avant la fin du sprint, qui concerne une règle métier à laquelle on n'a pas fait tellement attention jusqu'à présent. À la lecture du ticket, il n'est pas sûr de bien comprendre la règle en question. L'émetteur du ticket n'étant pas disponible au téléphone, Victor a décidé d'implémenter la règle dans son interprétation la plus simple. Après tout c'est un travail supplémentaire, et ce n'est pas comme si le projet était en avance. 🚚
Lorsque Victor et son équipe ont remis la lenteur à plus tard pendant des semaines, voire des mois, ils se retrouvent face à un trop-plein de "lenteur à devoir" accumulée.
La façon dont ce trop-plein se matérialise varie selon les situations, mais en règle générale, on peut dire que la lenteur accumulée devient manifeste lorsque les stratégies habituelles pour l'évacuer, la repousser à plus tard, échouent.
🔥
En adoptant le programme à une demande de changement, l'équipe a oublié un des copiés/collés. La régression ne s'est manifestée que 3 mois après la mise à jour. Il a fallu 2 jours entiers pour corriger le problème.
🔥 🪣
Après des semaines à gérer des urgences, l'équipe a enfin pris le temps de s'intéresser au module réécrit par Victor. Le verdict est sans appel : le code est incompréhensible, non-standard, à réécrire. Compter un mois de travail.
🔥 🚒
Pour ce qui est de la demande de changement implémentée sans consulter le demandeur, ça n'a pas raté : la règle ne convient pas. Un examen complet de la demande aurait montré que celle-ci comportait des incohérences. Maintenant l'application présente un défaut, qu'il faut expliquer, contourner, et corriger en urgence.
🔥 🚒 🚑 🚧 🚓 🎥 📡
Il serait facile, et futile, de blâmer Victor pour son manque de professionalisme. En mode : le problème, c'est Victor. 👻
Autant l'accuser de manquer de chance : Victor n'y peut rien. L'urgence est inscrite dans le process. Les acteurs ne font que s'y adapter.
Comme dit Deming : A bad system will beat a good person every time.
Stay tuned !