8 min lecture • Guide 87 of 877
Créer un Onboarding Efficace pour Nouveaux Développeurs
L'onboarding de nouveaux développeurs peut prendre des semaines ou mois sans structure, laissant les nouveaux arrivants confus et les membres existants constamment interrompus. Un programme d'onboarding efficace utilise NoteVault de GitScrum pour la documentation, des tâches initiales soigneusement conçues, et des attentes claires pour réduire le temps-vers-premier-commit de semaines à jours. L'objectif n'est pas juste la configuration technique—c'est créer la sécurité psychologique et construire des relations qui permettent la productivité à long terme.
Philosophie d'Onboarding
Ce Qu'un Bon Onboarding Accomplit
RÉSULTATS ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ MESURER SUCCÈS ONBOARDING │
├─────────────────────────────────────────────────────────────┤
│ │
│ MAUVAIS ONBOARDING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Semaine 1: "Lis le wiki" (obsolète, fragmenté) ││
│ │ Semaine 2: "Suis quelqu'un" (interrompt leur travail) ││
│ │ Semaine 3: "Prends n'importe quel ticket" (pas contexte)││
│ │ Semaine 4: Pose encore questions basiques ││
│ │ Mois 2: Finalement un peu productif ││
│ │ Mois 3: Découvre encore connaissance tribale ││
│ │ ││
│ │ Résultat: Nouvelle recrue se sent incompétente ││
│ │ Équipe frustrée par interruptions ││
│ │ Première vraie contribution: 4-6 semaines ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ONBOARDING EFFICACE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Jour 1: Environnement fonctionne, premier PR merged ││
│ │ Jour 2-3: Compléter 2-3 "good first issues" ││
│ │ Semaine 1: Pairé sur vraie fonctionnalité avec mentor ││
│ │ Semaine 2: Première fonctionnalité propre end-to-end ││
│ │ Semaine 3-4: Contribue à 50% capacité ││
│ │ Mois 2: Membre complet, mentorant prochaine recrue ││
│ │ ││
│ │ Résultat: Nouvelle recrue se sent capable ││
│ │ Équipe gagne contributeur rapidement ││
│ │ Première vraie contribution: 2-3 jours ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Framework 30-60-90 Jours
ATTENTES PROGRESSIVES:
┌─────────────────────────────────────────────────────────────┐
│ PHASES ONBOARDING │
├─────────────────────────────────────────────────────────────┤
│ │
│ PREMIERS 30 JOURS: APPRENTISSAGE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Objectifs: ││
│ │ • Environnement entièrement configuré et fonctionnel ││
│ │ • Comprendre architecture codebase ││
│ │ • Compléter 5-10 petites tâches ││
│ │ • Rencontrer tous membres équipe en 1:1 ││
│ │ • Savoir qui demander pour quoi ││
│ │ ││
│ │ Métrique succès: Peut exécuter, tester, déployer ││
│ │ code indépendamment ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ JOURS 31-60: CONTRIBUTION │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Objectifs: ││
│ │ • Posséder 2-3 fonctionnalités moyennes end-to-end ││
│ │ • Participer aux revues code (donner + recevoir) ││
│ │ • Participer et contribuer aux cérémonies sprint ││
│ │ • Commencer à identifier améliorations ││
│ │ ││
│ │ Métrique succès: Complète fonctionnalités avec niveau ││
│ │ normal de support ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ JOURS 61-90: OWNERSHIP │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Objectifs: ││
│ │ • Posséder une zone du codebase ││
│ │ • Prendre décisions architecturales (avec guidance) ││
│ │ • Améliorer documentation basée sur expérience ││
│ │ • Aider à onboarder prochaine recrue ││
│ │ ││
│ │ Métrique succès: Membre complet, principalement autonome││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Documentation dans NoteVault
Runbook Onboarding
DOCUMENTATION STRUCTURÉE:
┌─────────────────────────────────────────────────────────────┐
│ STRUCTURE NOTEVAULT ONBOARDING │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📓 Guide Onboarding │
│ │ │
│ ├─ 📄 Bienvenue & Vue d'Ensemble Équipe │
│ │ • Qui nous sommes, ce qu'on construit │
│ │ • Liste équipe avec photos, rôles, contact │
│ │ • Normes communication (quand Slack vs email) │
│ │ • Calendrier réunions et attentes │
│ │ │
│ ├─ 📄 Checklist Jour 1 │
│ │ ☐ Comptes créés (GitHub, GitScrum, Slack) │
│ │ ☐ Repo cloné et tourne localement │
│ │ ☐ Premier PR merged (typo fix ou README update) │
│ │ ☐ Présenté dans canal Slack équipe │
│ │ ☐ 1:1 planifié avec manager │
│ │ ☐ Buddy assigné et intro meeting fait │
│ │ │
│ ├─ 📄 Setup Développement Local │
│ │ • Prérequis (version Node, Docker, etc.) │
│ │ • Instructions setup étape par étape │
│ │ • Erreurs courantes et solutions │
│ │ • Vérification: "Terminé quand tests passent" │
│ │ │
│ └─ 📄 FAQ & Connaissance Tribale │
│ • "Pourquoi fait-on X de cette façon?" │
│ • Décisions historiques et contexte │
│ • Pièges courants │
│ • Qui sait quoi (carte expertises) │
│ │
└─────────────────────────────────────────────────────────────┘
Tâches Initiales
Good First Issues
CONCEVOIR TÂCHES INITIALES:
┌─────────────────────────────────────────────────────────────┐
│ PREMIÈRES TÂCHES IDÉALES DANS GITSCRUM │
├─────────────────────────────────────────────────────────────┤
│ │
│ CARACTÉRISTIQUES BONNES TÂCHES INITIALES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ Petit périmètre (1-4 heures) ││
│ │ ✅ Critères acceptation clairs ││
│ │ ✅ Touche vrai code production ││
│ │ ✅ Faible risque si fait incorrectement ││
│ │ ✅ Introduit un nouveau concept ││
│ │ ✅ A des patterns existants à suivre ││
│ │ ││
│ │ ❌ PAS: "Refactoriser système authentification" ││
│ │ ❌ PAS: "Corriger ce bug" (sans contexte) ││
│ │ ❌ PAS: "Construire nouvelle fonctionnalité" (trop large)││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EXEMPLE BONNE PREMIÈRE TÂCHE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tâche: Ajouter état chargement à liste utilisateurs ││
│ │ ││
│ │ Labels: good-first-issue, onboarding ││
│ │ Estimation: 2 points ││
│ │ ││
│ │ Description: ││
│ │ Actuellement liste utilisateurs n'affiche rien pendant ││
│ │ chargement. Ajouter un spinner de chargement. ││
│ │ ││
│ │ Critères acceptation: ││
│ │ ☐ Spinner affiche pendant fetch utilisateurs ││
│ │ ☐ Spinner correspond pattern existant ProductList ││
│ │ ☐ Test ajouté pour état chargement ││
│ │ ││
│ │ Pour commencer: ││
│ │ 1. Voir comment ProductList gère loading (src/components)│
│ │ 2. UserList est dans src/features/users/UserList.tsx ││
│ │ 3. Utiliser composant <Spinner /> de src/ui ││
│ │ ││
│ │ Demander à @mentor si bloqué plus de 30 minutes ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Modèle Mentorat
Système Buddy
RÔLE BUDDY ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ RESPONSABILITÉS BUDDY │
├─────────────────────────────────────────────────────────────┤
│ │
│ QUI: Membre expérimenté équipe (pas manager) │
│ │
│ DEVOIRS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PREMIÈRE SEMAINE: ││
│ │ • Check-in quotidien 15-min ││
│ │ • Pairer sur premières tâches ensemble ││
│ │ • Revoir tous PRs même jour ││
│ │ • Disponible pour "questions bêtes" (sans jugement) ││
│ │ • Présenter aux membres équipe ││
│ │ ││
│ │ SEMAINES 2-4: ││
│ │ • 2-3 check-ins par semaine ││
│ │ • Premier reviewer sur PRs ││
│ │ • Pairer sur tâches complexes ││
│ │ • Naviguer questions organisationnelles ││
│ │ ││
│ │ MOIS 2+: ││
│ │ • Check-in hebdomadaire ││
│ │ • Transition vers relation équipe normale ││
│ │ • Rétrospective sur expérience onboarding ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ALLOCATION TEMPS BUDDY: │
│ Semaine 1: ~4 heures (20% de semaine) │
│ Semaine 2-4: ~2 heures (10% de semaine) │
│ Mois 2: ~1 heure (5% de semaine) │
│ │
│ C'est du VRAI TRAVAIL. Tâches buddy réduites en conséquence.│
│ │
└─────────────────────────────────────────────────────────────┘
Sécurité Psychologique
Créer Environnement Sûr
PSYCHOLOGIE NOUVELLE RECRUE:
┌─────────────────────────────────────────────────────────────┐
│ CONSTRUIRE CONFIANCE │
├─────────────────────────────────────────────────────────────┤
│ │
│ PEURS COURANTES NOUVELLE RECRUE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Je vais poser question bête et paraître incompétent" ││
│ │ "Tout le monde semble tout savoir" ││
│ │ "J'aurais dû comprendre ça déjà" ││
│ │ "Mon code n'est pas aussi bon que le leur" ││
│ │ "Ils ont fait erreur en m'embauchant" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COMPORTEMENTS QUI CONSTRUISENT SÉCURITÉ: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ "Super question, j'ai pas su ça pendant des mois" ││
│ │ ✅ "Laisse-moi te montrer comment j'approcherais ça" ││
│ │ ✅ "J'ai fait même erreur quand j'ai commencé" ││
│ │ ✅ "Voici ce qui N'EST PAS documenté..." ││
│ │ ✅ "Ta perspective fraîche a trouvé vrai problème" ││
│ │ ││
│ │ ❌ "C'est dans les docs" (sans aider à trouver) ││
│ │ ❌ "Tu devrais déjà savoir ça" ││
│ │ ❌ Soupirer quand questions posées ││
│ │ ❌ Critiquer PR sans expliquer pourquoi ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