Cosa fai per evitare che il team dipenda troppo da una sola persona?

Question

Accepted Answer

**Un basso bus factor è un rischio che gestisco deliberatamente, allo stesso modo in cui gestisco qualsiasi singolo punto di guasto.** Se solo una persona può fare il deploy, fare debug del servizio di pagamento o toccare il modulo legacy, il team è a una dimissione o a una vacanza da una crisi. L'obiettivo è diffondere la conoscenza senza rallentare tutti a passo di lumaca.

## Meccanismi pratici

- **Code review con intento.** Le review non sono solo controllo all'ingresso; sono trasferimento di conoscenza. Mi assicuro che nessuna area sia rivista solo da chi l'ha scritta.
- **Pairing e rotazione sui sistemi critici.** Assegno deliberatamente il lavoro nelle aree ad alto rischio a una seconda persona, anche quando l'esperto lo farebbe più velocemente. Costo a breve termine, assicurazione a lungo termine.
- **Documentazione che si guadagna il proprio posto.** Non wiki esaustive che nessuno legge, ma le cose portanti: runbook, decisioni architetturali, "come fare il deploy", "cosa fare quando X si rompe".
- **Rotazione on-call.** Nulla diffonde la conoscenza operativa più velocemente che ognuno facendo a turno il responsabile della produzione.
- **Talk interni / brown bag.** Il proprietario di un sottosistema complicato lo illustra al team.

## Come trovo il rischio

- Mappare l'ownership onestamente: per ogni sistema critico, chiedere "chi altro potrebbe gestirlo se X fosse via per due settimane?". Se la risposta è "nessuno", quello è un rischio segnalato.
- Fare attenzione al **pattern dell'eroe** — la persona che è sempre quella interpellata, sempre la risposta. È un segnale di allarme, non un punto di forza.

## Trappole

- **Accaparrarsi la conoscenza come sicurezza del posto.** Ad alcuni ingegneri (e ad alcuni manager) piace essere indispensabili. Lo riformulo: essere il collo di bottiglia blocca la tua stessa promozione e il tuo tempo libero.
- Sovracorreggere verso "tutti fanno tutto", il che distrugge la profondità. L'obiettivo è nessun singolo punto di guasto, non zero specializzazione.
- Scrivere i documenti una volta e lasciarli marcire; documenti obsoleti sono peggio di nessuno.

## Perché è importante

Ridurre il bus factor protegge la delivery contro malattie, vacanze e dimissioni, e libera le tue persone più forti perché crescano invece di restare intrappolate a manutenere la cosa che solo loro capiscono. Rende anche il team più sano: l'ownership condivisa batte gli eroismi fragili.