Nei due decenni passati, il concetto di produttività è evoluto e si è espanso in tutte le direzioni all’interno dell’ingegneria del software, spesso con risultati confusi o contraddittori. Durante i miei primi anni in questo campo, ero sotto l’impressione errata che più ore di lavoro, più righe di codice e più “attività” automaticamente significassero migliori risultati. Ma quella visione della produttività, dallo sviluppatore al team lead e poi al manager dell’ingegneria, sembrava funzionare contro gli stessi obiettivi che era supposta raggiungere, non solo danneggiando la qualità del codice, ma anche gravando sulla salute e il benessere degli sviluppatori.

In questo articolo, condividerò alcune delle idee sbagliate che ho incontrato e smentirò i miti più pervasivi sulla produttività nel settore tecnologico. Attingendo da storie personali, esperienze pratiche di team e osservazioni supportate dalla ricerca, argomenterò che la vera produttività ha meno a che fare con sprint frenetici e carichi di lavoro e più a che fare con un focus mirato, routine di lavoro salutari e una cultura organizzativa equilibrata. Spero che, combattendo queste illusioni, possiamo iniziare a pensare in modo nuovo alla gestione dei progetti software e al trattamento delle persone che li creano.

L’illusione del lavoro straordinario

Una delle prime illusioni di produttività che ho conosciuto è il fatto che lavorare per ore prolungate necessariamente porta a migliori risultati. Nei miei primi anni di lavoro, avevo preso in carico un grande aggiornamento del sistema di pagamento di un’organizzazione, con un tempo molto limitato. A causa di questa scadenza imminente, sentendomi spinto contro il muro, ho convinto il mio team a lavorare fino a tardi la notte e durante i fine settimana per quasi due mesi.

Ma poi le crepe hanno iniziato a comparire circa sei mesi dopo. Sottili bug, probabilmente introdotti durante le sessioni di codifica notturne del team, hanno iniziato a emergere in produzione. Questi problemi, quando risolti, hanno richiesto tempo e risorse aggiuntive, ma la fiducia del cliente era anche stata compromessa. Peggio ancora, questo eroico sforzo di lavoro straordinario era stato possibile solo perché due membri chiave del team si erano bruciati a causa dello stress e avevano lasciato il lavoro dopo aver citato il burnout e l’insoddisfazione per il lavoro. Quindi è diventato chiaro che il successo a breve termine nel rispettare la scadenza era stato a caro prezzo a lungo termine. Quindi, il mito che le ore garantiscano la produttività si è rivelato disastroso.

Qualità del tempo rispetto alla quantità del tempo

La creatività e la risoluzione dei problemi, due abilità cruciali richieste nell’ingegneria del software moderna, vengono fortemente limitate dalla stanchezza. Utilizzando strumenti di tracciamento del tempo come RescueTime e Toggl nel corso degli anni per studiare i modelli di lavoro dei miei team, ho ottenuto alcuni risultati interessanti: il nostro codice di alta qualità viene prodotto quando gli sviluppatori godono di blocchi regolari di 4-5 ore di concentrazione ininterrotta. Quando le persone spingono verso giornate di 10 o 12 ore, il tasso di errori spesso aumenta e il lavoro di riparazione può consumare anche più ore a ritroso. Adottando orari più misurati, abbiamo visto una diminuzione marcata dei bug, un aumento della soddisfazione del team e, in ultima analisi, tempi di consegna più prevedibili.

La fallacia del focus

Un altro mito radicato è che gli sviluppatori dovrebbero essere “connessi” e digitare ogni minuto per essere considerati produttivi. Questo malinteso può portare le aziende a implementare sistemi di monitoraggio dell’attività draconiani, ossessionati dai colpi di tastiera o dal tempo sullo schermo. Ho visto organizzazioni incoraggiare una cultura in cui apparire “online” per il massimo numero di ore possibile è considerato un segno di impegno. Questa percezione manca completamente di attività intangibili essenziali che fanno parte dello sviluppo del software, come la pianificazione, la discussione, la ricerca e la progettazione concettuale.

