L'onboarding Degli Sviluppatori Che Consegna Subito

L’onboarding degli sviluppatori di solito si misura sulla durata dell’accoglienza formale, che è il lato sbagliato del problema. Il numero che conta è un altro: quanto passa prima che un nuovo ingegnere riesca a cambiare qualcosa avendo la certezza di non aver rotto nient’altro. Nella maggior parte dei team si misura in mesi, non in giorni.

Il ritardo dipende raramente dalla persona. Dipende da quanta parte del sistema esiste soltanto nella testa di altri, e da quanta parte delle prime due settimane se ne va a estrarla una interruzione alla volta.

L’unica metrica che vale la pena seguire: quanto passa prima che la loro prima modifica arrivi in produzione. Non il primo commit, che può essere un refuso corretto, ma un cambiamento che contava ed è andato online. Se serve più di una settimana, l’ostacolo quasi mai è la capacità. È una procedura di installazione che nessuno ha rifatto da zero di recente, oppure una base di codice i cui punti di ingresso non si trovano senza una guida.

Con che cosa compete l’onboarding degli sviluppatori

Tre costi, e uno solo riguarda il tempo della persona appena arrivata.

Il suo tempo, quello visibile e quello che tutti cercano di ottimizzare. Il tempo del team, perché ogni domanda interrompe qualcuno che stava facendo altro, e questa voce pesa più della prima. E il costo delle domande mai fatte, quando un nuovo ingegnere preferisce tirare a indovinare piuttosto che disturbare per la quinta volta in una mattina, e l’ipotesi è sbagliata in un modo che verrà a galla solo due mesi dopo.

È il terzo costo quello che un buon onboarding elimina davvero. La documentazione vale la pena di essere scritta non perché leggere sia più rapido che chiedere, ma perché permette di trovare la risposta alle undici di sera senza dover pesare il costo sociale di un’altra domanda.

Sistemate prima l’ambiente

Il fattore che pesa di più sulla prima settimana è se il progetto parte su una macchina pulita senza aiuto.

I team lo sottovalutano con regolarità, perché tutti hanno già un ambiente funzionante e nessuno ne ha ricostruito uno da due anni. Nel frattempo il documento di installazione rimanda a una versione che è andata avanti, salta la variabile d’ambiente che qualcuno ha aggiunto la primavera scorsa, e dà per scontato l’accesso a un servizio che alla persona nuova non è mai stato concesso.

Il rimedio non è affascinante. Fate seguire il documento alla lettera dal prossimo assunto, senza cambiare nulla, e annotate ogni punto in cui fallisce. Quella lista è la vostra vera procedura di installazione. Meglio ancora: riducetela a un solo comando che produce un sistema avviato con dati di prova utilizzabili, perché ogni passo manuale è un passo destinato a scivolare via.

Gli accessi fanno parte dell’ambiente. Chi ha il codice ma non i permessi sul repository, le credenziali di staging o il tracker non è pronto a lavorare. Preparate gli account prima della data di ingresso, invece di scoprire i buchi la prima mattina.

Affidate subito un compito vero

L’istinto di proteggere una persona nuova dal lavoro reale per due settimane nasce da buone intenzioni e ottiene il risultato opposto. Leggere una base di codice senza uno scopo insegna pochissimo, perché non c’è nulla a cui ancorare la lettura.

Una modifica piccola, autentica e rilasciabile al secondo o al terzo giorno insegna l’intero percorso di consegna: dove vive il codice, come girano i test, come funziona la revisione, come avviene il rilascio e a chi va detto. È il percorso di cui un nuovo ingegnere ha più bisogno ed è quello che meno di ogni altro risulta scritto da qualche parte.

Scegliete qualcosa che un utente vero sta aspettando, non un esercizio inventato. Le persone se ne accorgono, e la differenza decide se prenderanno sul serio i riscontri.

Poi lavorateci in coppia. Un’ora accanto a chi conosce il sistema trasmette più di una giornata di lettura, e chi affianca di solito scopre qualcosa sulla propria base di codice.

Che cosa scrivere e che cosa no

La documentazione si deteriora, quindi scrivete solo ciò che resta vero e ripaga la manutenzione.

