Rompere i silos: come migliorare la resilienza del tuo team ed evitare il "bus factor"

Hai mai sentito parlare del concetto di bus factor? Se no, permettimi di presentartelo. Il bus factor è un’idea semplice che non richiede una comprensione complessa.

Basta porsi questa domanda: quanti membri del team dovrebbero diventare improvvisamente indisponibili (a causa di un incidente o una vacanza imprevista) perché il lavoro del tuo team si fermi completamente?

Naturalmente, non vogliamo che accada nulla di spiacevole a nessuno, quindi, pensando a questo scenario, è meglio immaginare un'ipotesi più leggera. Quando le persone si prendono una pausa pianificata, ottengono una promozione o lasciano il lavoro, di solito c'è un periodo di transizione per trasferire conoscenze e condividere documenti. Ma cosa succederebbe se il tuo collega esagerasse a un addio al celibato e si trovasse bloccato in un altro paese senza risorse (un’alternativa più ottimistica rispetto a essere investiti da un autobus)?

Con i tuoi stakeholder che attendono con ansia il prodotto, il tuo team sarebbe in grado di consegnare senza il contributo di quel membro?

In molti team disfunzionali che ho incontrato, il bus factor è spesso basso, persino pari a uno. La perdita di un solo membro può bloccare tutto o causare ritardi significativi. Naturalmente, anche i team Agile ad alte prestazioni possono incontrare difficoltà temporanee se perdono un membro, e potrebbero verificarsi ritardi semplicemente a causa di meno "mani disponibili". Tuttavia, il lavoro non si fermerà completamente, poiché i membri rimanenti saranno in grado di raccogliere i pezzi e andare avanti, consegnando infine un incremento del prodotto funzionante.

I silos sono dannosi non solo perché ostacolano i benefici sinergici derivanti dal lavoro di squadra, ma anche perché rappresentano rischi significativi per il tuo prodotto o progetto. Ma ciò significa che tutti i membri del team devono essere dei tuttofare, esperti nei dettagli del lavoro degli altri? Gli UX designer dovrebbero seguire corsi di Python e i tester dovrebbero imparare il marketing digitale? Sebbene ampliare le proprie competenze sia sempre utile, potrebbe non essere l'uso più pratico di tempo e risorse. E no, i tuoi ingegneri backend non devono diventare esperti di Photoshop o Figma.

Detto ciò, è essenziale che i membri del team conoscano i ruoli reciproci, sappiano dove sono archiviate le informazioni e siano familiari con i contatti chiave. Consideriamo alcuni scenari ipotetici per illustrare come funzionerebbero un team suddiviso in silos e un team collaborativo in situazioni diverse.

Il caso di Linda: un esempio pratico

Ti presento Linda. Linda è una UX designer che lavora in un team di sviluppo di app, creando la maggior parte dei suoi design con Adobe XD e assemblando prototipi su InVision. Il team sta lavorando diligentemente su una nuova funzionalità che è già stata annunciata ai clienti e ha generato grande entusiasmo nei media. Linda è l’unica UX designer del team e sta ultimando l’interfaccia utente di questa funzionalità tanto attesa. Tuttavia, un lunedì mattina, non si presenta al lavoro e il suo telefono rimane inattivo.

Scenario con un team operante in silos

Immagina il team di Linda operare all’interno di silos, con ogni membro concentrato esclusivamente sulla propria parte di prodotto. Il product owner scrive le specifiche (sarebbe sorprendente se un team in silos riuscisse a creare user story adeguate), mentre gli sviluppatori iOS e Android programmano e i QA testano il loro lavoro. Con Linda assente, gli sviluppatori non possono proseguire e il lavoro si ferma mentre il team cerca un sostituto. Il nuovo designer impiega alcuni giorni per comprendere il problema, esaminare le versioni precedenti dell'app e creare nuovi design da zero. La funzionalità subisce ritardi e i clienti rimangono delusi.

Quando Linda ritorna due giorni dopo, spiega che era rimasta bloccata nella baita dei nonni a causa di un temporale che aveva interrotto l’elettricità. Con il telefono scarico, non poteva chiamare un Uber o avvisare i colleghi. Anche se tutti sono sollevati che Linda stia bene, gli stakeholder non sono soddisfatti del ritardo nella consegna.

Scenario con un team collaborativo

Ora, immagina lo stesso scenario in un team collaborativo. Quando Linda non si presenta, i suoi compagni non iniziano a progettare da soli. Tuttavia, hanno tutti accesso ad Adobe XD e InVision, sanno dove Linda archivia il suo lavoro e possono facilmente recuperare l'ultima iterazione del giorno precedente. Come si scopre, i design sono quasi completi e la funzionalità è chiara a tutti grazie al prototipo cliccabile che Linda ha completato venerdì. Il product owner ha alcune perplessità su un paio di pulsanti, ma gli aggiustamenti sono un compito rapido di 30 minuti che un designer di un altro team può facilmente gestire. Inoltre, Linda mantiene linee guida progettuali in una cartella condivisa, consentendo a qualsiasi designer di intervenire rapidamente e completare il lavoro. Sebbene il team sia preoccupato per Linda, il lavoro continua e l'app viene rilasciata nei tempi previsti.

In conclusione, più il tuo team opera in silos, maggiori sono i rischi. La vita è imprevedibile e, anche se speriamo che nessuno venga mai colpito da un autobus, esistono sempre possibilità di malattia, emergenze familiari o scenari improbabili e assurdi (tatuaggi sul viso e tigri, qualcuno?). Rompere i silos non significa necessariamente che ogni membro del team debba lavorare su tutto, ma significa che possono coprirsi a vicenda quando necessario.

Ecco alcuni passi pratici per rompere i silos nel tuo team:

1. Utilizza cartelle condivise per i documenti di lavoroAssicurati che tutti i membri del team siano responsabili dell'archiviazione di tutti i documenti, inclusi quelli in corso, in cartelle condivise. Servizi come Google Drive, Box, Dropbox e SharePoint rendono facile configurare uno spazio di archiviazione condiviso.

2. Crea una base di conoscenzaDocumenta le migliori pratiche, le procedure comuni e altre informazioni utili per i nuovi arrivati. Anche se il tuo team non assume frequentemente nuovi membri, questa documentazione sarà utile quando avrai bisogno di supporto extra o quando i membri del team dovranno coprire un collega assente.

3. Conduci sessioni di backlog refinement e pianificazione insiemeIn questo modo, tutti saranno consapevoli di chi sta lavorando su cosa e si promuoverà una maggiore trasparenza.

4. Incoraggia i membri del team ad aiutarsi a vicendaAnche se i compiti ricadono fuori dalla loro area di competenza principale, è importante che abbiano una conoscenza di base degli strumenti e delle tecniche degli altri membri del team. Non devono diventare esperti in tutto, ma avere una visione d'insieme può fare la differenza.

5. Crea user story verticalmente suddiviseLa maggior parte delle user story richiederà la collaborazione di diversi membri del team con competenze diverse. Questo approccio promuove l'apprendimento reciproco e la comprensione dei rispettivi strumenti e metodi.