Breakthroughs lontano dalla tastiera

Una delle dimostrazioni più sorprendenti di ciò è arrivata l’anno scorso, quando il mio team era in mezzo a una battaglia accesa con un problema di architettura di microservizi. Per due settimane, abbiamo battuto fuori codice con frustrazione, cercando di debuggere una rete intricata di servizi. Infine, ci siamo ritirati nello spazio di pausa per una conversazione più informale. Sulla base di una discussione approfondita, abbiamo whiteboardato una soluzione che era radicalmente più semplice, tagliando via gran parte della complessità con cui stavamo lottando. Quei 30 minuti di conversazione ci hanno risparmiato ciò che sarebbero stati sicuramente mesi di refactoring doloroso. È stato un potente promemoria che la risoluzione efficace dei problemi spesso avviene ben al di fuori dei confini di un IDE.

Ripensare le metriche di produttività

Se “ore lavorate” e “attività costante” sono metriche difettose, cosa dovremmo tracciare invece? Le misure tradizionali di produttività nell’ingegneria del software si concentrano di solito su output superficiali: righe di codice, numero di commit o ticket chiusi. Mentre questi possono fornire alcuni insight di alto livello, sono soggetti a un uso improprio. Gli sviluppatori possono committare meno cambiamenti logici o possono optare per modi più verbosi per fare le cose con l’obiettivo di manipolare una misura euristica delle righe di codice. In generale, queste misure non sono molto efficaci nel tracciare i progressi dello sviluppo, poiché molte di queste misure sono contrarie alla minimizzazione dei problemi di manutenzione.

Un approccio più olistico

Per molti anni, i miei team e io abbiamo cercato di trovare misure significative di output che ci dessero la certezza che i nostri sforzi si traducessero in guadagni reali.

1. Tempo di mercato per nuove funzionalità
   Quanto velocemente possiamo consegnare una funzionalità che è realmente utile per gli utenti reali? Questo è un modo più affidabile per misurare il throughput rispetto ai cambiamenti di codice grezzo, poiché ci fa considerare se le funzionalità che consegniamo sono realmente utili.
2. Numero di incidenti di produzione
   Un basso tasso di incidenti implica una migliore qualità del codice, test più approfonditi e decisioni architettoniche più solide. Incidenti di produzione frequenti segnalano debito nascosto o scorciatoie nello sviluppo.
3. Punteggi di manutenibilità del codice
   Utilizziamo strumenti automatizzati come SonarQube per rilevare duplicazioni, complessità e vulnerabilità potenziali. Punteggi che sono stabili o migliorano nel tempo indicano un codice più sano, con una cultura rispettosa della qualità a lungo termine.
4. Condivisione delle conoscenze del team
   Invece di concentrarsi solo sull’output individuale, stiamo verificando quanto le conoscenze fluiscono intorno. Le coppie affrontano insieme i compiti, eseguono recensioni di codice approfondite e documentano le decisioni architettoniche importanti? Un team ben informato può affrontare i problemi in modo più collettivo.
5. Valutazioni della soddisfazione del cliente
   In ultima analisi, il software è per gli utenti. Feedback positivi, bassi volumi di ticket di supporto e forti tassi di adozione degli utenti possono essere indicatori eccellenti di vera produttività.

Concentrandoci su queste misure più ampie, non solo incoraggiamo decisioni migliori su come scrivere il codice, ma assicuriamo anche che le nostre priorità rimangano allineate con le esigenze degli utenti e le soluzioni mantenibili.

Il potere della pigrizia strategica

Un tempo pensavo che i grandi sviluppatori fossero quelli che avrebbero scritto migliaia e migliaia di righe di codice ogni giorno. Con il tempo, ho scoperto che può essere l’esatto opposto. In realtà, i migliori ingegneri praticano ciò che chiamo “pigrizia strategica”. Invece di immergersi in una soluzione elaborata che richiede molto tempo, impiegano il tempo per creare o trovare un’alternativa più elegante, che richiede meno codice, meno dipendenze e meno manutenzione futura.

