Call alle 10:30. Messaggio Slack alle 11:15. "Scusa, una domanda veloce" alle 11:45. Call di allineamento alle 14:00. Messaggio del cliente alle 15:20. Un'altra domanda alle 16:00. Il costo delle interruzioni per gli sviluppatori è enorme, ma quasi mai misurato.
Il tuo sviluppatore ha avuto 8 ore di giornata lavorativa. Di quelle 8 ore, quante sono state davvero di lavoro concentrato e continuo?
Questo non è un articolo sulla produttività personale. È un articolo sul costo economico delle interruzioni — un costo che non appare in nessun budget ma che spesso incide più di un’assunzione.
La ricerca: 23 minuti non sono un’opinione
Gloria Mark, ricercatrice all’Università della California Irvine, ha studiato per anni l’impatto delle interruzioni sul lavoro cognitivo complesso. Il risultato medio osservato: dopo un’interruzione servono circa 23 minuti per tornare al livello di concentrazione precedente (studio 2005, studio 2008).
Non perché serva tempo a “ripartire”, ma perché lo sviluppo software richiede di mantenere un modello mentale complesso: struttura del sistema, flusso del codice, dipendenze, stato del problema. Una notifica può interrompere questo equilibrio. Ricostruirlo richiede tempo.
Il conto economico che raramente si fa
Una “domanda veloce” di 3 minuti non costa 3 minuti. Costa circa 26 minuti: 3 di interruzione + 23 di recupero.
Una call di 30 minuti non costa 30 minuti. Ne costa più di 50.
Con 5 interruzioni al giorno — un numero realistico in molti team — il costo supera facilmente le 2 ore.
In una settimana sono circa 10 ore. In un mese, circa 40 ore: l’equivalente di una settimana di lavoro. In un team di 4 persone, è come perdere uno sviluppatore a tempo pieno, ogni mese, senza accorgersene. E aggiungere persone non risolve il problema se il modo di lavorare resta lo stesso.
Perché le interruzioni a metà mattina sono le peggiori
Molti sviluppatori iniziano a essere davvero produttivi solo dopo i primi 30–45 minuti della giornata, quando hanno ricostruito il contesto del lavoro lasciato il giorno prima.
Interrompere questo momento con una call o una richiesta urgente spezza proprio la fase di massima produttività. Non si perde solo il tempo della riunione, ma l’intera finestra di lavoro che la precedeva e quella che serve per rientrare nel flusso.
Tre regole operative che cambiano tutto
La prima regola è creare finestre di comunicazione. Call e riunioni andrebbero raggruppate in momenti precisi della giornata, come l’inizio, la fine della mattina, l’inizio del pomeriggio o la chiusura della giornata. Il punto è evitare il centro dei blocchi di lavoro. Se devi interrompere il flusso, fallo quando il flusso non è ancora iniziato o sta per finire.
La seconda regola è proteggere blocchi di lavoro veri, da due o tre ore consecutive senza interruzioni reali. Niente call, niente “domande veloci”, niente richieste sincrone. La differenza tra tre ore continue e tre ore spezzettate è enorme: spesso coincide con la differenza tra completare una feature o limitarsi ad avviarla.
La terza regola è usare la comunicazione asincrona come impostazione predefinita. La maggior parte delle richieste può aspettare qualche ora. Come urgenti andrebbero trattati solo i blocchi operativi reali o gli incidenti veri. Se puoi aspettare senza fermare il lavoro altrui, scrivi un messaggio e lascia che lo sviluppatore risponda quando esce dal flusso.
Segnali che il tuo team è troppo interrotto
I segnali sono abbastanza chiari: il lavoro vero si sposta la sera o nel weekend, le stime sembrano sempre sforare, tutti appaiono occupati tutto il giorno ma le feature avanzano poco, e gli sviluppatori migliori iniziano a mostrare frustrazione o burnout, proprio mentre trovarli è già abbastanza difficile. In questi casi il problema raramente è la capacità del team; molto più spesso è il tempo reale di concentrazione che gli viene lasciato.
Proteggi il deep work come proteggi il budget
Il tempo di concentrazione del team tecnico è una risorsa limitata e preziosa. Ogni riunione evitabile, ogni richiesta non urgente, ogni notifica superflua erode quella risorsa.
Le aziende che consegnano più velocemente non hanno necessariamente team più grandi o più talentuosi. Hanno team che riescono a lavorare in modo concentrato per più ore al giorno.
La differenza tra 2 ore di lavoro profondo e 5 ore di lavoro profondo al giorno cambia radicalmente la velocità di avanzamento di un progetto.
Simone Giusti
Consulente software strategico
