Apprentissage, Performance
🏭 Chère entreprise,
Il faut se rendre à l'évidence : tu obtiens ce que tu demandes exactement, quoi que tu obtiennes.
Si ton règlement exige que tes développeurs·es soient payés à produire et non à se former, tu obtiendras des développeurs·es qui produisent, et ne se forment pas. Dès lors, ta capacité à créer et maintenir du logiciel de qualité va dépendre de la formation initiale de tes collaborateurs·ices et de leur vocation à s'améliorer sur leur temps perso.
Caveat : dans une fameuse école d'ingé parisienne on disait encore il y a quelques années : "Les tests, c'est pour ceux qui ne savent pas coder". 🧐
En même temps je connais des développeurs qui ont bientôt 35 ans d'expérience et qui n'ont jamais écrit un test auto. Ils travaillent dans une ESN qui fait des milliards de bénéfices. Ils prestent pour des entreprises clientes qui obtiennent ce qu'elles demandent.
Alors bien sûr, laisser ton personnel se former au lieu de produire, ce n'est pas de la bonne gestion. Le temps des salariés et des prestataires coûte cher. Mais tu n'as pas seulement besoin de produire : il te faut aussi t'améliorer. C'est vrai partout dans l'industrie, et en informatique c'est une évidence axiomatique, à moins que tes équipes ne soit occupées à réinventer la roue (et je suis sûr qu'il y a des clients pour ça). 🎡
Oui, dis-tu, mais il faut aller vite ! 🏎
Ah, la vitesse ! Mais la vitesse dépend de la stabilité. La vitesse sans la stabilité, c'est le chaos.
⇒ Plus ta production est performante, plus tu as des marges de manœuvre pour t'adapter
⇒ Plus tu as de marges de manœuvre, plus tu peux apprendre
⇒ Plus tu peux apprendre, moins il y a de variations incontrôlées dans ta production
⇒ Moins il y a de variations, plus tes performances augmentent
{:width="800px"}
Cela peut être un cercle vertueux : 💬
— On a stabilisé cette version, je propose qu'on décale la prochaine feature.
— Décaler, pour quoi faire ?
— Pour consolider ce qu'on a mis en place dans cette version : mettre à jour l'ADR, refactorer en binômes, documenter…
— OK.
Et bien sûr cela peut être un cercle vicieux : 🗯
— Je crois que j'ai enfin pu corriger ce bug.
— C'est pas trop tôt. Hop ! On relivre.
— Attends, est-ce qu'on pourrait poser quelques tests… 😬
— On relivre, je te dis, on verra ça plus tard ! On est en retard ! 🤬
Dans un projet en crise, on n'apprend pas (on s'adapte). Dans un projet stable, on apprend.
Alors chère entreprise, si ton projet n'est pas stable, tu es sans doute aux prises avec un cercle vicieux. De ces deux stratégies :
1️⃣ Tes développeurs·es se forment le soir et le week end sur leur propres ressources
2️⃣ Tu mets en place un process d'amélioration continue
Laquelle est la plus fiable ? La plus pérenne ?
Tu veux aller plus vite ?
🛠 améliore ton outillage
🎚 améliore tes standards
📋 améliore ton process
🤸🏻♂️ cesse de compter uniquement sur les quelques passionné·es qui ont du temps libre