Ricordo un progetto in cui uno sviluppatore junior ha trascorso tre giorni lavorando su uno script di elaborazione dei dati, che pesava quasi 500 righe di codice. Era solo goffo e ridondante, ma funzionava. Tornando a visitarlo più tardi quel pomeriggio, un lead developer del mio team è stato in grado di mostrare una soluzione compatta, di 50 righe, più pulita e probabilmente anche più performante.

Strumenti e tecniche per la vera produttività

Costruire un ambiente di vera produttività, piuttosto che semplice “lavoro impegnativo”, richiede sia la giusta strumentazione che la giusta mentalità organizzativa. Nel corso degli anni, ho sperimentato vari framework e ho scoperto alcune strategie affidabili:

1. Tecnica Pomodoro modificata
   I segmenti tradizionali di 25 minuti della tecnica Pomodoro possono sembrare troppo brevi per compiti di programmazione profonda. I miei team spesso utilizzano blocchi di focus di 45 minuti seguiti da pause di 15 minuti. Questo ritmo bilancia periodi prolungati di attenzione continua con il tempo necessario per riposare.
2. Ibrido Kanban/Scrum
   Combiniamo il flusso di lavoro visivo di Kanban con i cicli iterativi di Scrum. Utilizzando strumenti come Trello e Jira, limitiamo gli elementi WIP e pianifichiamo i compiti in sprint. Ciò previene il sovraccarico di cambio di contesto e ci mantiene concentrati sul completamento dei compiti prima di iniziare nuovi.
3. Tracciamento del tempo e analisi dei risultati
   La registrazione delle ore con strumenti come Toggl e RescueTime fornisce informazioni sui momenti più produttivi naturali di uno sviluppatore. Dotati di quelle informazioni, i compiti critici per ogni persona vengono pianificati nelle loro ore più produttive e non vengono confinati in rigide fasce orarie dalle 9 alle 17.
4. Recensioni di codice e programmazione in coppia
   Una cultura collaborativa tende a creare risultati migliori rispetto al comportamento eremitico. Ci scambiamo spesso recensioni di codice, ci accoppiamo di tanto in tanto, il che ci aiuta a individuare i problemi più presto, diffonde le conoscenze e mantiene la coerenza nella nostra base di codice.
5. Integrazione continua e testing
   I test automatizzati e le pipeline di integrazione continua proteggono contro check-in affrettati e approssimativi che possono rovinare l’intero progetto. I test configurati correttamente segnalano le regressioni in fretta e incoraggiano modifiche pensate e incrementali.

Costruire una cultura di ingegneria sana

Forse il mito più dannoso di tutti è che lo stress e la pressione automaticamente guidino a prestazioni più elevate. Alcuni leader sostengono ancora che gli sviluppatori eccellono sotto scadenze strette, sprint costanti e rilasci ad alto rischio. La mia esperienza è che, sebbene una scadenza stretta possa creare un breve periodo di sforzo, lo stress cronico alla fine porta a errori, burnout e problemi di morale che possono far regredire il progetto ancora di più.

Sicurezza psicologica e aspettative sostenibili

Ho visto risultati molto migliori dove la sicurezza psicologica è garantita e gli sviluppatori si sentono a loro agio nel sollevare preoccupazioni, offrire alternative e dichiarare errori precocemente. Promuoviamo questo tipo di cultura tenendo retrospezioni regolarmente, che non puntano il dito ma esplorano come i nostri processi possano essere migliorati. Stabiliamo anche aspettative realistiche in termini di ore di lavoro, permettendo ai membri del team di prendersi pause e andare in vacanza senza sensi di colpa. È controintuitivo, ma i team ben riposati e apprezzati scrivono costantemente codice di qualità superiore rispetto ai team che sono sotto costante pressione.

Giorni senza riunioni e blocchi di focus

