9 min lecture • Guide 808 of 877
Planification de Capacité pour la Croissance
La croissance nécessite de la planification. GitScrum aide les équipes à comprendre leur capacité et à planifier l'évolution à mesure que l'organisation grandit.
Comprendre la Capacité
Capacité Actuelle
ÉVALUATION DE LA CAPACITÉ D'ÉQUIPE :
┌─────────────────────────────────────────────────────────────┐
│ │
│ FACTEURS DE CAPACITÉ : │
│ │
│ TEMPS DISPONIBLE : │
│ Jours ouvrables totaux - jours fériés - congés - réunions │
│ │
│ TEMPS EFFECTIF : │
│ Temps disponible × facteur focus (typiquement 60-80%) │
│ Prend en compte : interruptions, admin, support │
│ │
│ COMPÉTENCES ÉQUIPE : │
│ Tout le travail ne peut pas être fait par tous │
│ Goulots sur compétences spécialisées │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CALCUL DE CAPACITÉ : │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CAPACITÉ ÉQUIPE - SPRINT 15 ││
│ │ ││
│ │ MEMBRE JOURS FACTEUR EFFECTIF ││
│ │ ────── ──── ────── ───────── ││
│ │ @alex 10 80% 8 jours ││
│ │ @jordan 8 80% 6.4 jours (2 jours congé) ││
│ │ @pat 10 70% 7 jours (astreinte) ││
│ │ @sam 10 80% 8 jours ││
│ │ @taylor 10 50% 5 jours (formation) ││
│ │ ──────────────────────────────────────────────────────││
│ │ TOTAL : 48 34.4 jours effectifs ││
│ │ ││
│ │ DÉBIT HISTORIQUE : ││
│ │ Sprint 14 : 35 story points ││
│ │ Sprint 13 : 38 story points ││
│ │ Sprint 12 : 32 story points ││
│ │ MOYENNE : ~35 points/sprint ││
│ │ ││
│ │ CAPACITÉ SPRINT 15 : ~32 points ││
│ │ (Plus bas due aux congés et formation) ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Planifier pour la Croissance
Quand Grandir
SIGNES QUE VOUS AVEZ BESOIN DE PLUS DE CAPACITÉ :
┌─────────────────────────────────────────────────────────────┐
│ │
│ SURCHARGE CONSTANTE : │
│ ──────────────────── │
│ • Backlog grandit plus vite que vous livrez │
│ • Engagements de sprint régulièrement manqués │
│ • Équipe travaille des heures non durables │
│ • Qualité souffre due à la précipitation │
│ │
│ GOULOTS : │
│ ──────── │
│ • Une personne bloque plusieurs stories │
│ • Compétences spécialisées en pénurie │
│ • Revues/approbations créent des retards │
│ • Point unique de défaillance │
│ │
│ BESOIN STRATÉGIQUE : │
│ ─────────────────── │
│ • Nouveau domaine produit planifié │
│ • Scaling pour servir plus de clients │
│ • Investissement plateforme technique │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ⚠️ ATTENTION : LOI DE BROOKS │
│ ───────────────────────────── │
│ "Ajouter des personnes à un projet en retard le retarde" │
│ │
│ POURQUOI : │
│ • Nouvelles personnes ont besoin d'onboarding │
│ • Personnes existantes forment au lieu de livrer │
│ • Surcharge de communication augmente │
│ │
│ PLANIFIEZ À L'AVANCE, pas en crise │
└─────────────────────────────────────────────────────────────┘
Division d'Équipe
ÉVOLUTION DES ÉQUIPES :
┌─────────────────────────────────────────────────────────────┐
│ │
│ GRANDIR UNE ÉQUIPE : │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ TAILLE : 5 → 6 → 7 → 8 → 9 → DIVISER ! ││
│ │ ▲ ││
│ │ │ ││
│ │ Optimal ││
│ │ ││
│ │ 5-9 personnes : Zone idéale ││
│ │ 10+ : Surcharge communication trop haute ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ QUAND DIVISER : │
│ ─────────────── │
│ • Équipe atteint 10 personnes │
│ • Frontière de domaine claire existe │
│ • Peut créer équipes autonomes │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ STRATÉGIES DE DIVISION : │
│ │
│ PAR DOMAINE PRODUIT : │
│ ┌──────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Grande Équipe│ ──→ │ Frontend │ │ Backend │ │
│ │ (12 pers.) │ │ Équipe (6) │ │ Équipe (6) │ │
│ └──────────────┘ └────────────┘ └────────────┘ │
│ │
│ PAR DOMAINE FONCTIONNEL : │
│ ┌──────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Grande Équipe│ ──→ │ Paiements │ │ Auth │ │
│ │ (12 pers.) │ │ Équipe (6) │ │ Équipe (6) │ │
│ └──────────────┘ └────────────┘ └────────────┘ │
│ │
│ GARDER : Personnes expérimentées sur chaque nouvelle équipe│
│ ÉVITER : Tous les seniors sur une équipe │
└─────────────────────────────────────────────────────────────┘
Impact de l'Onboarding
Courbe de Productivité
PRODUCTIVITÉ NOUVEAU HIRE :
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRODUCTIVITÉ AU FIL DU TEMPS : │
│ │
│ Productivité │
│ │ │
│ 100%├─────────────────────────────────────────────────█ │
│ │ ██████ │
│ 80%├──────────────────────────────────────█████ │
│ │ ████████ │
│ 60%├────────────────────────███████ │
│ │ ██████ │
│ 40%├─────────────█████ │
│ │ ████ │
│ 20%├─────████ │
│ │ ████ │
│ 0%├█──────────────────────────────────────────────→ Temps│
│ Mois 1 Mois 2 Mois 3 Mois 4 Mois 5 │
│ │
│ MONTÉE EN PUISSANCE TYPIQUE : │
│ Mois 1 : Apprentissage, setup, petites tâches (20%) │
│ Mois 2 : Contribue avec support (40%) │
│ Mois 3 : Travaille de façon autonome (60%) │
│ Mois 4 : Contribution presque pleine (80%) │
│ Mois 5+ : Pleine productivité (100%) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ IMPACT SUR L'ÉQUIPE : │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Lors de l'ajout d'un nouveau : ││
│ │ ││
│ │ MOIS 1-2 : ││
│ │ • Mentor passe 20% temps à aider ││
│ │ • Nouveau à 20-40% productivité ││
│ │ • NET : Légère baisse output équipe ││
│ │ ││
│ │ MOIS 3-4 : ││
│ │ • Moins de mentorat nécessaire (10%) ││
│ │ • Nouveau à 60-80% productivité ││
│ │ • NET : Équilibre ││
│ │ ││
│ │ MOIS 5+ : ││
│ │ • Nouveau contribue pleinement ││
│ │ • NET : ROI positif ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PLANIFIEZ POUR LA BAISSE avant d'attendre des gains │
└─────────────────────────────────────────────────────────────┘
Planification à Long Terme
Roadmap de Capacité
PLANIFICATION DE CAPACITÉ :
┌─────────────────────────────────────────────────────────────┐
│ │
│ ROADMAP DE CAPACITÉ : │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ T1 T2 T3 T4 ││
│ │ ── ── ── ── ││
│ │ ││
│ │ Équipe A 6 6 7 8 ││
│ │ (stable) (stable) (+1 dev) (+1 dev) ││
│ │ ││
│ │ Équipe B 5 6 6 6 ││
│ │ (stable) (+1 dev) (stable) (stable) ││
│ │ ││
│ │ Équipe C 0 0 4 5 ││
│ │ (nouvelle) (+1 dev) ││
│ │ ││
│ │ TOTAL 11 12 17 19 ││
│ │ ││
│ │ ─────────────────────────────────────────────────────── ││
│ │ ││
│ │ PLAN RECRUTEMENT : ││
│ │ T1 : 0 recrutements ││
│ │ T2 : 2 recrutements (Équipe A, Équipe B) ││
│ │ T3 : 5 recrutements (Équipe A, bootstrap Équipe C) ││
│ │ T4 : 2 recrutements (Équipe A, Équipe C) ││
│ │ ││
│ │ NOTES : ││
│ │ • Équipe C : Nouvelle initiative produit ││
│ │ • Commencer recrutement 2-3 mois avant besoin ││
│ │ • Tenir compte du taux de conversion entretiens ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ALIGNER AVEC : │
│ • Roadmap produit │
│ • Cycles budgétaires │
│ • Attrition attendue │
│ • Lacunes de compétences │
└─────────────────────────────────────────────────────────────┘
Gérer l'Attrition
PLANIFIER POUR LE TURNOVER :
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRÉVOIR L'ATTRITION : │
│ ───────────────────── │
│ Moyenne industrie : 10-20% turnover annuel │
│ Équipe de 10 : Prévoir 1-2 départs par an │
│ │
│ STRATÉGIES D'ATTÉNUATION : │
│ ────────────────────────── │
│ │
│ RÉDUIRE DÉPENDANCE PERSONNES CLÉS : │
│ • Documenter connaissances critiques │
│ • Formation croisée sur systèmes importants │
│ • Programmation en binôme diffuse les connaissances │
│ │
│ MAINTENIR PIPELINE DE RECRUTEMENT : │
│ • Toujours recruter (lentement) │
│ • Construire relations avec candidats │
│ • Réduire délai de recrutement quand nécessaire │
│ │
│ PLANIFIER À L'AVANCE : │
│ • Savoir que départ arrive (préavis) │
│ • Démarrer recherche remplacement immédiatement │
│ • Transfert de connaissances pendant le préavis │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PLANIFICATION DE SUCCESSION : │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RÔLES CRITIQUES ││
│ │ ││
│ │ RÔLE PRINCIPAL BACKUP RISQUE ││
│ │ ──── ───────── ────── ────── ││
│ │ Tech Lead @alex @jordan Bas ││
│ │ DBA @sam ❌ Haut ⚠️ ││
│ │ DevOps @pat @taylor Moyen ││
│ │ Product Owner @morgan @chris Bas ││
│ │ ││
│ │ ACTION : Former quelqu'un aux responsabilités DBA ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