Indice
Per i team di sviluppo in rapida crescita è normale arrivare al punto di valutare la possibilità di creare un team distribuito.
In questa puntata del CTO Podcast fornisco 4 consigli per creare con successo team remoti facendo sì che gli svantaggi di questo tipo di soluzione diventino invece dei punti di forza.
Clicca il tasto play nel player qui sotto per ascoltare subito questa puntata del podcast.
Trascrizione
Ciao da Alex Pagnoni e benvenuto nel podcast Pionieri del Tech, il podcast di Axelerant dedicato ai CTO e ai responsabili dei team di sviluppo e a chi vorrebbe diventarlo.
Nella puntata di oggi parlerò di alcuni consigli utili per chi gestisce un team di sviluppo distribuito.
Oggi giorno, infatti, è normale per chi gestisce un team di sviluppo in rapida crescita doversi mettere nell’ordine di idee di creare un team distribuito.
Questo perché è sempre più difficile trovare e trattenere talenti sotto casa, soprattutto se parliamo delle piazze più competitive come ad esempio quella di Milano, dove molti miei clienti mi raccontano che spesso non fanno in tempo ad assumere una persona o instaurare una collaborazione con un freelance che se li perdono ancora prima di iniziare.
O che comunque fanno fatica a tenere queste persone in azienda, soprattutto le più valide, perché c’è una forte concorrenza sul mercato ad accaparrarsi i programmatori migliori.
Ad esempio, parlando qualche settimana fa con un’azienda, mi hanno fatto presente che avevano concordato di avviare un progetto con un paio di freelance ma che il primo giorno gli hanno dato entrambi forfait dicendo che nel frattempo avevano trovato altri lavori più remunerativi.
E non sono certo gli unici, anzi.
Questo tipo di problema è uno dei motivi per i quali molte aziende si rivolgono al mio servizio di sviluppo software per far crescere rapidamente il loro team di sviluppo creando un team distribuito più ampio, dove una parte del mio team si unisce da remoto a quello del cliente.
Chiaramente, lavorare in team di sviluppo distribuito può essere impegnativo, perché oltre ad affrontare le normali difficoltà tipiche dello sviluppo del software si possono aggiungere altri problemi, in particolare di comunicazione.
Ad esempio, a differenza in un team co-locato nella stessa stanza, non è che ci si può avvicinare alla sedia di qualcun altro per parlargli a riguardo di una nuova funzionalità o di qualche riga di codice.
Tuttavia, la realtà è che problemi come questi sono dei falsi miti se il team distribuito è stato impostato correttamente.
In Team Scaling infatti questi problemi li abbiamo già risolti molto tempo fa e anzi per esperienza devo dire che un team distribuito per come lo intendiamo noi, con certe modalità di collaborazione, comunicazione e l’uso degli strumenti adatti, ha tanti vantaggi che bilanciano ampiamente i pochi svantaggi come quello della vicinanza.
Anzi, è spesso un vantaggio non essere tutti assieme nella stessa stanza, perché le interruzioni diminuiscono esponenzialmente e aumenta la produttività.
Più in generale, posso affermare che un team distribuito può funzionare alla grande anche perché più di 20 anni fa avevo fondato un gruppo nella cosiddetta demo scene ai tempi dell’Amiga dove i membri erano tutti sparsi in giro per l’Italia, con i coder, i grafici e i musicisti che riuscivano a collaborare al meglio e a creare delle demo in perfetta sintonia, e questo con delle possibilità tecnologiche e di comunicazione ben inferiori a quelle attuali.
Inoltre negli anni successivi ho anche creato e gestito svariati progetti open source con programmatori che collaboravano da ogni parte del mondo, quindi anche con fasce orarie differenti, e avendo a che fare con persone di un certo calibro il problema di essere distribuiti non esisteva.
Questi tipi di cultura che ho vissuto a lungo tra demo scene e progetti open source con una forte componente collaborativa sono ancora oggi alla base di Team Scaling.
In questo caso la parola chiave è appunto collaborazione, che passa per una particolare attenzione alla comunicazione.
Accogliere la comunicazione asincrona
Il mio primo consiglio è infatti quello di accogliere il più possibile un modello di comunicazione asincrona, basata su una comunicazione aperta che è fondamentale in qualsiasi team ma in particolar modo in quelli distribuiti, così come di adottare il più possibile strumenti collaborativi come Slack, video conferenze come Zoom o Google Meet, ecc. e allo stesso tempo cercando di usare il meno possibile la mail, che è anche cognitivamente più impegnativa perché richiede una comunicazione più strutturata.
Una delle più grandi sfide da affrontare nei team distribuiti è infatti il disallineamento rispetto all’avere le persone di fianco, disallineamento che però si risolve in modo definitivo usando strumenti come quelli che ho indicato prima.
Anzi, come dicevo prima, personalmente lo ritengo un vantaggio, perché da una parte riduce notevolmente le distrazioni continue che si possono avere quando si è fianco a fianco, e allo stesso tempo prima di stabilire una riunione al volo che molto spesso è più una perdita di tempo che altro ci si pensa bene.
Piuttosto, bisogna cercare di aggiungere dei dettagli in più nella comunicazione e fornire più contesto possibile, in modo da ridurre i passaggi nella comunicazione.
Ad esempio, bisogna pianificare in anticipo ciò che bisogna comunicare per completare ad esempio una user story sulla quale si sta lavorando ed è meglio identificare gli eventuali blocchi prima di arrivarci, in modo che il team possa essere maggiormente proattivo nelle risposte.
Inoltre bisogna mettere da parte un po’ di tempo tutti i giorni per riprendere il filo delle conversazioni che non si è riusciti a seguire, ad esempio su Slack, e rispondere alle domande.
Incontrarsi di persona per creare fiducia
Il mio secondo consiglio è quello di incontrarsi di persona per aiutare a creare fiducia tra le persone nel team distribuito.
Ovviamente i team di sviluppo lavorano meglio quando c’è fiducia, e quest’ultima è meno facile da costruire quando ci sono meno punti di contatto con gli altri membri del team.
Anche se potrebbe non essere possibile in tutti i casi, consiglio fortemente di stabilire degli incontri di persona, anche solo uno iniziale, perché nella mia esperienza ho riscontrato il beneficio e l’impatto enorme in senso positivo che può avere nelle dinamiche del team.
Ad esempio, in Team Scaling è normale per noi andare a visitare almeno una volta il cliente con il nostro team, in modo da presentarci di persona.
Poi successivamente gli incontri possono anche essere in video o audio conferenza, anche semplicemente per parlare assieme di una feature da sviluppare oppure, quando sono previsti, nei daily meeting se ad esempio si seguono metodologie come quella di Scrum o simili.
Uno dei benefici nel creare fiducia è quello ad esempio di rendere le code review o cose come le pull request meno problematiche e creare meno timore o quantomeno ridurre le barriere psicologiche nel chiedere aiuto ad un membro remoto.
Abbattere i silos del know how
Il terzo consiglio è quello di abbattere i silos del know how o, ancor meglio, evitare di crearne.
Anche questo è un problema che nei progetti open source viene tipicamente eliminato con la condivisione della conoscenza, la scrittura di documentazione e il coordinamento con i vari strumenti collaborativi.
Chiaramente, è facile accumulare un know how condiviso con gli sviluppatori che stanno nello stesso ufficio, in termini di prodotto, metodi di lavoro, pattern di sviluppo, cambiamenti e così via.
Bisogna però evitare di dimenticarsi di condividere questo know how con il resto del team, perché i silos di questo tipo possono sfociare in persone che rimangono bloccate nello sviluppo, pull request che non aderiscono ai nuovi pattern di sviluppo e problemi di vario genere.
Per ridurre o eliminare questo problema ci sono vari modi, come quelli che ho citato prima ma anche notificando l’intero team di sviluppo di questi tipi di cambiamenti e decisioni ogni volta che si verificano.
Le chat condivise come Slack sono molto utili in questo senso, ad esempio noi abbiamo sempre dei canali condivisi con i clienti o ancor meglio entriamo nello stesso account Slack del cliente condividendo i vari canali dedicati allo sviluppo.
Anche il pair programming da remoto aiuta molto ad evitare la creazione di silos informativi.
Eccedere nel comunicare le aspettative
Il quarto consiglio consiste invece nell’eccedere comunicando le aspettative, che devono quindi essere esplicitate il più possibile. Questo è uno dei casi in cui troppo è meglio di troppo poco, che peraltro aiuta a fare chiarezza sui requisiti e sulle aspettative dei propri clienti e utenti finali.
Bisogna infatti ridurre la possibilità di avere comunicazioni errate o carenti in questi casi, in particolar modo quando si parla di requisiti, espressi ad esempio in forma di user stories.
Alcuni dei rimedi sono quelli di rendere espliciti i criteri di accettazione delle singole user stories, di aggiungere delle checklist relative a ciò che va fatto, documentare le funzionalità correlate a quelle user stories che non vanno sviluppate per quelle story in modo da evitare lavoro extra, così come includere screenshot e link ai design dove previsti.
Inoltre, iscriviti alla nostra community, dove potrai approfondire questo argomento, fare domande e condividere le tue esperienze, interagire con me personalmente e suggerire un argomento per le prossime puntate.
Grazie di nuovo e al prossimo episodio, ciao da Alex.
