In un articolo precedente ho spiegato perché il bus factor è una delle metriche di rischio più ignorate nello sviluppo software. Questo articolo parte da lì, ma va un passo oltre: non tanto perché il bus factor conta — quello ormai dovrebbe essere chiaro — ma come si misura davvero. Perché il numero che quasi tutti hanno in testa è quasi sempre falso.
Il motivo è semplice. Quando un team guarda sé stesso da dentro, tende a sovrastimare quanto la conoscenza sia distribuita. Quattro sviluppatori che lavorano sullo stesso progetto sembrano un bus factor di quattro. Sulla carta è rassicurante. Nella pratica, spesso è uno.
Il bus factor che racconti e quello che hai davvero
Il bus factor apparente è facile da raccontare. Si calcola così: quante persone lavorano sul progetto? Quante sanno aprire il repository, fare una modifica, chiudere un bug, scrivere una feature? Se la risposta è “quattro”, allora ci si convince che il rischio sia basso.
Il bus factor reale è un’altra cosa. La domanda giusta non è “quante persone sanno contribuire?”, ma quante persone possono tenere in piedi il progetto da sole quando succede qualcosa di non previsto? Non eseguire task già definiti, non fare il compitino assegnato, non portare avanti il lavoro finché tutto fila liscio. Sto parlando di decidere: che trade-off fare, dove mettere mano, cosa sacrificare, come spiegare la scelta allo stakeholder, come tenere insieme il tutto quando il progetto si piega sotto un problema vero. Lì il numero si abbassa brutalmente.
Nella maggior parte dei team c’è una persona che tiene in testa il sistema intero. Le altre conoscono bene le parti su cui lavorano, abbastanza quelle adiacenti, poco o nulla il resto. Finché il lavoro è ordinario, sembra che tutto funzioni. Quando arriva l’imprevisto, tutti tornano da quella persona.
Quella persona è il tuo bus factor reale.
Il test che non perdona
Il modo migliore per capire se ti stai raccontando una favola è molto semplice: sparisci per una settimana. Non ferie vere, non “scrivimi se succede qualcosa di grave”. Proprio una settimana in cui, su quel progetto, tu non ci sei, e le decisioni vanno prese senza di te.
Il punto non è se qualcuno ti cerca — quello succederà comunque. Il punto è un altro: al tuo ritorno trovi decisioni già prese oppure una pila di cose lasciate in sospeso perché “dovevi vederle tu”?
Se trovi la seconda, il tuo bus factor è 1.
Anche se il team è di cinque persone.
Anche se tutti sono bravi.
Anche se il progetto “va bene”.
Questo è il test che separa la ridondanza reale dalla semplice sensazione di avere una squadra.
Il bug notturno è sempre più sincero dei processi
C’è un altro momento in cui il bus factor smette di mentire: il problema notturno. Se alle due di notte succede qualcosa in produzione, quante persone possono davvero diagnosticare il problema e risolverlo? Non alzare il telefono e farsi guidare, non “tamponare finché domani si vede”. Risolverlo.
È lì che capisci quanta conoscenza del sistema è superficiale e quanta invece è strutturale. Molti team scoprono in quel momento che il loro progetto è, di fatto, una monarchia tecnica travestita da organizzazione distribuita.
Il sintomo più sottovalutato: l’onboarding
C’è poi un test ancora più subdolo, perché non ha il pathos del bug in produzione ma dice la verità con la stessa precisione: il tempo che serve a una persona senior per diventare operativa.
Se domani entra qualcuno molto bravo, quanto ci mette a muoversi sul progetto senza appoggiarsi continuamente alla stessa persona? Se la risposta vera è “mesi”, allora la conoscenza è ancora quasi tutta in una testa sola. Se invece in due settimane riesce a orientarsi leggendo, facendo qualche domanda e prendendo mano ai moduli giusti, vuol dire che una parte della conoscenza è stata esternalizzata. Ed è lì che entra in gioco la documentazione fatta bene.
La documentazione aiuta. Quella finta no.
Qui serve una distinzione brutale. La documentazione non alza il bus factor solo perché esiste una wiki: quella roba, nella maggior parte dei casi, serve solo a far sentire il team più ordinato di quanto sia davvero. La documentazione utile è quella che permette a qualcuno di entrare, capire e fare, non quella che spiega genericamente il sistema con belle parole e diagrammi dimenticati da sei mesi.
Il principio giusto è semplice: una documentazione sana separa le cose per quello che sono. C’è la parte che ti aiuta a capire il perché, quella che ti dice come fare una cosa specifica, quella che ti serve da riferimento quando cerchi un dettaglio preciso. Mischiare tutto nello stesso documento produce solo confusione.
Il nome del framework conta relativamente. Il punto vero è un altro: la conoscenza deve uscire dalle teste e finire in artefatti che qualcuno può usare davvero.
Il problema è che la documentazione decade. Sempre. Oggi è corretta, tra diciotto mesi no. E decade nel modo peggiore: in silenzio. Nessuno se ne accorge finché qualcuno prova a seguirla e si schianta.
Per questo la documentazione non va trattata come un progetto a parte da fare “quando c’è tempo”. Va trattata come parte del lavoro normale. Se cambi il sistema e non aggiorni la documentazione che serve a capirlo, stai solo spostando il problema in avanti.
Perché il bus factor resta basso anche nei team forti
Questo è il punto che confonde più persone. Puoi avere un team bravo, serio, capace, e avere comunque un bus factor reale di 1. Perché contribuire bene non significa poter sostituire davvero: sono due cose diverse.
Un team funziona quando ognuno sa fare bene il proprio pezzo. Il bus factor sale quando almeno un’altra persona sa fare anche il tuo. E questo richiede un investimento esplicito, che spesso non si fa perché sembra inefficiente: in apparenza è uno spreco, stai chiedendo a qualcuno di imparare cose che già un altro sa fare. In realtà è esattamente il contrario. Stai pagando ridondanza oggi per non trovarti paralizzato domani.
Il problema è che questo investimento andrebbe fatto proprio dalla persona più sovraccarica del sistema. E quella persona, quasi sempre, non ha tempo. È lo stesso meccanismo che ho raccontato in Quando una persona copre troppi ruoli, l’organizzazione è fragile: il sistema dipende da qualcuno proprio perché quel qualcuno non ha mai avuto il margine per costruire un’alternativa.
Costruire un secondo non significa passare task
Qui c’è l’errore più comune. Molti pensano che costruire un secondo significhi iniziare a distribuire lavoro. Non basta: passare task produce supporto operativo, non ridondanza reale.
Se vuoi costruire un secondo, devi dare a qualcuno un pezzo intero di sistema. Un’area con responsabilità vera. Qualcosa su cui quella persona debba decidere, sbagliare, capire, difendere scelte e portarne il peso. Se continui a dare compiti singoli, il modello mentale resta nel tuo cervello: l’altra persona impara a eseguire, non a sostituire.
Poi c’è il passaggio più difficile: smettere di correggere tutto. All’inizio la review serve. Poi arriva un punto in cui tu continui a rivedere tutto solo per rassicurarti, e lì la review smette di essere uno strumento di qualità e diventa una tassa sulla crescita dell’altro. Il momento in cui capisci che stai facendo sul serio è questo: l’altra persona prende una decisione diversa da quella che avresti preso tu, ma ragionevole. Se la tua reazione è correggerla comunque, non stai costruendo un secondo. Stai costruendo una copia minore di te.
Da 1 a 2 cambia quasi tutto
Non serve inseguire la perfezione. Non serve un bus factor di 5 ovunque. Nella maggior parte dei casi, la vera soglia è passare da 1 a 2 sulle parti critiche.
Con una sola persona, l’indisponibilità è un rischio costante. Con due, la resilienza cambia drasticamente. Non in modo lineare: proprio di ordine di grandezza.
È qui che molte aziende sbagliano. Vedono la costruzione del “secondo” come un lusso organizzativo. In realtà è una forma di assicurazione. Costa prima, salva dopo.
Il punto di partenza, se il tuo bus factor è 1
Se leggendo questo articolo ti sei reso conto che il tuo progetto gira davvero intorno a una sola persona, non serve fare teorie. Serve iniziare da qualcosa di estremamente concreto.
Scegli una persona specifica. Non “il team”, non “nei prossimi mesi distribuiremo meglio la conoscenza”. Una persona con nome e cognome. Dagli un’area precisa. Lasciale prendere decisioni. Lasciale sbagliare in modo controllato. Costringiti a non intervenire su tutto. Poi pianifica la settimana in cui non ci sarai.
Perché finché non fai quel test, puoi raccontarti quello che vuoi. Il bus factor, come la sicurezza o il debito tecnico, sembra sotto controllo finché non lo metti davvero alla prova. E quando cede, di solito cede tutto insieme.
Simone Giusti
Consulente software strategico
