Tempo di lettura: 3 minuti

Quando lavoro e gioco

Più che fare soldi… più che la sensazione di lanciare un nuovo prodotto, una funzione, un sito web o un’applicazione… l’idea che sto apprezzando di più nella mia vita professionale è la sensazione di “gioco”. A volte il gioco consiste nell’essere da solo, con un’elevata autonomia e poche conseguenze, a volte nella possibilità di scegliere tecnologie nuove e divertenti, ma la cosa più preziosa è quando il gioco coinvolge altre persone.

Ne ho forse già parlato in passato nel contesto di qualche progetto. È un po’ come giocare a basket: ogni membro del team si presenta alle riunione, ci si scambia il lavoro fatto in autonomia (con schermate, brevi video o dimostrazioni), si implementano le modifiche, si comunicano pensieri e sfide del momento, si parla del lavoro al di fuori degli orari stabiliti per le riunioni.

Questa pratica viene chiamata Hot potato process: “processo della patata bollente”. Un frequente avanti e indietro tra progettazione e sviluppo. Il design e il codice procedono di pari passo, si informano a vicenda e producono qualcosa di più grande della somma delle sue parti. È un processo spontaneo in cui i dettagli e la fedeltà di un’applicazione si riempiono lentamente nel tempo, come un JPEG che si carica progressivamente con una connessione lenta.

Se c’è un aspetto negativo in questo processo è che si deve ricostruire molto a metà del processo, quando arrivano nuovi requisiti o si scoprono nuovi vincoli. Quando vi è una iterazione frequente e un processo di sviluppo ciclico, si può avere la sensazione di non aver mai “finito”. È una “tassa” da pagare che potrebbe non essere neurologicamente adatta a tutti. Molti potrebbero addirittura preferire un processo più lineare, da catena di montaggio.

Se dovessi scegliere quale processo preferire, sceglierei la rielaborazione di un componente più volte in un processo hot potato rispetto ad altre alternative. Una trappola comune dei progetti waterfall e faux-agile è l’impegno eccessivo in un’idea o progetto difficile da realizzare in codice e che fa saltare l’obiettivo quando le scadenze incombono. Sono state condotte alcune ricerche sul perché i progetti falliscono e l’over-committing è tra i primi posti. A meno che tutti non siano disposti a ridurre radicalmente la specificità nel propio ambito, si esercita una forte pressione sugli sviluppatori affinché tirino fuori un coniglio dal cappello e salvino la situazione.

Quando si gioca ad acchiapparella si consegna una soluzione funzionante a ogni checkpoint. State iterando collettivamente verso qualcosa di migliore. Quando tutti guardano un codice funzionante (o un prototipo) invece di un componente teorico, si possono avere conversazioni più informate sui costi/benefici/tempi dei miglioramenti proposti. Questo livello di collaborazione è molto alto e funziona solo quando si lavora insieme, ci si presenta, si costruisce fiducia e c’è un circolo vizioso che si passa la palla avanti e indietro.

Alcuni studi suggeriscono che gli animali che giocano tendono ad adattarsi meglio a un ambiente e a un clima in continua evoluzione. La capacità di giocare e l’adattabilità sono collegate in modo univoco. Se si astrae questo concetto dal settore tecnologico, il gioco all’interno di un’organizzazione sembra più prezioso che mai nel campo della tecnologia in costante evoluzione.

Forse abbiamo bisogno di più gioco al lavoro.

Credits: Foto di Erik Mclean su Unsplash