Oltre il lavoro da remoto

Il lavoro da remoto si è affermato da qualche anno. Oggigiorno, complice anche una pandemia, il tema è sulla bocca di tutti. Tutti ne parlano. In tanti dicono di praticarlo. In pochi hanno veramente compreso cosa significa, come si attua e che impatto può avere.

Parlare di lavoro da remoto vuol dire tutto e niente. È una definizione troppo generica. Chi fa telelavoro, con un orario fisso, pause pre-concordate, e compiti definiti nel minimo dettaglio, lavora da remoto? Allo stesso modo il nomade digitale che viaggia e lavora su svariati progetti, organizzandosi in autonomia, e senza orari fissi, lavora da remoto? Tecnicamente, in entrambi i casi la risposta è sì, sono entrambi lavoratori da remoto.

Non mi voglio addentrare nella diatriba “smart working vs. lavoro da remoto”. Il termine smart working viene usato pressoché solo in Italia; il resto del mondo usa i termini Work from Home (WFH) o Remote Working. Inoltre, se ci pensiamo, qualsiasi modalità di lavoro può essere smart (“brillante”, “intelligente”) e, per esserlo, non deve necessariamente svolgersi da remoto.

A questo punto è ovvio che ogni definizione possa andare stretta. È altrettanto importante sottolineare che non c’è un lavoro da remoto giusto o uno sbagliato. Ogni realtà ha le sue peculiarità e come per molte altre cose il contesto è sovrano. È quindi sensato declinare il lavoro da remoto in base a contesto e necessità.

Dispersi

Nel 2010, quello che oggi è il prodotto di punta dell’azienda per cui lavoro era utilizzato da svariate realtà internazionali. Al tempo era un prodotto open source, frutto dell’attività di consulenza del suo creatore. Al crescere degli utilizzatori e delle conseguenti richieste di modifiche, e perché no, segnalazioni di bug, risultò ovvio che una persona sola non potesse più sostenere il carico di lavoro.

L’attività di consulenza internazionale del creatore, e la sua necessità di viaggiare continuamente, fecero sì che fosse naturale cercare collaboratori tra la cerchia delle conoscenze lavorative, piuttosto che nella zona di residenza. Il primo “arruolato” fu un messicano, che ancora oggi si occupa di amministrazione e di una buona fetta della parte finanziaria. Il secondo uno svedese, che diventò direttore del reparto tecnico e rimane uno dei pilastri dell’area di sviluppo.

Col tempo ci si è resi conto che la possibilità di assumere persone sparse per il mondo porta con sé alcuni vantaggi. Elimina i costi di ricollocamento, la barriera psicologica ad esso legata e permette di avere le persone vicino a dove sono i clienti. Infine, garantisce che il fuso orario di chi deve fornire supporto coincida con quello dei clienti, in modo da evitare reperibilità notturne.

Queste caratteristiche hanno fatto sì che la tendenza non si fermasse. Oggi ci definiamo orgogliosamente “dispersi” (dispersed). Siamo “spalmati” su diciassette fusi orari. Dalla California, negli Stati Uniti, a Sydney in Australia. Nessuno lavora nella stessa città di nessun altro.

Tutto rigorosamente asincrono

Lavorare su diciassette fusi orari comporta che ci siano colleghi che non si sovrappongono mai. Significa anche che non c’è mai un orario in cui sono tutti “al lavoro”. È spesso una questione prettamente logistica: per chi vive in Michigan, ad esempio, le possibilità di avere un’ora di sovrapposizione con chi vive a Sydney sono limitate al brevissimo periodo in cui l’ora legale scatta prima in un posto di quando scatta quella solare nell’altro.

Se è un vincolo all’apparenza insormontabile, come si può pensare di far lavorare insieme persone che a fatica si possono vedere? Strutturando tutti i processi intorno al vincolo. Tutti i nostri processi sono pensati per persone che lavorano in gruppo, ma che non lavorano nello stesso momento. Lavoriamo sì da remoto, ma soprattutto lavoriamo in maniera asincrona. Ci sono voluti più di sei anni per arrivare alla struttura attuale e un articolo non può certo essere esaustivo, mi limiterò quindi ad elencare alcuni esempi.

Facciamo pair programming [1], ma non molto: sia per la questione dei fusi orari sia perché gli strumenti per fare pairing da remoto sono ancora lontani dal fornire un’esperienza degna del suo nome. In ottica di lavoro asincrono, facciamo invece revisione incrociata pressoché di qualsiasi cosa. Del codice, ovviamente, ma anche della documentazione, del comunicato per annunciare il rilascio di una nuova funzionalità, o di una risposta al quesito di un cliente. Una o più persone scrivono e una o più persone rivedono. E così via fintanto che il lavoro non è completo.

Comunicazione, comunicazione, comunicazione