Cosa che ha funzionato con uno dei miei team precedenti è stata l’introduzione dei “Mercoledì senza riunioni”. Gli sviluppatori trascorrevano l’intera giornata a codificare, ricercare o testare senza interruzioni. La produttività è decollata in quei mercoledì e tutti nel team amavano quel blocco di tempo tranquillo. Controbilanciavamo questo con una programmazione di riunioni essenziali negli altri giorni, mantenendole brevi e concise in modo da non accumulare discussioni prolungate.

Lezioni da casi di studio nel mondo reale

Ci sono molti esempi nel settore tecnologico più ampio che illustrano come l’adozione di un modello equilibrato e centrato sulla qualità porti a prodotti migliori. Aziende come Basecamp (in precedenza 37signals) hanno parlato pubblicamente del concetto di lavoro calmo e focalizzato. Limitando le ore di lavoro e scoraggiando il lavoro straordinario, hanno rilasciato prodotti stabili e pensati come Basecamp e HEY con un design attento. A differenza delle startup ad alta pressione, che iterano in fretta rilasciando funzionalità difettose e bruciando la buona volontà degli sviluppatori al loro seguito.

Ho visto un team che lo ha realmente preso a cuore. Ha riorganizzato tutti gli orari intorno a loro, inserendo pause e imponendo un limite rigido di ore. In un trimestre, i punteggi di soddisfazione degli sviluppatori sono saltati, ma ancora meglio, i biglietti di supporto in entrata sono diminuiti di diversi ordini di grandezza.

Ripensare il significato di “produttività”

Alla fine, le mie esperienze mi hanno portato a definire la produttività nell’ingegneria del software come: consegnare valore sostenibile agli utenti finali mantenendo un ambiente salutare per il team di sviluppo. È molto facile essere ingannati da output pseudo, come backlog di sprint completamente riempiti o una lunga lista di messaggi di commit. Ma al di là del superficiale, un codice solido e mantenibile richiede chiarezza mentale, collaborazione costante e pianificazione pensata.

Un’equazione equilibrata

La formula per il successo sostenibile bilancia obiettivi chiari, la giusta strumentazione e una cultura di supporto che si prenda cura sia del benessere dello sviluppatore che delle esigenze dell’utente finale. Possiamo inquadrare questa visione con tre principi guida:

1. Lavoro efficace rispetto al lavoro prolungato: ciò che conta veramente è ciò che viene consegnato, non quante ore il team ha trascorso davanti a uno schermo.
2. Metriche orientate al valore: monitoriamo metriche relative ai risultati, come la manutenibilità, i tassi di difetti o la soddisfazione degli utenti.
3. Miglioramento continuo culturale: la vera produttività deriva da miglioramenti incrementali nel modo in cui il lavoro fluisce, i team collaborano e il codice viene scritto. Retrospezioni, pianificazione flessibile, condivisione delle conoscenze: è questo che rende possibile un ritmo sostenibile nel tempo.

Conclusione

La vera produttività nell’ingegneria del software non consiste nel cercare di stipare più ore in ogni giorno o scrivere righe di codice a centinaia per impressionare un manager. Significa invece creare soluzioni robuste, ben testate che abbiano un valore reale per gli utenti e resistano alla prova del tempo. È tempo di mettere in discussione questi miti e ridefinire cosa significa produttività per il nostro settore.

Il viaggio personale mi ha insegnato che “ore lavorate” o “ticket chiusi” – tali misure possono essere ingannevoli. La produttività reale deriva da team energici, che scrivono codice responsabile e funzionalità allineate con le esigenze reali degli utenti. Ciò richiede un approccio olistico: pianificazione pensata, metriche significative, pigrizia strategica e una forte cultura di ingegneria che valorizza chiarezza, collaborazione e creatività. Se rimaniamo aperti all’indagine di nuovi metodi, scartando assunti che hanno superato il loro tempo, possiamo costruire un’industria tecnologica in cui la produttività favorisca non solo un miglior software.