Qualità, orari, produttività
Non ci prendiamo in giro: tutti parliamo di qualità e l’abbiamo come obiettivo, ma tutti sappiamo anche come sia necessario “fare quantità”.
Un burn-down chart, ad esempio, ci racconta una storia di “quantità”: ci dice quanto stiamo procedendo, quanto rimane da fare, quanto tempo abbiamo a disposizione e, con qualche calcolo, quanto tempo più o meno ci vorrà per finire le cose. Esso misura la “produttività” del gruppo, almeno per quanto riguarda la velocity di sviluppo. Eppure, nei corsi Scrum e nei “testi sacri” della materia, si sottolinea sempre come il progresso nel lavoro debba essere svolto a un ritmo sostenibile.
C’è insomma, la chiara consapevolezza che, per quanto importante, la quantità equivale alla produttività solo fino a un certo punto. Se gli orari divengono eccessivi, se il ritmo a cui si procede aumenta vorticosamente, si ottiene proprio il contrario di quello che ci si attenderebbe, vale a dire una diminuzione della produttività? Perché? È quello che cercheremo di vedere in questo articolo, partendo con un epidosio accaduto realmente qualche tempo fa.
Pavese vs. Fast food
Recentemente ho avuto a che fare con un’azienda di medie dimensioni che opera in un ambito non informatico — vale a dire che non produce software come core business ma “vende” tutt’altro tipo di servizi — la quale ha un piccolo reparto IT che si occupa dell’infrastruttura informatica cruciale su cui si basa il lavoro di tutta la baracca…
Uno dei responsabili del settore IT, che si chiama Fabio, mi ha colpito per un comportamento che lo contraddistingueva dai suoi colleghi. Quasi tutti i giorni, tranne nei rari casi in cui si sono manifestati seri problemi imprevisti, si concedeva una lunga pausa pranzo, trascorsa per lo più seduto comodamente a tavola in una delle osterie/trattorie della cittadina di provincia in cui ha sede l’azienda. A volte era in compagnia di colleghi, a volte da solo, ma tendeva a non rinunciare mai a questo “rito” del pranzo. Sebbene brillasse per serietà e affidabilità, sembrava non avere alcun imbarazzo a concedersi qualche ulteriore minuto di pausa prima e dopo il pranzo rispetto ai suoi colleghi e ai suoi “capi”.
Molti altri, invece, preferivano impiegare la pausa pranzo per un rapido spuntino, anche rimanendo in ufficio, e tornavano immediatamente a rituffarsi nelle attività.
Dal momento che anche questo tipo di aspetti organizzativi, seppur marginalmente, avevano a che fare con il mio lavoro di consulenza in quella azienda, alla mia domanda molto divertita del perché la pausa pranzo dovesse essere così “santificata”, il personaggio in questione ha risposto ridacchiando: “Eh, vedi… Lavorare stanca. E questa pausa a tavola mi rigenera. Non lo posso fare in ufficio, ma se potessi… farei anche una breve dormita”. In un’altra occasione, parlando con un collega, Fabio ha ripetuto la stessa frase: “Lavorare stanca!”. Ho scoperto poi che non si trattava solo di una frase fatta, ma che per lui la raccolta di poesie di Cesare Pavese intitolata appunto Lavorare stanca era stata un po’ uno dei libri di riferimento nella sua formazione culturale e personale [1].
Ozio re dei vizi?
Come spesso accade, un episodio apparentemente marginale come questo ha poi finito per incontrarsi con una serie di altre considerazioni trovate nel corso delle “peregrinazioni” tra libri e web per cercare informazioni. Mi sono infatti imbattuto in un articolo che era proprio un elogio del “lavorare meno” [2] ma non con un approccio “fricchettone” e libertario, quanto con una serie di motivazioni “scientifiche” alla base, che sembrerebbero mettere in relazione eccesso di lavoro e decadimento della produttività.
Ora, e qui torno con una delle mie convinzioni, è vero che dagli USA ci vengono un sacco di spunti e di innovazioni, ma è anche vero che tante riflessioni di questo tipo le avremmo già “in casa”. Solo che magari non sono scritte nel best seller pubblicato in America negli ultimi due anni, ma in qualche classico filosofico che sembra inopportuno citare in ambito di sviluppo software e gestione di progetto IT [3].
Battute a parte, nel mondo greco e latino si dava grande importanza all’ozio inteso come tempo non dedicato al lavoro ma alla riflessione, al pensiero, allo studio che avrebbero permesso al cittadino libero di migliorare la qualità delle proprie attività. È chiaro che stiamo parlando di società completamente diverse dalle nostre, in cui il lavoro manuale pesante veniva svolto da masse di poveracci e schiavi che non si potevano certo permettere di passare parte del loro tempo a studiare e riflettere… però è interessante notare come esistesse fin da tempi antichi la consapevolezza che la produttività non sia solo spingere al massimo.
Il tempo dedicato alla riflessione e allo studio, questo sì magari in perfetta solitudine, non è tempo perso. Staccare, smettere di fissarsi su qualcosa, aprirsi a esperienze apparentemente lontane da ciò su cui si sta lavorando può risultare in un inaspettato miglioramento delle prestazioni. Spesso le soluzioni arrivano proprio quando non le stiamo cercando.
Tutta colpa di Taylor e Ford!
Di fatto, lavorare meno può essere una chiave per aumentare la produttività, a patto che si tratti di lavorare meglio. Ci portiamo dietro un’eredità di organizzazione aziendale, che è quella del modello della fabbrica fordista, per cui più si lavora, più si produce. Ma i tempi — e i mercati, e i prodotti — sono cambiati.
Eppure, anche nella fabbrica fordista della prima metà del Novecento, quella in cui l’alienazione degli operai è rappresentata tanto bene nel film Tempi moderni di Charles Chaplin (1936), il problema dell’eccesso di lavoro era ben presente. Anche se adesso usiamo sempre questo modello per indicare il modo insostenibile in cui non si deve lavorare se si desidera migliorare la produttività, ci dimentichiamo che fu proprio la fabbrica fordista a mettere a punto un sistema di lavoro basato sulle 40 ore settimanali: 8 ore al giorno per 5 giorni alla settimana.
Questo, per i tempi, rappresentava in effetti un processo di riduzione dell’orario di lavoro, che era in genere orientato a una settimana lavorativa di 6 giorni con 10 ore quotidiane, anche se magari a ritmi ben più blandi… Ford e i suoi ingegneri si resero conto che, alla lunga, lavorare troppo finiva per avere un impatto negativo sulla produttività. E se lo avevano capito loro…
Oggigiorno sono sempre più numerosi gli studi che valutano l’effetto della stanchezza (troppe ore di lavoro, mancanza di pause, mancanza di sonno) sulla produttività. I risultati forniti dalle neuroscienze [4] non esitano a definire gli effetti derivanti dalla mancanza di sonno simili a quelli dell’ubriachezza da alcool. Lavoreremmo volentieri in un ambiente di ubriachi? OK, sento già qualcuno che urla “salute!” o “prosit!”… E quindi riformulo la domanda, più seriamente: riterreste produttivo un ambiente in cui le persone fossero rintontite dall’alcool, anche se lavorassero molte ore?
La stanchezza abbatte la creatività
Uno degli aspetti spesso sottovalutati nei gruppi di lavoro tecnici è la creatività. Anche in professioni legate al mondo dell’ingegneria e dello sviluppo del software, infatti, la creatività è una componente importante per la riuscita nei progetti: trovare modi nuovi per fare le cose, vedere i problemi da angolazioni inusuali, proporre soluzioni apparentemente controintuitive sono capacità che hanno a che fare con la creatività.
Ebbene, l’esaurimento da stanchezza, il cosiddetto burnout [5], ha un impatto negativo proprio su aspetti quali la creatività, la capacità (o la voglia) di comunicare e confontarsi, l’energia che si mette nel progetto: tutti elementi poco misurabili in termini assoluti, ma la cui importante criticità è ormai chiara a chiunque abbia un minimo di esperienza e di onestà intellettuale.
I gruppi di lavoro “rilassati” — che non significa “fannulloni” — sono proprio quelli in cui, nel momento della difficoltà, possono emergere soluzioni, incoraggiamento, proposte. I gruppi stressati sono quelli in cui, nel momento della difficoltà, le persone si chiudono a riccio solitariamente invece di legarsi insieme per trovare soluzioni e raggiungere gli obiettivi.
Ricercare le condizioni migliori
Affinché le persone nei gruppi di lavoro diano il meglio di sé in modo sostenibile, e aumentino quindi la produttività, è necessario creare delle condizioni ottimali in cui ci si possa muovere. In questo senso assume molta importanza studiare certe statistiche, conoscere certi pattern comportamentali tipici, riconoscere l’importanza delle condizioni culturali in cui si opera e adeguare le metodologie alla realtà.
Se, per esempio, sappiamo che in certe aree geografiche e culturali del pianeta, determinate ore o determinati periodi sono meno produttivi, concentriamo le attività nei momenti più produttivi. Un esempio? Ci sono momenti della giornata in cui, mediamente, l’attenzione e la capacità elaborativa delle persone è ridotta [6]; si tratta, come è facile intuire, delle prime ore del pomeriggio, fino a circa le 16:00. Ecco, ai fini del miglioramento della produttività, è meglio non concentrare in quelle ore attività che richiedano grande attenzione o impegno: un’ora “persa” in quel periodo è sicuramente meno impattante sulla produttività di quello che potrebbe sembrare, specie in attività ad alto grado di componente creativa, mentale o di attenzione.
Ridurre le cose da fare
Quella della selezione, valutazione e riduzione delle cose da fare è una litania ormai ripetuta all’infinito. Il processo di individuazione, peso, raffinazione e messa in lavorazione delle storie utente che si fa in Scrum è una “istituzionalizzazione” di questo concetto: fare poche cose, farne una per volta, finire la cosa che si sta facendo prima di cominciare a farne un’altra, per evitare di ingolfare il flusso.
Però… e qui viene il problema, come si fa a fare meno se le pressioni dall’alto non vanno in quel senso? È difficile, ma occorre imparare a dire dei no. Dei no motivati da dati, riflessioni, esempi considerazioni. Dei no che non siano un infantile diniego, ma appaiano più come una presa di coscienza delle priorità.
A una futura sposa che dica alle sue amiche “Mi spiace, ma non posso venire con voi al cinema oggi pomeriggio perché devo andare a provare l’abito nuziale”, nessuna si sognerebbe di opporre delle critiche: tutte comprendono che andare a provare il vestito è una attività importante, che deve essere svolta in quei tempi e che impedisce di fare altro. Così dovrebbe — che è un verbo al condizionale — essere anche nei gruppi di lavoro: se c’è franchezza, se c’è motivazione, se non c’è un atteggiamento da “fannullone”, se c’è una produttività riscontrabile, questi “no” diventeranno un ulteriore motivo di miglioramento della produttività. Lavorare meno, fare meno cose, ma portarle a pieno compimento.
Delegare, collaborare, aiutare e lasciarsi aiutare
Altro concetto ribadito più volte e da più parti: l’eroe solitario, il personaggio capace da solo di fare tutto va bene per i film… ma meno per le reali esigenze della vita aziendale.
Delegare è inevitabile: il tempo a disposizione non consente di fare tutto da soli, anche se si fosse capaci di farlo. Delegare, però significa anche due cose: aprire agli altri la conoscenza di ciò che si sta facendo ed essere disposti ad accettare che le cose siano fatte anche nel modo in cui noi non lo faremmo… E queste, in certi ambienti ipercompetitivi sono eresie, anche se poi ciò impatta negativamente sulla reale produttività.
Collaborare non significa solamente fare le cose insieme, ma anche condividere l’esperienza e la conoscenza che si possiede. È chiaro che ci sarà sempre chi sa fare meglio qualcosa, ma la situazione più produttiva è rappresentata da team in cui tutti possono fare (quasi) tutto. Non c’è uno specialista esclusivo per ciascuna area (analisi, studio del dominio, codifica etc.) ma tutti sanno fare un po’ di tutto. Il team crossfunzionale è più solido e produttivo perché, nel caso per qualsiasi ragione venga temporaneamente a mancare un elemento, certi processi non si bloccano, a differenza di quello che accade nelle organizzazioni rigide tradizionali:
“Guardi oggi manca la persona che fa i certificati di esistenza in vita. Mi spiace ma bisogna che torni domani…”
“Non lo può fare lei?”
“Eh, no… è una operazione un po’ particolare, la può fare solo l’addetto specifico”…
La conoscenza collaborativa è una delle chiavi per la produttività: maggiore è lo scambio di informazioni e conoscenze, migliore è la comunicazione, minori saranno gli intoppi, gli sprechi (in senso Lean), maggiore sarà la sostituibilità del particolare “addetto” che dovesse venire a mancare temporaneamente. Del resto, basta pensare a una squadra sportiva: fermo restando che ognuno gioca meglio in un determinato ruolo e che le specificità vanno coltivate, certi giocatori finiscono per risultare estremamente preziosi per gli allenatori e per i loro compagni proprio per la loro duttilità tattica e la capacità di ricoprire più ruoli all’interno della squadra. Il punto di arrivo sarebbe quello di avere personale in grado di giocare in più ruoli all’occorrenza, senza chiaramente arrivare ai tuttologi che poi possono risultare dei nientologi…
Infine: aiutare e farsi aiutare. Per alcune persone, la sola consapevolezza di avere qualcuno “accanto” capace di fornire aiuto se serve è in grado di migliorare nettamente la produttività. Sarà suggestione, ma ci sono studi a tal proposito, ad esempio quelli raccolti nel libro Friendfluence [7].
Automatizzare i compiti ripetitivi
Si dice che il filosofo tedesco Immanuel Kant fosse uomo di abitudini molto regolari, al punto che i suoi concittadini di Königsberg regolavano gli orologi sulla base dei tempi della sua passeggiata pomeridiana. Perché Kant era così ossessivo nel rispettare i suoi orari? Per lasciarsi più tempo libero possibile per pensare e fare il suo “mestiere” di filosofo.
Ragioniamo un attimo: ci sono attività sia tecniche, sia di normale amministrazione, che possono essere automatizzate in modo da ridurre al minimo il prelievo di energie e il dispendio di tempo che implicano. E maggiori sono il tempo e l’energia dedicati ad attività ripetitive a bassa necessità di attenzione e creatività, maggiore sarà il risparmio che si può fare su di esse mettendo in atto processi di automazione.
In termini tecnici, questo significa ad esempio adottare una metodologia DevOps, che non serve ovviamente solo a ridurre i tempi, ma che ha anche questo non trascurabile effetto… Però ci sono tante operazioni quotidiane dal controllo dei social media alle informazioni riguardo a una determinata materia, dal reporting all’organizzazione di riunioni, che possono essere, almeno in parte automatizzati. Crearsi modelli di mail, di reportistica, utilizzare canali di comunicazione standardizzati… sono tutte attività che prendono tempo inizialmente ma che lo “restituiscono” con gli interessi in un secondo momento. E anche far fare certi lavori a esperti di dominio esterni può essere una spesa che poi si ripaga in termini di guadagno di tempo.
È inutile mettere in atto sofisticati processi di automatizzazione dei test e delle varie operazioni di configurazione, se poi consumiamo il tempo risparmiato in infinite e inutili riunioni. Almeno in parte, anche questo tipo di processi può essere automatizzato e ridotto in durata, con un positivo riverbero sulla produttività.
Conclusioni
Che ci piaccia o no, il tempo a nostra disposizione è una risorsa limitata. Possiamo, occasionalmente, tirare al massimo, ridurre i tempi di riposo e fare delle full-immersion lavorative per particolari situazioni e per brevissimi periodi. Ma, come diceva il nostro Fabio, “Lavorare stanca”. E a lui interessava maggiormente risultare produttivo, sulla base di dati di fatto, che non apparire indaffarato agli occhi dei “capi”, indipendentemente dai risultati effettivi.
La produttività si migliora aumentando la qualità del lavoro e non la quantità di ore lavorate. Il che, paradossalmente, all’inizio richiede un grosso investimento di tempo e di energie: in pratica si fa più fatica per arrivare a farne meno, che non per mantenersi sugli stessi livelli di impegno. Ma ne vale la pena, in termini professionali e di vita personale.
Luigi Mandarino ha cominciato ad appassionarsi ai computer con il glorioso ZX Spectrum 48k: una bomba, per l‘epoca 🙂 Dopo gli studi di ingegneria, si è dedicato per diversi anni allo sviluppo di applicazioni Java, specie per la piattaforma Enterprise. Successivamente, ha svolto il ruolo di architetto dei sistemi interessandosi particolarmente alle architetture di integrazione. Attualmente, svolge consulenze a svariate aziende in particolare nel settore bancario, assicurativo e finanziario, principalmente su temi inerenti le architetture Java EE e le dinamiche di processo secondo un approccio Lean/Agile.