Un’interazione quasi costantemente asincrona richiede un costante allenamento delle abilità comunicative. Perché un collega possa continuare il lavoro iniziato da altri, in una time zone diversa, è essenziale che trovi un resoconto sullo stato di avanzamento lavori, annotazioni, e tutto ciò che gli possa servire per portare avanti il compito assegnato. Non deve dipendere dalla disponibilità di chi non potrà essere disponibile.

Non è semplice sviluppare le capacità comunicative richieste. È molto facile scrivere per sé stessi. Quando rileggete avete a disposizione, nella vostra testa, tutto il contesto e tutte le informazioni non scritte. È molto difficile scrivere per gli altri: richiede mettersi nei panni altrui, non dare nulla per scontato e, in quasi tutti i casi, richiede di scrivere anche le ovvietà. Preferiamo sovra-comunicare, piuttosto che rischiare di non essere compresi; potrebbe compromettere l’intera giornata lavorativa di qualcun altro.

Abbiamo più di un canale di comunicazione. Si spazia dai commenti a una pull request su GitHub, agli aggiornamenti di stato in una issue su GitHub, al canale di Slack appositamente creato per il compito che il gruppo di lavoro sta svolgendo. Ogni canale ha uno scopo leggermente diverso, ma nel loro insieme ci permettono di lasciare una costante scia di “briciole di pane”. Chiunque le può seguire per comprendere appieno il contesto e lo stato.

Scrivere significa anche che tutti i processi sono scritti, non c’è nulla che viene portato avanti in forma aneddotica, o semplicemente perché sta nella testa di qualcuno. Se un processo esiste, è corredato di documentazione, liste di cose da fare e modelli che vengono usati, ad esempio, per creare nuove issue su GitHub. Riteniamo che abbia molto più senso impegnare energie per risolvere un problema piuttosto che ricordarsi tutti i passaggi necessari per fare un rilascio.

Comunicare significa inoltre che “se vediamo qualcosa, diciamo qualcosa” (if you see something, say something). Questo principio si traduce, ad esempio, in un continuo aggiornamento della documentazione e dei processi. Si spazia da correzioni minime, come gli errori di ortografia, a quelle più sostanziose derivanti, ad esempio, da un cambio nelle procedure di rilascio a fronte di un aggiornamento di uno degli strumenti interni.

Queste modifiche seguono gli stessi principi di revisione incrociata di cui abbiamo accennato. Quando c’è una modifica da apportare, viene aperta una pull request, qualcuno farà la revisione delle modifiche e ci si occuperà, insieme, di incorporarle.

I pro e i contro

L’assenza di un orario lavorativo rigido, la pianificazione per compiti e la pervasiva natura asincrona, danno un elevatissimo grado di libertà che si riflette nel bilanciamento lavoro / vita privata. Perché andare in piscina dopo le diciotto, quando tutti vanno a nuotare, se lo puoi fare alle undici di mattina? Oppure, perché fare la spesa il sabato, quando la si può fare in settimana alle due del pomeriggio in tutta tranquillità? O anche, perché non organizzare la propria giornata lavorativa in maniera simile a quella scolastica dei figli e non smettere di lavorare tutti i giorni alle sedici?

Il rovescio della medaglia è che c’è sempre qualcuno che lavora. Vuoi perché sta in un fuso orario diverso, vuoi perché è di un culto religioso diverso e quindi quello che per qualcuno è Natale, per altri è un giorno qualunque. Sta di fatto che gestire la disconnessione è molto difficile. Commettere l’errore di guardare le notifiche alle dieci di sera e ritrovarsi a lavorare a mezzanotte è molto facile. Ma anche molto sbagliato. Nessuno lo chiede, ogni cosa è pensata per far sì che non sia mai necessario. Nonostante tutto, succede. È una trappola in cui è facilissimo cadere.

Fiducia, responsabilità e maturità

In conclusione, un aspetto cruciale. Quanto fin qui esposto è solo tattica e logistica. È tutto necessario, ma non sufficiente. Fiducia, responsabilità e maturità sono aspetti fondamentali senza i quali abbiamo solo un bell’abito, ma ci siamo scordati del monaco.

Ciò che abbiamo esposto fino ad ora altro non è che il risultato del rendere le persone totalmente autonome nello svolgimento dei compiti. L’autonomia è una medaglia con due facce. Non c’è autonomia senza fiducia e non c’è autonomia senza maturità e responsabilità. È necessario avere fiducia totale nelle persone a cui si garantisce autonomia. Al contempo, un elevato livello di maturità e di responsabilità è necessario per garantirsi l’autonomia concessa. Al venir meno di una delle due facce, il gioco si rompe e l’impalcatura crolla.

Un’organizzazione che volesse abbracciare il lavoro da remoto nella sua essenza deve comprendere come rendere autonome le persone, o in senso più ampio, i gruppi di lavoro. Fiducia, responsabilità e maturità sono aspetti essenziali che la cultura dell’organizzazione deve promuovere con tutte le sue forze. Al contempo è necessario costruire tutte le strutture di sostegno senza le quali le fondamenta culturali hanno poca possibilità di esprimersi.