Il lato umano della collaborazione nei team software

La collaborazione nei team software è un mestiere umano, non un problema di strumenti. Ciò che resta, cioè il codice, i file di design e la cronologia dei commit, è il fossile dei discorsi che lo hanno prodotto. Quando quei discorsi vanno bene, il sistema riflette un giudizio condiviso. Quando vanno male, lo stesso sistema nasconde vecchi conflitti sotto forma di debito tecnico.

Questo articolo parla del lato umano che i manuali di ingegneria di solito saltano. Noi siamo un team di tre persone, quindi ogni punto debole si vede subito. Qui sotto trovi dieci abitudini che reggono alla pressione vera.

La sicurezza psicologica al primo posto

Una buona collaborazione nei team software parte dalla sicurezza psicologica. Un ingegnere che teme una risposta secca smette piano piano di fare domande. Poi i piccoli dubbi diventano difetti costosi che nessuno aveva previsto.

I gruppi sani trattano la frase “spiegami questo modulo” come una richiesta normale. Poiché il tech lead detta il tono, il tech lead parte per primo. Infatti un responsabile che ammette in pubblico le proprie lacune insegna agli altri che la curiosità non si paga. Guarda la ricerca sulla sicurezza psicologica per le prove dietro questa idea.

La comunicazione scritta scala

La scrittura è ciò che permette a un gruppo di crescere. Parlare è rapido, tuttavia non lascia alcuna traccia. Inoltre una riunione taglia fuori chi vive in un fuso orario scomodo.

Il materiale scritto viaggia molto più lontano, ad esempio i documenti di design, le note delle pull request e le schede di decisione. Arriva a un collega nuovo anche mesi dopo. Inoltre mettere per iscritto un ragionamento obbliga a pensare meglio che a voce. Se il piano non regge una pagina scritta, il piano non esiste ancora.

I team piccoli comunicano meglio

Oltre le otto persone circa, il costo del parlare cresce più della resa. Ogni coppia nuova aggiunge un altro legame da curare. Per questo motivo la collaborazione nei team software rende di più in gruppi da tre a sette ingegneri con un solo obiettivo.

Quando un gruppo deve crescere, dividilo con criterio. Dai a ogni metà un confine chiaro e una piccola interfaccia stabile. Questo batte una stanza affollata. La legge di Brooks diceva lo stesso già nel 1975.

La code review rivela la cultura

La code review è il punto in cui la collaborazione cresce oppure marcisce. Le revisioni che scavano nei compromessi di design, nei casi limite e nei nomi vaghi rendono il team più forte. Invece le revisioni che litigano sullo stile personale creano solo difesa.

Quindi scrivi norme di revisione esplicite. Separa il “da cambiare” dal “da valutare”. Ringrazia una patch che ti ha insegnato qualcosa. La guida di Google alla code review è una base ragionevole da copiare. Per una modifica difficile, venti minuti in coppia battono tre giri di commenti.

Il disaccordo fa bene

Un gruppo d'accordo su tutto è incurioso oppure spaventato. Nessuno dei due stati produce software affidabile. I team forti trattano un'obiezione ben argomentata come un dono, poiché di solito nomina un rischio che nessun altro ha visto.

Perciò dai al dissenso un posto dove vivere. Registra l'obiezione, esaminala con calma, poi lascia decidere il tech lead. Dopo, tutto il gruppo si impegna insieme. Quest'ultimo dovere conta quanto la discussione che lo precede.

Il contesto condiviso fa parte del lavoro

Una persona brava aggiunge poco senza contesto, per quanto sia capace. I team seri investono nelle prime settimane. Prima, affianca chi arriva a un ingegnere esperto. Poi affidagli un compito piccolo e sicuro, prima dei sistemi in produzione.

Tieni appunti che spiegano perché l'architettura è così, non solo cosa fa. Il ragionamento è ciò che risparmia un pomeriggio al lettore successivo. In sintesi, il contesto non è una cortesia. È parte del lavoro di ingegneria.

Mescola le discipline

La collaborazione nei team software migliora molto quando design, prodotto e sviluppo stanno in un solo gruppo. I passaggi di consegne tra silos perdono dettagli; la proprietà condivisa no. Ad esempio, un designer che legge le pull request nota subito la deriva dal mockup concordato. Allo stesso modo, un ingegnere seduto a un colloquio con il cliente scopre i casi scomodi prima di scrivere una riga. La nostra pagina lavora con noi descrive il tipo di persone che cerchiamo.

Il lavoro da remoto chiede uno sforzo esplicito

Un team da remoto rinuncia ai segnali gratuiti, come un sopracciglio alzato o una chiacchiera di corridoio. Nulla li sostituisce per caso. Invece li compri apposta: più contesto scritto, agende strette e telecamere accese nelle chiamate che contano.

La collaborazione da remoto può funzionare benissimo. Tuttavia regge solo quando il gruppo ammette il costo e lo paga. I team che fingono un costo pari a zero si allontanano piano e in silenzio.

Scrivi per chi arriva dopo

Gli ingegneri che costruiscono un sistema quasi mai lo mantengono tre anni dopo. Perciò scrivi per un lettore che non incontrerai mai. I commenti devono spiegare il motivo, non la meccanica. Registra i compromessi dietro ogni scelta architetturale grande. Persino un messaggio di commit può raccontare una storia utile.

I team che saltano questo passaggio lasciano codice che si legge bene e resiste a ogni modifica. Il conto arriva anni dopo, quindi nessuno lo collega mai alla scelta iniziale.

Celebra la collaborazione in pubblico

La cultura cresce con le storie che un gruppo ripete. Dopo un incidente doloroso in produzione, racconta come il team si è ripreso. Fai il nome di chi ha lavorato davvero. Allo stesso modo, dividi il merito quando una funzione piace ai clienti.

Lo sforzo silenzioso svanisce. Lo sforzo celebrato si somma. Questa è la leva più economica che un tech lead abbia.

Le abitudini battono gli strumenti

Nessuna piattaforma nuova ripara un gruppo che non si fida di sé. Una chat non convince un ingegnere timido a parlare. Una lavagna piena di ticket non insegna a un revisore a essere gentile.

Piuttosto, gli strumenti seguono i comportamenti. Scegli poche abitudini, dai loro un nome e rivedile a ogni retrospettiva. Lascia cadere quelle che smettono di rendere. I team che fanno così migliorano sempre, ed è proprio la tesi del nostro articolo sull'apprendimento continuo nei team di sviluppo.

Come lavoriamo

Square Software è un team di tre persone in Albania. Costruiamo software su misura e ci uniamo anche ai team dei clienti come mani in più. Le nostre tariffe stanno nella fascia 35-55 EUR/ora, e studiamo ogni lavoro con cura prima di dare un prezzo.

Un gruppo piccolo rende queste abitudini facili da tenere e da lasciare. Perciò scriviamo più di quanto parliamo, rivediamo ogni modifica e accorciamo la distanza tra un dubbio e una risposta. Leggi di più su chi siamo, guarda come offriamo i servizi di outsourcing oppure scrivici.

In sintesi

Gli strumenti continueranno a cambiare. La parte umana no. In sintesi, la collaborazione nei team software è un insieme di abitudini: sicurezza, scrittura chiara, gruppi piccoli, revisione onesta e merito condiviso.

Niente di tutto ciò è un costo morbido. I team che lo trascurano scoprono, qualche anno dopo, che la resa si è fermata mentre il codice sembrava ancora pulito. Per un ragionamento vicino, leggi il nostro articolo sulle soft skill per gli ingegneri del software.