Il progetto è in ritardo. La deadline si avvicina. Il cliente preme. La reazione istintiva è spesso la stessa: aggiungere sviluppatori al progetto. Sembra logica elementare — più persone, più velocità. Nel software, però, l'effetto è spesso diverso da quello atteso.
Frederick Brooks lo descrisse già nel 1975 in The Mythical Man-Month, un testo ancora molto citato nell'ingegneria del software. A distanza di decenni, il problema che descriveva è ancora attuale.
Il mito del mese-uomo
Il ragionamento sembra semplice: se uno sviluppatore completa un progetto in 12 mesi, dodici sviluppatori lo completeranno in un mese.
Questa logica funziona quando le attività sono completamente indipendenti e non richiedono coordinamento. Nel software, questa condizione è rara. Il codice ha dipendenze, i moduli si intrecciano e le decisioni di uno sviluppatore influenzano il lavoro degli altri.
Ogni persona aggiunta al team deve comprendere il contesto, coordinarsi con gli altri e allinearsi alle scelte fatte in precedenza.
Perché aggiungere persone può rallentare
La comunicazione cresce rapidamente
Se hai 3 sviluppatori, i canali di comunicazione sono pochi. Con 6 aumentano in modo significativo. Con 10 o più, il tempo speso in allineamenti e coordinamento diventa una parte rilevante della giornata.
Ogni persona aggiunta non porta solo capacità produttiva, ma aumenta la necessità di sincronizzazione: riunioni, messaggi, code review, chiarimenti.
L'onboarding ha un costo
Uno sviluppatore nuovo non è produttivo dal primo giorno. Deve comprendere il codebase, le convenzioni, l'architettura e le motivazioni dietro molte scelte.
Questo richiede tempo sia a lui sia al team esistente. Nelle prime settimane, il contributo netto può essere molto limitato.
La conoscenza implicita non si trasferisce facilmente
In molti progetti, una parte importante delle decisioni non è documentata, ma vive nell'esperienza del team. È il classico problema del bus factor: se chi sa come funziona il sistema non è disponibile, i nuovi non hanno modo di colmare il gap velocemente.
Uno scenario tipico
Un team di 4 sviluppatori lavora a un prodotto. Il cliente chiede di anticipare la consegna e il team viene ampliato a 10 persone.
Nelle prime settimane, i membri più esperti dedicano molto tempo all'onboarding. Successivamente, aumentano le necessità di coordinamento, le code review si allungano e il flusso di lavoro diventa più complesso.
Il beneficio in termini di velocità può arrivare solo dopo mesi, quando ormai il vantaggio temporale inizialmente cercato si è ridotto.
Le cause reali dei ritardi
Quando un progetto è in ritardo, raramente la causa è semplicemente il numero di persone. Più spesso si tratta di:
- Requisiti che cambiano nel tempo
- Stime iniziali poco realistiche
- Debito tecnico che rallenta lo sviluppo
- Colli di bottiglia architetturali
Aggiungere persone non risolve direttamente nessuno di questi problemi.
Cosa fare invece
Ridurre lo scope
Se la deadline non si può spostare, è spesso più efficace rivedere il perimetro delle funzionalità necessarie al rilascio.
Rimuovere gli ostacoli
Chiedere al team cosa rallenta il lavoro porta spesso a soluzioni più efficaci dell'aumento del personale: pipeline lente, ambienti instabili, code review bloccate.
Ridurre le interruzioni
Meeting frequenti, cambi di priorità e richieste urgenti riducono significativamente la produttività del team.
Aggiungere persone in modo mirato
Se è necessario ampliare il team, è più efficace farlo su attività ben isolate e con competenze specifiche, in modo da limitare l'impatto sul resto del gruppo.
La lezione di Brooks, oggi
La frase di Brooks — "Adding manpower to a late software project makes it later" — resta valida come principio generale.
In molti casi, un team piccolo, ben coordinato e con poche interruzioni riesce a mantenere una velocità più costante rispetto a un team numeroso che passa gran parte del tempo a coordinarsi.
La domanda utile, quando un progetto è in ritardo, non è "quante persone servono in più?", ma "cosa sta rallentando il team attuale?".
Simone Giusti
Consulente software strategico
