Come inserisci i nuovi ingegneri in modo efficace?

Question

Accepted Answer

Un buon onboarding rende un nuovo ingegnere **produttivo e fiducioso rapidamente**, mentre lo fa sentire benvenuto. Un pessimo onboarding spreca settimane e comunica "sei da solo". Un po' di struttura ripaga enormemente.

## Un checklist di onboarding

```text
WEEK 1  — environment runs, first tiny PR merged, knows who's who
WEEK 2-3 — owns a small real task end to end
MONTH 1 — comfortable in the core codebase and workflow
MONTH 2-3 — contributing independently on normal work

Provide: a buddy, a written setup guide, a starter task list,
and a clear "who to ask about what" map.
```

## Un esempio concreto

Assegna un bug piccolo, reale, a basso rischio nel primo o secondo giorno, non una grande feature, non un lavoro inutile. Rilasciare qualcosa di reale nella prima settimana costruisce fiducia e insegna l'intera pipeline (build, review, deploy) in miniatura.

## Assegna un buddy

Accoppia ogni nuovo arrivato con un buddy che risponda alle domande "sciocche" senza giudizio. Riduce il carico su di te e dà al nuovo una persona sicura a cui chiedere, il che accelera notevolmente la rampa.

## Un pericolo

Non gettarli sulla parte più difficile del sistema per primo, e non lasciare che la documentazione marcisca. Ogni nuova assunzione è un controllo gratuito del tuo onboarding, correggi quello che li ha bloccati.

## Perché è importante

Le prime settimane modellano come una persona si sente riguardo al team e quanto velocemente contribuiscono.

Un buon onboarding trasforma un'assunzione in un contributore in settimane invece che in mesi, e la documentazione che costruisci aiuta tutti dopo di loro.