5 min lecture • Guide 707 of 877
La Connaissance se Perd Quand les Membres Partent
Les départs d'équipe ne devraient pas signifier des départs de connaissances. GitScrum aide à capturer les connaissances institutionnelles via des fonctionnalités de documentation, l'historique des tâches et les enregistrements de décisions qui préservent le contexte indépendamment de qui est dans l'équipe.
Évaluation des Risques de Connaissances
Types de Connaissances
CATÉGORIES DE CONNAISSANCES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONNAISSANCES EXPLICITES (Plus faciles à capturer): │
│ • Le code lui-même │
│ • Documentation écrite │
│ • Documentation des processus │
│ • Diagrammes d'architecture │
│ │
│ CONNAISSANCES TACITES (Plus difficiles à capturer): │
│ • Pourquoi les décisions ont été prises │
│ • Bizarreries systèmes et contournements │
│ • "Ne fais pas ça parce que..." │
│ • Contexte relationnel │
│ • Contexte historique │
│ │
│ CONNAISSANCES TRIBALES (Plus à risque): │
│ • "Demande à Sarah, elle sait" │
│ • Règles non écrites │
│ • Histoires de guerre sur les échecs passés │
│ • Raccourcis et astuces │
│ │
│ ZONES À HAUT RISQUE: │
│ ☐ Zones qu'une seule personne connaît │
│ ☐ Systèmes legacy complexes │
│ ☐ Intégrations personnalisées │
│ ☐ Systèmes de production critiques │
│ ☐ Relations stakeholders clés │
└─────────────────────────────────────────────────────────────┘
Audit des Connaissances
CARTOGRAPHIE DES CONNAISSANCES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ VÉRIFICATION CONCENTRATION CONNAISSANCES: │
│ │
│ Système/Zone │ Principal │ Backup │ Niveau Risque │
│───────────────────────┼───────────┼────────┼──────────────│
│ Intégration paiement │ Alex │ Marie │ 🟢 Faible │
│ Système facturation │ Jordan │ - │ 🔴 Critique │
│ Pipeline CI/CD │ Alex │ Jordan │ 🟢 Faible │
│ Outil import clients │ Marie │ - │ 🔴 Critique │
│ API principale │ Équipe │ Équipe │ 🟢 Faible │
│ │
│ VÉRIFICATION "BUS FACTOR": │
│ "Si cette personne se faisait renverser, ce serait grave?" │
│ │
│ • Bus factor = 1 → Risque critique (une personne sait) │
│ • Bus factor = 2 → Risque modéré │
│ • Bus factor = 3+ → Risque plus faible │
│ │
│ RISQUES IDENTIFIÉS: │
│ • Jordan est le seul à connaître facturation legacy │
│ • Marie possède tout le processus import clients │
│ │
│ PLAN D'ATTÉNUATION: │
│ • Jordan: Documenter et pairer avec un membre │
│ • Marie: Créer runbook et formation shadow │
└─────────────────────────────────────────────────────────────┘
Stratégies de Prévention
Documentation Continue
DOCUMENTER AU FUR ET À MESURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NE PAS: Attendre qu'un départ pour capturer les savoirs │
│ FAIRE: Capturer continuellement au fil du travail │
│ │
│ DOCUMENTATION PAR DÉCLENCHEUR: │
│ │
│ Quand ceci arrive... │ Créer/Mettre à jour ceci... │
│───────────────────────────┼───────────────────────────────│
│ Décision majeure prise │ Architecture Decision Record │
│ Incident production │ Post-mortem + Runbook │
│ Nouveau processus │ Documentation processus │
│ Intégration construite │ Guide d'intégration │
│ Feature complexe terminée │ Doc vue d'ensemble feature │
│ "Truc bizarre" découvert │ Document Gotchas/bizarreries │
│ │
│ INTÉGRÉ AU WORKFLOW: │
│ • Revue de code: "Y a-t-il une doc pour ça?" │
│ • Fin de sprint: "Quoi documenter?" │
│ • Résolution incident: "A-t-on mis à jour le runbook?" │
│ │
│ FAIBLE FRICTION: │
│ • Utiliser des templates │
│ • Accepter "assez bien" plutôt que parfait │
│ • Toute doc est mieux que pas de doc │
└─────────────────────────────────────────────────────────────┘
Formation Croisée
DISTRIBUTION DES CONNAISSANCES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ROTATION DE PAIRING: │
│ │
│ Sem 1: Jordan enseigne à Marie le système facturation │
│ Sem 2: Marie enseigne à Jordan l'outil import │
│ Sem 3: Alex enseigne à l'équipe intégration paiement │
│ │
│ OPTIONS DE FORMAT: │
│ │
│ Pairing (Meilleur pour connaissances tacites): │
│ • Travailler ensemble sur vraies tâches │
│ • Expliquer le processus de réflexion │
│ • Sessions de 2-4 heures │
│ │
│ Démo (Bon pour vue d'ensemble): │
│ • Montrer comment le système fonctionne │
│ • Répondre aux questions │
│ • Enregistrer pour référence future │
│ │
│ Revue Code (Bon pour contexte): │
│ • Inclure contexte dans descriptions PR │
│ • Expliquer pourquoi, pas juste quoi │
│ • Transfert de connaissances pendant revue │
│ │
│ OBJECTIF: Pas de point unique de défaillance │
└─────────────────────────────────────────────────────────────┘