Bus-faktoren: Hvor mange kan du tåle at miste?

Bus-faktoren er en simpel, men effektiv måde at tænke på eksekveringsrisiko i engineering-organisationer. Den refererer til antallet af personer, der pludselig skulle forsvinde, før et projekt går i stå, fordi det resterende team mangler viden eller evne til at fortsætte. Den forsvinden kunne skyldes nogen, der siger op, bliver ramt af en bus, tager langtidsorlov, eller bare bliver flyttet til en anden prioritet.

Det er en af de mest overså risici i en engineering-organisation, fordi den ikke dukker op i sprint-metrikker. Man opdager den først, når det er for sent. Og nej, dokumentation alene løser det ikke. Videndeling kræver aktivt pairing, rotation og fælles ejerskab.

Forstå risikoniveauerne

Bus-faktor på 1 (kritisk): Én person besidder al viden. Hvis vedkommende forlader teamet, stopper projektet. Det er dit auth-system, som kun Alice forstår, eller deployment-pipelinen, der kun kører i Bobs hoved.

Bus-faktor på 2 (skrøbelig): To personer deler den, men der er ringe eller ingen overlap. Hver ejer sin halvdel. Bedre end 1, men I er stadig én opsigelse fra, at nogen står helt alene med det.

Bus-faktor på 3 (håndterbar): Der er reelt overlap. En opsigelse gør ondt, men stopper ikke leverancen. Teamet kan absorbere tabet og komme sig inden for et sprint eller to.

Bus-faktor på 4+ (robust): Dyb viden. Teamet absorberer opsigelser uden at tabe tempoet. Det er der, du vil være for alt kritisk.

Kortlæg jeres videnfordeling

Tag jeres kritiske systemer og kortlæg, hvem der faktisk kender dem. Ikke hvem der har rørt ved dem én gang, men hvem der kunne fejlsøge et produktionsproblem klokken 3 om natten uden at ringe til nogen andre.

I vil sandsynligvis finde mønstre som dette: auth-systemet er helt Alice. API-gatewayen er mest Alice og Bob, med Charlie der har delvis viden. CI/CD-pipelinen er Bobs domæne. Data-pipelinen har god fordeling på tværs af tre personer.

Hullerne er åbenlyse, når man kortlægger det. Hvis Alice forlader teamet, mister I hele auth-systemet. Hvis Bob forlader teamet, mister I både API-gatewayen og CI/CD.

Måder at rette op på det

Pairing-rotation: Rotér par på tværs af domæner specifikt for at sprede viden, ikke for kodekvalitet. Hvis auth-systemet er helt Alice, sæt hende sammen med Bob i to uger. Sæt så Bob sammen med Charlie. Skab bevidst overlap.

Delt vagtplan: Hvis kun én person kan blive vækket for et system, har I en bus-faktor på 1 på det system. Udvid rotationen. Tving folk til at lære ved at sætte dem i situationer, hvor de skal finde ud af det selv.

Bredde i code review: Kræv reviews fra folk uden for domænet. Det er langsommere i dag, men bygger robusthed i morgen. Personen, der reviewer migrationen i dag, kan hjælpe med at fejlsøge den næste kvartal.

Architecture Decision Records: Dokumentér "hvorfor'et" bag beslutninger, ikke bare "hvad'et". Det er det, der er sværest at overføre. Når nogen spørger "hvorfor valgte vi denne tilgang?", bør svaret ikke kun ligge i ét hoved.

Kør auditen

For hvert kritisk system, tæl hvor mange personer der kunne fejlsøge et produktionsproblem klokken 3 om natten uden at ringe til nogen andre. Hvis svaret er 1 for noget som helst, er det jeres højest prioriterede videndelingsinvestering dette kvartal.

Vent ikke, til nogen siger op, med at opdage, at I har et problem.