Come capire se il tuo sviluppatore fa bene il lavoro (anche se non sei tecnico)
Sette segnali concreti per valutare se il tuo dev sta lavorando bene, anche se non sai leggere il codice. Nessun gergo tecnico, nessuna fiducia cieca.
Hai assunto uno sviluppatore o ti sei affidato a un freelance, e adesso ti chiedi se sta facendo bene. Non sai leggere il codice, quindi non puoi giudicarlo direttamente. Eppure devi decidere: continuare a pagarlo, sostituirlo, intervenire. Questa guida ti dà sette segnali concreti per capirlo, anche se di tecnica non sai niente.
Importante: tutti questi segnali sono verificabili da chiunque, non servono competenze tecniche. Se anche tre o quattro sono rossi, è il momento di fare una valutazione esterna.
1. Commit settimanali visibili
Sul repository del codice (GitHub, GitLab) si vede ogni modifica fatta. Si chiamano "commit". Un dev che lavora produce commit ogni 2-5 giorni in media. Se passa una settimana senza commit, qualcosa non sta succedendo — o il dev non sta lavorando, o sta lavorando offline e accumulando senza condividere (rischio enorme).
Cosa fare: chiedi accesso read-only al repository. Guarda la frequenza dei commit nelle ultime 4 settimane. Niente da 14+ giorni è un red flag.
2. Deploy in produzione regolari
Il codice scritto vale zero finché non è in produzione. Un team sano fa deploy almeno una volta a settimana, idealmente ogni 2-3 giorni. Se sono mesi che "è quasi pronto" ma non vedi mai nulla di nuovo nell'app, hai un problema.
Cosa fare: chiedi al dev di mostrarti oggi, su una call, la versione live (non in locale). Se rifiuta o dice "te lo faccio vedere la settimana prossima", è un segnale forte.
3. Risposta alle tue domande senza rigirarle
Un dev competente risponde "sì, posso farlo in 3 giorni" oppure "no, perché X, ma posso fare Y in alternativa". Un dev in difficoltà risponde "dipende, vediamo, aggiorniamoci", o sposta sempre la conversazione su aspetti tecnici che non capisci per non darti una risposta concreta.
Cosa fare: la prossima volta che chiedi una stima, conta i giorni che ci mette a darti una risposta concreta. Se più di 48 ore, hai un problema di seniority o motivazione.
4. Documentazione del lavoro
Un dev senior scrive cose. Non per piacere — per non riscrivere a memoria ogni tre settimane. Cerca: un README sul progetto, note tecniche su Notion/Confluence, decisioni architetturali scritte da qualche parte. Se non c'è nulla, sappi che il giorno in cui il dev sparisce hai perso tutto.
Cosa fare: chiedi "dove sta documentato come si fa un deploy?" Se non sa rispondere o ti manda via WhatsApp un audio di 5 minuti, la risposta è: non è documentato.
5. Test che girano (anche se non sai cosa siano)
I "test automatici" sono codice che verifica automaticamente che altri pezzi di codice funzionino. Un progetto serio ne ha. Un dev junior te li scrive all'ultimo (o mai). Un dev senior li scrive durante il lavoro.
Cosa fare: chiedi direttamente "quanti test ha il progetto?" e "quando li avete eseguiti l'ultima volta?". Non importa se la risposta è tecnica — importa quanto velocemente la dà. Se ci pensa, è meglio non avere test che averli scritti male.
6. Coraggio di dirti no
Questo è il segnale più importante e il più ignorato. Un dev che ti dice sempre "sì, possiamo farlo" è un esecutore mediocre, non un partner tecnico. Un dev che ti dice "questa feature non ha senso, perché X" ti sta salvando settimane di lavoro inutile.
Cosa fare: ricorda l'ultima volta in cui il tuo dev ti ha detto di no. Se non te la ricordi, hai un esecutore puro. Va bene per fare cose già definite. Non va bene per costruire un prodotto.
7. Owner di niente sensitive
Questo non è un segnale di qualità tecnica, è di sicurezza aziendale. Tu devi essere owner di: repository, hosting, dominio, account Stripe, account cloud. Il dev ha accesso come collaboratore, mai come proprietario.
Se invece il dev è registrato come owner di queste cose, devi rimediare oggi. Non perché il tuo dev è disonesto — perché stai costruendo un punto di fallimento da cui non puoi riprenderti se lui sparisce.
Cosa fare se 3+ segnali sono rossi
La tentazione è licenziare e cercare un altro freelance. Pessima idea. Non sai se il problema è il dev, lo scope, le specifiche, o il codice ereditato. Senza una valutazione esterna stai rischiando di ripetere lo stesso errore col prossimo.
Quello che ha senso fare:
- Audit tecnico esterno indipendente: 2-3 giorni, costo limitato, report scritto su cosa funziona, cosa non funziona, e dove sta il problema. Ne ho parlato nella pagina audit tecnico software.
- Sulla base dell'audit, decidi: tieni il dev e lo affianchi a un riferimento tecnico, lo sostituisci, o riscrivi parti specifiche.
- Mai più mettere fiducia cieca. Imposta da subito i 7 segnali sopra come routine settimanale.
Riassumendo
Non serve essere tecnici per capire se il tuo sviluppatore sta facendo bene. Bastano 7 segnali pratici, verificabili da chiunque:
- Commit settimanali visibili.
- Deploy in produzione regolari.
- Risposta diretta alle tue domande.
- Documentazione scritta del lavoro.
- Test automatici presenti.
- Coraggio di dirti no quando serve.
- Owner di niente che è tuo.
Se 3+ di questi sono rossi, non aspettare. Un audit tecnico esterno ti costa una piccola frazione di quello che rischi se continui sulla strada sbagliata. Vuoi un confronto sulla tua situazione? Parliamone in 30 minuti, ti rispondo entro 24 ore.