Un team non è la somma dei titoli
Per anni il mondo software ha descritto i team attraverso ruoli abbastanza standard: Product Owner, Project Manager, designer, frontend developer, backend developer, architect. Questi titoli sono utili per capire di che competenze stiamo parlando, ma diventano un problema quando vengono trattati come la struttura obbligatoria di ogni progetto.
Un tool interno circoscritto, un nuovo prodotto da validare e un gestionale con integrazioni critiche hanno bisogno di macchine diverse. Mettere cinque persone dove una può seguire bene il problema aggiunge passaggi. Pretendere che una sola persona governi architettura, sicurezza e complessità che richiedono specializzazione crea invece fragilità.
La domanda utile non è quindi "quali ruoli dobbiamo avere?", ma "quali responsabilità devono essere presidiate in questo progetto?".
Le responsabilità che non possono sparire
Qualcuno deve capire il dominio e il risultato che il software deve produrre. Qualcuno deve trasformare quel problema in decisioni di prodotto e di esperienza. Qualcuno deve costruire e mantenere il sistema. Quando la complessità lo richiede, servono competenze più profonde su architettura, dati, integrazioni, performance, sicurezza e infrastruttura.
Serve inoltre un sistema decisionale: priorità, trade-off e dubbi devono arrivare alle persone che hanno il contesto per scioglierli. Il coordinamento non è un ruolo obbligatorio in sé; è una responsabilità che cresce quando aumentano persone e dipendenze.
Queste responsabilità possono essere distribuite su molte persone oppure concentrate in poche. Il progetto decide la forma.
L'AI cambia la forma del team, non elimina le responsabilità
L'AI ha reso una singola persona molto più produttiva in attività che prima richiedevano più passaggi: analisi, prime interfacce, codice, test, documentazione e prototipi. Questo rende possibili squadre più leggere in progetti che qualche anno fa non avrebbero retto economicamente.
Allo stesso tempo, l'AI non rende irrilevanti contesto, review e responsabilità. Un errore sui permessi, sui dati o su un'integrazione critica continua ad avere conseguenze anche se il codice è stato prodotto in pochi minuti.
Per questo una squadra può partire molto corta e coinvolgere sviluppatori nelle review o nei punti critici. Se il progetto cresce, cresce anche la profondità tecnica necessaria.
Il cliente è parte del sistema decisionale
Il cliente non deve stare fuori dal team aspettando che qualcuno traduca per settimane le sue richieste. Chi conosce il processo deve poter vedere cosa sta succedendo, provare il software e partecipare alle decisioni quando sono ancora facili da cambiare.
Questo non significa assegnargli un titolo formale di Product Owner. Significa dargli accesso al contesto: cosa stiamo cercando di ottenere, quali alternative stiamo valutando e quali conseguenze hanno le scelte.
In alcuni progetti questa vicinanza produce anche un effetto ulteriore: le persone del cliente possono acquisire una parte della capacità necessaria per far evolvere direttamente il software.
Come componiamo il team in BitBoss
Partiamo dal problema e dal livello di rischio. Alcuni progetti consentono un setup leggero, con una persona di prodotto molto vicina al cliente e sviluppatori che entrano in review e nei passaggi critici. Altri richiedono un team strutturato fin dall'inizio. Nei contesti regolati o molto complessi, più documentazione, specializzazione e controllo sono semplicemente necessari.
Il punto comune non è Scrum, un organigramma o una cadenza fissa. Sono i principi: software vero il prima possibile, cliente dentro alle decisioni, iterazione e uno standard tecnico che permetta al prodotto di essere capito e fatto evolvere anche quando la squadra cambia.
