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. All'inizio può sembrare un vantaggio, ma in realtà espone l'azienda a uno dei rischi organizzativi più seri. 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. In pratica misura quanto il sapere critico è concentrato su poche teste.
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. La prima conseguenza è lo stop operativo: nessuno sa esattamente come funziona il deploy, perché quel job gira alle 3 di notte o dove si trovano certe configurazioni, quindi il team rallenta o si blocca.
Subito dopo arriva il reverse engineering del proprio prodotto. Il nuovo sviluppatore deve capire un sistema complesso senza contesto, e ho visto team impiegare mesi solo per tornare al livello di comprensione che avevano prima.
Da lì nasce spesso anche la tentazione di riscrivere tutto da zero, che quasi sempre si rivela un errore costoso. Intanto si deformano anche le dinamiche interne: ogni decisione passa sempre dalla stessa persona, non per cattiva volontà, ma perché l'organizzazione l'ha resa il punto obbligato di ogni passaggio importante.
I segnali che il problema è già presente
Puoi capirlo senza analisi complesse. Se quando qualcosa si rompe in produzione viene sempre cercata la stessa persona, se durante le sue ferie il team rallenta visibilmente, se esistono parti del sistema che nessun altro ha mai toccato e se le code review sono poco incisive perché solo uno "capisce davvero", allora il problema è già presente. Lo stesso vale quando le decisioni architetturali passano quasi sempre da una sola testa. Se ti riconosci in più di uno di questi segnali, 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 se il sapere resta concentrato.
Pair programming mirato
Le parti critiche del sistema devono essere lavorate da almeno due persone. È il modo più rapido per trasferire la conoscenza tacita, quella che non finisce nei documenti e che spesso vale più di qualsiasi wiki.
Code review fatte davvero
La review serve ad assicurarsi che qualcun altro capisca cosa è stato fatto e perché. Se il reviewer non è in grado di spiegare la modifica, la review non ha ancora prodotto il suo effetto.
Documentare le decisioni, non il codice
La documentazione utile non commenta ogni riga di codice. Registra soprattutto perché sono state prese certe decisioni. Gli ADR, cioè brevi documenti che spiegano una decisione architetturale e le sue ragioni, funzionano bene proprio per questo.
Rotazione sulle aree sensibili
Se un componente è sempre gestito dalla stessa persona, la prossima modifica dovrebbe farla qualcun altro con il suo supporto. All'inizio si procede più lentamente, ma nel tempo si costruisce una base molto più solida.
Momenti regolari di knowledge sharing
Sessioni brevi e frequenti, con il codice aperto e il contesto raccontato a voce, aiutano a distribuire conoscenza in modo naturale. È il classico knowledge sharing, cioè la condivisione pratica di ciò che il team sa già. Non serve trasformarle in cerimonie: basta renderle regolari.
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
