Esperienza team remoto (dall’emergenza alla efficenza)

    Esperienza team remoto (dall’emergenza alla efficenza)

    La nostra azienda ha nel DNA il lavorare con colleghi distribuiti geograficamente in italia e all’estero e spesso ci troviamo a lavorare in contesti internazionali, ma l’emergenza COVID-19 ha reso necessario una transizione di tutta la nostra forza lavoro in modalità full-remote, oltre ogni nostra previsione.

    I nostri team di lavoro sono attualmente in grado di riunirsi, decidere, pianificare, rilasciare deliverable, monitorare, e consumare quei momenti di vita di gruppo pur non essendo seduti alla stessa postazione. Garantendo i nostri servizi e preservando lo stesso grado di efficacia.

    La transizione al lavoro remoto è stata per noi un percorso incrementale molto rapido, ma non scevro di apprendimenti di natura organizzativa, tecnologica e umana.

    Presentiamo qui la nostra storia composta da due fasi: la prima ‘abilitante’ e divisa in diversi step che ci hanno consentito di far lavorare l’intera azienda da remoto. Ed una seconda fase, consapevole ed orientata all’efficentamento del lavoro in questa modalità.

    Phase 1: abilitare al Remote Work

    must-have infrastructure

    In maniera lungimirante, prima del generale lock down, il nostro reparto IT si è assicurato di avere a disposizione una infrastruttura che ci consentisse di operare da remoto. In un clima di massima emergenza ed in poco tempo ha abilitato tutti i dipendenti all’accesso alla VPN aziendale.

    Ci si è assicurati inoltre che ogni dipendente fosse dotato di risorse hardware appropriate:

    – un laptop con webcam

    – cuffie con cancellazione del rumore

    – accesso ad internet da casa

    – un recapito telefonico mobile (con possibilità di tethering)

    apertura all’esterno delle risorse di progetto

    Ove necessario ogni team leader di progetto ha comunicato al cliente l’inizio del lavoro da remoto. Si è poi censito e riportato tutte le risorse software di cui si aveva necessità per garantire il servizio e in accordo con i sistemi si è provveduto a garantirne l’accesso dall’esterno della rete Euris.

    Tipicamente un team di sviluppo software ha avuto necessità di accedere a:

    – Source control: (Git server hosted, Bitbucket, GitLab, Azure Repos, …)

    – Build pipelines & automation tools: (Bamboo, Jenkins, Azure DevOps, GitLab, AWS CodePipeline)

    – Environments: accesso agli ambienti di sviluppo condiviso, agli ambienti di integrazione ed ai database corrispondenti

    studio degli opportuni strumenti di comunicazione

    Oltre alle risorse necessarie alla scrittura e rilascio del codice un ruolo chiave è stato rivestito dalla comunicazione. E’ qui che l’emergenza coronavirus ci ha costretto a cambiare ed evolvere: la necessità di privarci del contatto umano, di momenti di condivisione svolti de-visu, l’impossibilità di sedere di fronte allo stesso monitor o lavagna ha comportato una riprogettazione dei modi e degli strumenti comunicativi.

    Per i team che erano abituati a lavorare alle stesse scrivanie è venuto a cadere il concetto di supervisione ed allineamento reciproco che si poteva avere anche solo osservando un momento il monitor del vicino. Oltre al consueto contatto telefonico (risposta immediata, ma poco utile alle sessioni collegiali) e al formale ed asincrono canale delle email (con risposta < 8h, ma a rischio congestione) ha giocato un ruolo fondamentale uno strumento intermedio, near real time: la chat.

    Diverse piattaforme di messaggistica istantanea erano già in uso localmente in ogni progetto e si è scelto di far convergere tutta l’azienda su una piattaforma. La scelta si è orientata su Microsoft Teams che ci ha consentito di poter contattare tutti rapidamente, di avere canali e room tematiche, di condividere rapidamente documenti e fare video call; anche all’esterno dell’azienda.

    Questa scelta di fatto è stato un fattore abilitante il lavoro da remoto e al momento ospita il grosso delle informazioni che transitano intra-team e aziendalmente.

    Teams ci ha supportanto anche nella organizzazione di sessioni di video conferenza. Una modalità che è divenuta estremamente diffusa e quotidiana, internamente e anche verso i clienti. In queste situazioni è fondamentale disporre di uno strumento che possa garantire lo screen-sharing (ed il trasferimento di controllo di mouse e tastiera) e la registrazione delle sessioni.

    Se per alcuni team prima era possibile chiedere a voce se una attività su un documento era terminata, ora che il grosso delle comunicazioni è scritto in una chat, si ha un filtro. Si selezionano i termini, si scrive meno rispetto a semplicemente chiedere. E’ in questo contesto che un workspace condiviso acquisisce valore, la condivisione organizzata dei documenti è diventata chiave e strumenti quali share su directory condivise, o wiki sono risultati non più accettabili. Anche in questo caso abbiamo utilizzato uno strumento unico in cui poter far confluire contenuti documentali, ma anche verbali, report e sessioni di analisi condivise. La nostra scelta è ricaduta su Atlassian Confluence. Di particolare valore è l’ottica ‘push’ (è il tool che ci avvisa quando qualcuno modifica gli argomenti di nostro interesse) il versioning dei documenti, la possibiltà di commentare e l’integrazione con altri tool esterni.

    In alcuni casi è necessario riunirsi virtualmente di fronte ad una lavagna per lavorare a sessioni di brainstorming. In questi casi ci siamo avvalsi di strumenti ad-hoc come Jamboard.

     tracciamento delle attività

    Tutta l’esperienza di collaborazione in team è virtuale. E’ necessario che ci sia una board che rappresenti lo stato di avanzamento dei lavori di tutto il team. E’ sempre stato nel nostro dna lavorare con board di tracciamento. Esse rappresentavano uno standard de-facto di ogni progetto molto prima dell’emergenza COVID-19. In questa transizione verso il full-remote ci siamo occupati di far convergere le varie esperienze all’utilizzo di un tool comune: Jira, di curarne l’adozione e assicurare opportuna formazione ad ogni team. Anche Jira supporta la modalità ‘push’ di diffusione degli aggiornamenti di stato e riduce l’effort del controllo.

    Phase 2: Perform

    Sviluppare codice da remoto

    Lo sviluppo di codice è una attività che richiede forti competenze verticali ma altrettanto forti necessità di confrontare il proprio lavoro con le esigenze del committente e l’infrastruttura, l’esistente e la cultura di sviluppo del team. Riuscire ad implementare da remoto dei meccanismi che soddisfino questi punti lavorando separati e senza potersi incontrare fisicamente, non è banale.

    Per riuscire ad ottenere ciò abbiamo agito su due fronti. Il primo è stato il consolidamento degli strumenti di Continuous Integration. I quali, corredati da opportune suite di test, sono diventati il nostro termometro di salute del prodotto software attualmente in sviluppo. È lo strumento di CI che sollecitato ad ogni commit (veramente frequenti in modalità full-remote) ci dice se siamo confidenti a rilasciare il software. Ancora in questo caso, ritorna l’ottica “push” di trasmissione delle informazioni: mi arriva una notifica se la mia ultima modifica ha causato dei malfunzionamenti.

    In aggiunta alle pipeline di CI, ci siamo avvalsi di strumenti di analisi statica del codice, SonarQube nello specifico.

    Il secondo fronte di azione ha riguardato la collaborazione alla scrittura del codice. Diversi sono i tool che abbiamo utilizzato con successo: Visual Studio Live Share, Eclipse Saros, IntelliJ Floobits/Saros. Oltre che alla condivisione schermo con la possibilità di trasferire il controllo di mouse e tastiera. Questi strumenti hanno reso possibile una collaborazione efficace, con la possibilità di lavorare in diretta ed in contatto audio/video sullo stesso file di codice e particolarmente utile in fase di review o ai fini formativi di risorse più junior.

    Non da ultimo il meccanismo delle pull-request (GitLab, BitBucket, TFS) che ha consentito di mettere in atto un sistema di controllo della qualità del codice sorgente, che ci consente di indicare puntualmente le linee di codice da migliorare e perchè e che in definitiva ha permesso di sviluppare la cultura di sviluppo software di team, l’aderenza alle best practices del settore e la crescita dei colleghi più junior.

    Modifiche ai nostri comportamenti

    Come team players il leitmotiv del lavorare da remoto è stato incentrato nel comunicare in maniera precisa lo stato delle attività, gli elementi bloccanti ed in ultima analisi anche il nostro punto di vista. Come già segnalato, si perde in questa modalità tutto il linguaggio non verbale ed il ‘lusso’ di poter disporre di più di occasioni di condivisione corale come una banale sosta alla macchinetta del caffè.

    Lo standup meeting viene seguito scrupolosamente, si è sintetici, orientati a ciò che manca, piuttosto che ai progressi. Si pospongono le questioni più lunge di alcuni minuti a sessioni di approfondimento tematiche, ci viene richiesto di comunicare esplicitamente la nostra confidenza nel chiudere una attività e in quali tempi, si concede ulteriore spazio a pianificazioni tattiche ad opera del team leader: anticipiamo i task più complessi nelle prime ore della giornata in modo da poter attuare piani di compensazione.

    Abbiamo avuto inoltre esigenza di introdurre uno Afternoon-check come momento formale di controllo nel primo pomeriggio, il quale ci ha permesso di verificare e affinare la nostra capacità di prevedere le nostre performance.

    La Definition-of-Done diventa un contratto forte all’interno del team. È un impegno che solleva gli altri membri dal dover controllare la completezza del lavoro altrui (il compagno di scrivania con più esperienza non riuscirà a ‘buttare un occhio’ sul mio operato). La si discute insieme e la si rende esplicita. E si itera perfezionandola.

    La board è sempre aggiornata.

    Se tutta la nostra esperienza di collaborazione è mediata da strumenti digitali è stato necessario per noi sviluppare una nuova etichetta.

    Il primo problema da affrontare è stato mostrare se si è disponibili oppure no. In questo senso si è promosso un uso diligente del segnalino di stato stato sullo strumento di chat, che è diventato per noi l’indicatore di presenza.

    Allo stesso modo l’utilizzo dei calendar meeting è diventato preponderante e strutturale: non è più possibile aspettare segnali impliciti per l’avvio di una riunione come il collega che solleva le mani dalla tastiera, o sospira soddisfatto “finito”.

    In ultima analisi il lavorare distanti ha richiesto maggiore diligenza nell’utilizzo degli strumenti di comunicazione ed un consumo ancora più responsabile del tempo altrui. Ma una volta avviata, questa modalità ha permesso ai membri del team di godere di grande autonomia e focus. Ed ha avuto un ottimo output in termini di performance, che non hanno subito alcuna flessione se non in positivo.