Vale la pena: come si installa e si avvia il sistema, come si rilascia, che forma ha l’architettura e perché è così, le decisioni che altrimenti verrebbero rimesse in discussione ogni volta, e chi è responsabile di che cosa. La nostra guida alla documentazione tecnica tratta più a fondo il problema della manutenzione.

Non vale la pena: tutto ciò che il codice già dice con chiarezza, i percorsi passo passo di schermate che cambiano ogni mese, e i riferimenti API esaustivi compilati a mano. Sono le pagine che invecchiano più in fretta e che ingannano di più.

Nella maggior parte dei team il documento di maggior valore è una breve panoramica dell’architettura che spiega quali sono i pezzi principali e perché sono stati separati. Costa un pomeriggio, cambia di rado, e risponde alla domanda che ogni nuovo ingegnere passa la prima settimana a ricostruire da solo.

L’onboarding è una prova per il team

Tutto ciò su cui una persona nuova inciampa è qualcosa che il team assorbiva senza accorgersene.

Se l’installazione richiede tre giorni, quel costo c’è sempre stato, pagato a piccole rate da chiunque abbia mai rimesso in piedi una macchina. Se nessuno sa spiegare perché un componente esista, quell’ambiguità sta già costando decisioni. Se il rilascio ha bisogno di una persona precisa, quella dipendenza era già un rischio, ed è lo stesso che emerge in una due diligence tecnica e in qualsiasi piano di ripristino serio.

Trattate quindi le prime settimane come un audit gratuito. Chiedete alla persona nuova di tenere una lista di tutto ciò che l’ha confusa, e leggete quella lista come un backlog, non come un giudizio sulle sue capacità. È la descrizione più onesta del vostro sistema che qualcuno vi darà, perché dopo due mesi anche lei avrà smesso di notare.

Mecanik entra spesso in basi di codice già esistenti come parte del nostro lavoro di sviluppo software, il che significa che facciamo questa prova sui sistemi altrui per mestiere. I team che inseriscono in fretta non sono quelli con la documentazione migliore. Sono quelli in cui qualcuno ha ricostruito da poco il proprio ambiente e ha riparato ciò che si era rotto.

Domande frequenti

Quanto dovrebbe durare l’onboarding degli sviluppatori? Misurate il tempo fino alla prima modifica significativa in produzione, non la durata dell’accoglienza. Se serve più di una settimana, l’ostacolo raramente è la capacità. Di solito è una procedura di installazione che nessuno ha rifatto da zero di recente, oppure una base di codice i cui punti di ingresso non si trovano senza una guida.

Che cosa dovrebbe fare un nuovo sviluppatore nei primi giorni? Una modifica piccola, autentica e rilasciabile, con un utente vero che la aspetta. Leggere una base di codice senza scopo insegna poco perché manca un ancoraggio, mentre una sola modifica reale insegna dove vive il codice, come girano i test, come funziona la revisione, come avviene il rilascio e a chi va detto.

Perché configurare l’ambiente richiede così tanto tempo? Perché tutti ne hanno già uno funzionante e nessuno ricostruisce da zero da anni, così il documento scivola via. Il rimedio è far seguire quel documento alla lettera al prossimo assunto, senza cambiare nulla, e annotare ogni fallimento. Quella lista è la procedura vera, e ridurla a un solo comando le impedisce di scivolare di nuovo.

Quale documentazione conviene mantenere per l’onboarding? Come installare e avviare il sistema, come rilasciarlo, che forma ha l’architettura e perché, le decisioni che altrimenti verrebbero rimesse in discussione, e chi è responsabile di che cosa. Lasciate perdere ciò che il codice già dice, i percorsi di schermate che cambiano ogni mese e i riferimenti API scritti a mano.

Che cosa rivela su un team un onboarding lento? Che i costi assorbiti senza vederli sono reali. Tre giorni di installazione erano già pagati a piccole rate da chiunque rimettesse in piedi una macchina. Un componente che nessuno sa giustificare sta già costando decisioni. Un rilascio che solo una persona sa eseguire era un rischio anche prima che arrivasse qualcuno di nuovo.