Quando un'azienda decide di far costruire un software, la prima domanda è quasi sempre: "Quindi mi serve uno sviluppatore?". È una domanda ragionevole e incompleta. Lo sviluppatore è la figura più visibile, perché è quella che scrive il codice. Ma un software che funziona, che serve a chi lo usa e che si può mantenere negli anni è il risultato del lavoro di più funzioni, e quando una di queste manca il progetto non si ferma: peggiora in silenzio.
Questa guida è scritta per chi decide, compra o coordina un progetto senza essere un tecnico. Spiega quali sono i ruoli, cosa fa ciascuno, cosa consegna, come riconoscere che manca e quanto questo pesa sul costo. Vale per un progetto di una settimana come per uno di un anno: cambia il numero di persone, non l'elenco delle funzioni.
Ruoli e persone: una distinzione che cambia tutto
Un punto di partenza che evita molti equivoci: un ruolo non è una persona. In un'azienda grande ogni ruolo può avere un reparto. In un progetto piccolo, una sola persona può coprirne tre o quattro. Un freelance esperto è spesso analista, progettista e sviluppatore insieme. Quello che conta non è quante persone ci sono, ma se ogni funzione viene svolta da qualcuno, con attenzione e con il tempo necessario.
Il rischio tipico dei progetti piccoli è la funzione orfana: nessuno si occupa del collaudo, nessuno tiene il filo del progetto, nessuno scrive cosa è stato deciso. Non c'è cattiva volontà: ciascuno è convinto che lo faccia qualcun altro.
Panoramica: chi interviene e quando
La matrice sopra mostra una cosa che spesso sorprende: i ruoli non si danno il cambio come in una staffetta. Si sovrappongono. L'analista non sparisce dopo l'analisi, perché durante lo sviluppo emergono domande sul dominio. Il tester non aspetta la fine dello sviluppo: prepara gli scenari di prova mentre il codice viene scritto. Il project manager è presente dall'inizio alla fine.
Il committente: il ruolo di cui si parla meno
Prima dei ruoli "tecnici", c'è il ruolo di chi commissiona il lavoro. Nei libri di metodo si chiama product owner, o semplicemente referente. È la persona, interna all'azienda cliente, che:
- sa cosa serve al business e può dirlo con precisione;
- decide le priorità quando due richieste confliggono;
- risponde alle domande in tempi rapidi, perché ogni giorno di attesa è un giorno di progetto fermo;
- valida il lavoro, cioè dice "sì, questo è quello che volevo" oppure "no, manca questo".
È il ruolo che il cliente non può delegare al fornitore, e il più sottovalutato. Un progetto con un ottimo team e un referente assente tende a produrre un ottimo software per un problema leggermente sbagliato. Se in azienda nessuno ha tempo per ricoprire questo ruolo, vale la pena dirlo subito: cambia il preventivo e cambia il modo di lavorare.
Quanto tempo richiede? Per un progetto di dimensione media, un referente ben preparato dedica tipicamente qualche ora a settimana, con picchi nei giorni di collaudo. Non è un impegno enorme, ma deve essere reale e protetto.
L'analista: capire prima di costruire
L'analista (a volte chiamato analista funzionale o business analyst) è la persona che traduce il modo di lavorare dell'azienda in requisiti scritti. Ascolta chi usa i processi, osserva come si lavora davvero, individua le eccezioni che nessuno aveva menzionato e le mette per iscritto.
Cosa produce: un documento dei requisiti (anche breve), l'elenco dei processi da coprire, i casi particolari, i criteri con cui si deciderà che una funzione è "fatta".
Una domanda tipica: "Cosa succede quando un cliente annulla un ordine già spedito?". Sembra un dettaglio; spesso è la differenza tra un software usabile e uno che richiede una soluzione manuale ogni settimana.
Cosa succede se manca: si costruisce quello che il referente ricorda di aver detto, non quello che serve. I problemi emergono al collaudo, quando correggerli costa dieci volte di più.
Il progettista: decidere come è fatto
Il progettista (o architetto software) decide la struttura del sistema: quali parti lo compongono, come comunicano, dove si conservano i dati, come si proteggono, come potrà crescere. Sono decisioni con conseguenze che durano anni, e per questo conviene che le prenda chi ha già visto cosa succede quando si sbagliano.
Cosa produce: lo schema dei dati, il disegno dell'architettura, le scelte tecnologiche motivate, spesso i disegni delle schermate principali.
Una domanda tipica: "Questo sistema dovrà gestire dieci utenti o mille? Dovrà parlare con altri programmi? Dove vivranno i dati e chi li potrà vedere?". Le risposte guidano scelte che, cambiate dopo, costano molto.
Cosa succede se manca: il software cresce per aggiunte successive, senza un disegno d'insieme. Funziona, ma ogni modifica diventa più lenta e più rischiosa della precedente. È il "debito tecnico": un costo rimandato che si ripresenta con gli interessi.
Lo sviluppatore: scrivere il software e rispondere della sua qualità
Lo sviluppatore scrive il codice. Oggi, con gli assistenti basati su intelligenza artificiale, scrive più in fretta le parti ripetitive. Ma il valore di uno sviluppatore esperto non sta nella velocità di digitazione: sta nel giudizio. Sapere cosa chiedere, accorgersi quando una soluzione plausibile è sbagliata, mantenere il codice coerente e comprensibile per chi verrà dopo.
Cosa produce: il software funzionante, i test automatici che ne proteggono il comportamento, la documentazione tecnica essenziale.
Una domanda tipica: "Questa funzione è corretta anche se mancano dei dati? E se due persone la usano nello stesso momento?".
Cosa succede se è troppo junior o senza guida: il codice funziona nei casi normali e si rompe in quelli reali. Un buon sviluppatore junior, affiancato da uno senior che rivede il lavoro, è una combinazione ottima e conveniente. Lo stesso junior da solo, su un sistema che gestisce dati e processi reali, è un rischio che il preventivo non mostra.
Il ruolo è anche quello più facile da trovare e confrontare: per questo trovi su LancerJob profili con stack, esperienza e disponibilità in chiaro. Per capire come valutarli, usa la checklist di valutazione di un freelancer.
Il tester: pensare come l'utente maldestro e come il malintenzionato
Il tester (o responsabile qualità) verifica che il software faccia ciò che deve in tutte le condizioni, non solo in quelle felici. Prova a inserire date assurde, a premere due volte lo stesso pulsante, a chiudere il browser a metà operazione, a entrare dove non dovrebbe.
Cosa produce: i piani di prova, le segnalazioni di difetti, la verifica finale prima del rilascio, e spesso i test automatici che continueranno a girare nel tempo.
Una domanda tipica: "Cosa succede se il cliente ha un nome con un apostrofo, un indirizzo all'estero e un ordine da centomila articoli?".
Cosa succede se manca: il collaudo diventa i primi giorni di uso reale, con gli utenti nel ruolo di tester involontari. È il modo più costoso e più demoralizzante di scoprire i difetti.
Nei progetti piccoli il tester non è una persona diversa: è un'attitudine che lo sviluppatore deve avere, più il collaudo del referente. L'importante è che il tempo per farlo sia previsto, e non tagliato quando il progetto è in ritardo.
Il project manager: tenere insieme persone, tempi e decisioni
Il project manager non scrive codice e non progetta. Tiene insieme il progetto: pianifica, aggiorna chi deve essere aggiornato, individua i rischi, negozia le modifiche, fa emergere i problemi prima che diventino crisi. È anche l'interlocutore del cliente quando il tecnico è concentrato sul lavoro.
Cosa produce: il piano di lavoro, i resoconti periodici, l'elenco delle decisioni prese e delle modifiche richieste, la gestione di tempi e costi.
Una domanda tipica: "Questa richiesta nuova rientra nel preventivo? Se la facciamo, cosa spostiamo?".
Cosa succede se manca: nessuno governa le modifiche. Ogni richiesta sembra piccola, ma la somma sposta tempi e costi, e nessuno se ne accorge finché il budget è finito. Il costo del project manager non sparisce se lo tagli: si trasforma in ritardi e malintesi.
Gli altri ruoli, spesso decisivi
A seconda del progetto, entrano altre figure. Le più comuni:
- Progettista dell'esperienza d'uso (UX/UI). Disegna le schermate perché siano chiare per chi le usa. Decisivo quando gli utenti sono molti, non esperti o devono usare il software in condizioni difficili (in magazzino, in movimento, da tablet).
- Sistemista o specialista DevOps. Prepara e mantiene l'infrastruttura su cui il software gira: server, database, copie di sicurezza, aggiornamenti, monitoraggio. Quando manca, spesso se ne occupa a metà lo sviluppatore.
- Specialista di sicurezza. Verifica che gli accessi siano protetti, che i dati sensibili siano trattati correttamente, che il sistema resista agli attacchi più comuni.
- Esperto del dominio. Qualcuno che conosce il settore (logistica, sanità, produzione) e sa quali regole non scritte valgono. A volte è il referente del cliente, a volte un consulente.
- Responsabile dei dati. Per i progetti con molti dati storici o con integrazioni complesse, qualcuno che si occupi di pulirli, trasformarli e importarli.
Cosa succede quando un ruolo manca: una guida ai sintomi
I problemi dei progetti software hanno spesso un ruolo mancante come causa. Una tabella utile per riconoscerli:
| Sintomo | Ruolo probabilmente mancante |
|---|---|
| "Non è quello che volevamo" a fine progetto | Analista o referente del cliente |
| Ogni modifica richiede tempi sempre più lunghi | Progettista |
| Il software funziona in demo e si rompe con i dati reali | Tester |
| Tempi e costi sono sfuggiti di mano | Project manager |
| Nessuno sa come rimettere in piedi il sistema se si ferma | Sistemista |
| Utenti che evitano di usare il programma | Progettista dell'esperienza d'uso |
| Dati duplicati, incoerenti o persi | Responsabile dei dati |
Se riconosci uno di questi sintomi in un progetto in corso, la domanda utile non è "chi ha sbagliato?", ma "chi si occupa di questa funzione?". Spesso la risposta è "nessuno".
Quanto costa avere tutti i ruoli (e quanto costa non averli)
Un'idea diffusa è che i ruoli diversi dallo sviluppatore siano un lusso. I numeri dicono altro. In un progetto di dimensione media, come visto in Quanto costa sviluppare un gestionale su misura, la scrittura del codice pesa intorno al 40% del budget. Il resto è analisi, progettazione, collaudo, coordinamento, rilascio e formazione: cioè tutti gli altri ruoli.
Un progetto senza questi ruoli non costa il 60% in meno. Costa meno all'inizio e di più dopo, in tre forme riconoscibili:
- Rilavorazioni. Quello che è stato costruito sulla base di requisiti sbagliati va rifatto.
- Ritardi. Le decisioni non prese bloccano il lavoro per giorni.
- Manutenzione più cara. Un sistema senza disegno d'insieme è più lento e rischioso da modificare, per sempre.
Una regola pratica: quando un preventivo propone un prezzo molto più basso della media, chiedi quali ruoli non sono compresi. Spesso la differenza sta lì.
Come si coprono i ruoli in un progetto piccolo
Non serve una squadra di sei persone per un progetto da due mesi. Serve però organizzare le funzioni. Alcuni modi concreti:
- Un freelance senior che copre analisi, progettazione e sviluppo, con un referente interno che valida e un collaudo guidato. È la configurazione più comune e funziona bene se il perimetro è chiaro. Ne parliamo in Freelancer o agenzia: quando conviene l'uno o l'altra.
- Due professionisti con competenze complementari, per esempio uno sviluppatore e un tester/analista, che si controllano a vicenda.
- Un tutor tecnico a ore, che rivede periodicamente il lavoro di uno sviluppatore meno esperto, per un costo contenuto.
- Un'agenzia o software house, quando servono più competenze in parallelo e una struttura che garantisca continuità.
In tutti i casi, scrivi nella richiesta di progetto chi si occupa di cosa. Il modello in Come scrivere una richiesta di progetto efficace ha una sezione apposta.
Dove servono ancora le persone (anche con l'intelligenza artificiale)
Si sente dire che l'intelligenza artificiale renderà superflui molti di questi ruoli. È utile separare ciò che è vero da ciò che non lo è. Gli assistenti di programmazione accelerano la scrittura del codice ripetitivo, aiutano a redigere documentazione e a generare prime bozze di test. Questo cambia il lavoro dello sviluppatore e, in parte, il tempo che richiede.
Non cambia però la natura delle altre funzioni. Capire cosa serve a un'azienda richiede di parlare con le persone. Scegliere un'architettura richiede di conoscere i vincoli del progetto. Verificare la sicurezza richiede di sapere cosa cercare e interpretare i risultati. Coordinare richiede un interlocutore che negozi e si prenda la responsabilità delle decisioni. E qualcuno, alla fine, deve rispondere del risultato.
Per il dettaglio su cosa fa e non fa l'IA nello sviluppo, leggi L'intelligenza artificiale non scrive il software al posto tuo. La sintesi: l'IA è un acceleratore nelle mani di chi sa, non un sostituto di chi manca.
Checklist: i ruoli del tuo prossimo progetto
Prima di chiedere preventivi, rispondi per iscritto a queste domande. Se una resta senza risposta, hai trovato un ruolo scoperto.
- Chi è il nostro referente? Nome, tempo a settimana, chi lo sostituisce se è assente.
- Chi analizza i processi e scrive i requisiti? Il fornitore, noi, un consulente?
- Chi decide come è fatto il sistema? Con quale esperienza su progetti simili?
- Chi scrive il codice e chi lo rivede? Una sola persona senza revisione è un rischio.
- Chi collauda, e con quali scenari? Quanti giorni sono previsti per il collaudo?
- Chi coordina il progetto? Con quale frequenza avremo aggiornamenti?
- Chi gestisce server, copie di sicurezza e aggiornamenti dopo il rilascio?
- Chi risponde se qualcosa non funziona dopo la consegna? Per quanto tempo?
Domande frequenti
Posso fare a meno del project manager se il team è piccolo? Puoi non avere una persona a tempo pieno, ma non puoi fare a meno della funzione: qualcuno deve tenere il piano, registrare le decisioni e governare le modifiche. Nei progetti piccoli è spesso il freelance stesso, con un referente del cliente che fa da contraltare.
Mi basta un solo sviluppatore molto bravo? Per un progetto piccolo e ben definito, sì, a patto che sia bravo anche nell'ascoltare e nel documentare, e che il collaudo e le decisioni siano coperti. Un solo sviluppatore su un sistema critico, senza nessuno che controlli il lavoro, è invece un rischio di continuità.
Il referente del cliente deve essere un tecnico? No. Deve conoscere bene il processo di business e avere l'autorità di decidere. Il linguaggio tecnico lo gestisce il fornitore.
Quanti ruoli servono in un progetto da pochi mesi? Le funzioni sono sempre le stesse. Le persone possono essere due o tre. La domanda da fare è: chi si occupa di ciascuna funzione, e quanto tempo ha previsto per farlo?
Come trovo professionisti per i vari ruoli? Per la parte .NET, su LancerJob trovi sviluppatori freelance specializzati nello stack Microsoft, con profili che indicano esperienza e disponibilità. Per le altre figure puoi chiedere nella richiesta di progetto se il professionista ha già lavorato con analisti, tester o project manager e come ha coperto quelle funzioni.
In sintesi
- Un ruolo non è una persona: in un progetto piccolo una persona ne copre più, ma le funzioni restano.
- Le funzioni essenziali sono sei: referente del cliente, analisi, progettazione, sviluppo, collaudo e coordinamento. A queste si aggiungono, secondo il progetto, esperienza d'uso, infrastruttura, sicurezza e dati.
- Il ruolo più trascurato è quello del committente: senza un referente reale, il progetto deriva.
- Il codice pesa circa il 40% del budget: tagliare gli altri ruoli non fa risparmiare, sposta i costi in rilavorazioni, ritardi e manutenzione.
- L'IA accelera alcune attività dello sviluppatore, ma non sostituisce chi capisce, decide, verifica, coordina e risponde del risultato.
- Prima di chiedere preventivi, scrivi chi si occupa di cosa: è il modo più semplice di vedere cosa manca.