Hai quel developer che sa tutto. Conosce ogni angolo del codice, ogni workaround, ogni decisione presa anni fa e mai documentata. Tutti lo cercano, tutti dipendono da lui. Sembra un vantaggio competitivo, ma spesso è uno dei rischi più grandi che l'azienda sta correndo. Il bus factor nello sviluppo software misura proprio questo: quanto il tuo prodotto dipende da una sola persona.
Cos'è il bus factor e perché è un problema aziendale
Il bus factor indica quante persone nel team, se non fossero più disponibili domani, metterebbero seriamente in difficoltà il progetto.
Se la risposta è “una”, il bus factor è 1.
Non serve immaginare scenari estremi. Basta una lettera di dimissioni, un burnout, un’offerta migliore. Quando il bus factor è molto basso, la conoscenza critica del prodotto vive nella testa di poche persone — a volte una sola.
È una metrica di rischio operativo.
Il costo reale che raramente si considera
Quando il developer chiave se ne va, sostituirlo è solo l'inizio del problema.
Primo: lo stop operativo.
Nessuno sa esattamente come funziona il deploy, perché quel job gira alle 3 di notte, dove sono certe configurazioni. Il team rallenta o si blocca.
Secondo: il reverse engineering del proprio prodotto.
Il nuovo sviluppatore deve capire un sistema complesso senza contesto. Ho visto team impiegare mesi solo per tornare al livello di comprensione che avevano prima.
Terzo: la tentazione della riscrittura.
Quando il codice è poco comprensibile, la soluzione più proposta diventa riscrivere tutto da zero. Che quasi sempre si rivela un errore costoso.
Quarto: dinamiche distorte nel team.
Quando una persona diventa indispensabile, ogni decisione passa da lei. Non per cattiva volontà, ma perché il sistema l’ha portata in quella posizione.
I segnali che il problema è già presente
Puoi capirlo senza analisi complesse. Chiediti:
- C’è sempre la stessa persona coinvolta quando qualcosa si rompe in produzione?
- Quando quella persona è in ferie, il team rallenta visibilmente?
- Ci sono parti del sistema che nessun altro ha mai toccato?
- Le code review sono poco incisive perché solo uno "capisce davvero"? (È anche il motivo per cui il software diventa fragile.)
- Le decisioni architetturali passano quasi sempre da una sola testa?
Se hai risposto sì a più di due domande, probabilmente il bus factor è molto basso.
È un effetto di come è organizzato il lavoro.
Come alzare il bus factor senza ingrandire il team
Serve distribuire la conoscenza — aggiungere sviluppatori cambia poco senza condivisione del sapere.
Pair programming mirato
Le parti critiche del sistema devono essere lavorate da almeno due persone. È il modo più rapido per trasferire conoscenza tacita, quella che non finisce nei documenti.
Code review fatte davvero
La review non è approvare una pull request. È assicurarsi che qualcun altro capisca cosa è stato fatto e perché. Se il reviewer non è in grado di spiegare la modifica, la review non ha funzionato.
Documentare le decisioni, non il codice
Non serve commentare ogni riga. Serve tracciare perché certe scelte sono state fatte. Gli ADR (Architecture Decision Records) sono uno strumento semplice ed efficace.
Rotazione sulle aree sensibili
Se un componente è sempre gestito dalla stessa persona, la prossima modifica la fa qualcun altro con il suo supporto. È più lento all’inizio, ma crea resilienza nel tempo.
Momenti regolari di knowledge sharing
Sessioni brevi e frequenti in cui qualcuno spiega come funziona una parte del sistema. Senza formalità, solo con il codice aperto e il racconto del contesto.
Il vero nodo è culturale
Molte aziende premiano chi risolve emergenze, non chi previene la dipendenza dalla singola persona.
Il developer che sistema un bug di notte è visto come un eroe. Quello che investe tempo nel condividere conoscenza sembra “meno produttivo”.
Questo incentivo porta naturalmente a un bus factor basso.
Se vuoi davvero ridurre il rischio, la condivisione di conoscenza deve diventare una priorità esplicita, non un’attività secondaria.
È questione di gestione del rischio
Gestire il bus factor significa trattare la conoscenza come un asset critico dell’azienda, esattamente come fai con i dati o con le infrastrutture.
Il miglior developer non è quello che sa tutto lui. È quello che fa in modo che il team possa andare avanti anche senza di lui.
Simone Giusti
Consulente software strategico
