In un’azienda in full remote working, non si rinuncia per principio ad utilizzare le risorse migliori, dovunque esse siano.

Questo causa un problema organizzativo non da poco: i componenti del team potrebbero non trovarsi nel medesimo fuso orario.

Il fuso orario non sempre è geografico: può capitare un componente del team più produttivo e più portato a lavorare in orari insoliti. In questo caso va trattato come un componente remoto nel fuso orario di appartenenza.

La prima cosa di cui tenere conto in un team che lavora in modalità remota e multifuso, è la scelta degli strumenti. Ogni cosa deve essere lavorabile in asincrono: le call ridotte al minimo, spesso nei periodi di “confine” tra chi finisce di lavorare e chi inizia.

Occorrono delle policy aziendali, anche semplicemente dette, che spieghino come si lavora in asincrono. La base sta nell’eccesso di informazione. Quando si comunica con questa modalità infatti non si può dare niente per scontato, altrimenti il rischio è che passi un giorno intero prima di potersi chiarire di nuovo.

Le timeline, i piani di lavorazione, gli obbiettivi, e la kanban board, devono essere il pane di tutti: sono le uniche misurazioni che i manager hanno per vedere a che punto è il team.

Certo ogni tanto sarà necessaria qualche alzataccia o fare tardi per coordinarsi a voce. Tranquilli: se l’informazione asincrona è completa, accadrà di rado.

Infine oltre alla barriera temporale occorre valutare come affrontarne altre, culturali e linguistiche per esempio, se presenti.

Nel caso della lingua, in caso di team multiculturali, si adotta per convenzione l’inglese, che generalmente tutti in azienda conoscono.

Ricordatevi però di non tralasciare le unità di misura, imponendo il sistema metrico decimale e le date in formato aaaa/mm/dd per esempio, onde evitare comunicazioni errate o di possibile incomprensione. In ogni orario inoltre, ricordate di specificare il fuso orario utilizzato. “Rilasciamo lunedì” per esempio, non ha un significato preciso. Semmai si rilascia Lunedì alle 11:00GMT+1.

Per la parte IT è consigliabile usare sistemi dì CI/CD con possibilità di schedulazione precisa dei lavori. Inoltre, essendo più complesso il pair programming, dovrete scrivere sempre i test, in modo che tra sviluppatori ci si interfacci lavorando su codice testato e sicuramente funzionante.

Un team agile e liquido così strutturato sarà pronto ad affrontare delle sfide con elementi altrimenti non possibili nel team. Potrete, in cambio di un po’ di complessità organizzativa, contare sulle persone migliori, dovunque esse siano e qualsiasi abitudine abbiano.

Pensateci.