Lundi dernier, un nouveau dev a rejoint Be API. Vendredi, il avait déjà livré sa première feature sur un projet client sans qu’on ait pris de retard au planning. Voilà comment on s’y prend :
Chez nous, tous les nouveaux devs, même seniors, commencent avec une vélocité de 2.
Concrètement, ça veut dire que les premières semaines, ils ont 2 h pour faire une tâche estimée à 1 h.
Si on fait ça, c’est parce que même un très bon dev n’est pas efficace immédiatement dans un environnement qu’il découvre.
Il doit d’abord comprendre:
• le codebase
• l’architecture
• les conventions
• les process
• les habitudes de l’équipe
Si on planifie 1h pour 1h de travail estimé, on prend le risque que :
• la tâche déborde
• le planning prend du retard
• l’équipe compense
Bref, intégrer quelqu’un finit par ralentir tout le monde.
On préfère assumer la phase d’apprentissage.
Pendant l’onboarding, 1h estimée = 2h planifiées.
Résultat : les nouveaux devs peuvent travailler directement sur les projets en cours, sans mettre le planning sous tension.
L’objectif est qu’ils atteignent progressivement une vélocité de 1 d’ici la fin de leur période d’essai.
Et ça change tout :
→ le nouveau dev apprend dans le vrai contexte
→ l’équipe ne subit pas de retard
→ le planning reste fiable
Si vous avez d’autres méthodes qui fonctionnent pour rendre l’onboarding efficace, je suis preneur.