Una persona o un team? Come definire la composizione minima di un progetto in base a competenze, dipendenze e rischio

La ricerca non sostiene una regola semplice come "i team più piccoli sono sempre migliori" o "i team più grandi producono sempre di più".

Una meta-analisi del 2023, basata su 208 effetti indipendenti e 21.435 team, ha rilevato nel complesso una relazione praticamente nulla tra dimensione del team e prestazione sul compito, ma una forte variabilità in base al contesto. Gli autori mostrano che il peso della dimensione cambia, tra l'altro, con la complessità del compito e le esigenze di coordinamento. [4]

Un esperimento su un compito complesso di mappatura di crisi ha mostrato contemporaneamente benefici e costi dei team più grandi: la collaborazione aumentava con la dimensione, mentre cambiavano i modelli di impegno individuale. In quello specifico esperimento, i team più grandi hanno superato un numero equivalente di persone che lavoravano in modo indipendente. Non è una ricetta universale per ogni tipo di lavoro. [5]

La conclusione pratica è semplice: il numero di persone deve derivare dalla natura del lavoro, non da una cifra magica.

La Scrum Guide del 2020 descrive lo Scrum Team come piccolo, interfunzionale e autogestito. Indica inoltre che in genere comprende 10 persone o meno. [3]

È un'indicazione utile nel contesto di Scrum, ma non una legge universale per tutti i progetti, servizi, settori o modelli di lavoro.

Un progetto edilizio, una campagna di marketing, una verifica di sicurezza, un sistema finanziario e un piccolo sito informativo hanno esigenze molto diverse. Un unico numero non dovrebbe essere trasferito direttamente tra questi contesti.

Il Service Standard britannico richiede che i team dei servizi digitali siano multidisciplinari e abbiano accesso a un insieme adeguato di competenze. Specifica inoltre che la composizione deve dipendere da ciò che il team deve ottenere nella fase considerata. [1]

Un'altra guida GOV.UK afferma che dimensione del team e ruoli necessari cambiano durante le diverse fasi di costruzione del servizio. [2]

Ne deriva una regola pratica:

prima descrivi il lavoro e le responsabilità, poi individua le competenze e solo alla fine assegna le persone specifiche.

Non è possibile dimensionare un team su un ambito poco chiaro.

Annota almeno:

• quale risultato deve essere prodotto,
• cosa rientra nell'ambito,
• cosa ne resta fuori,
• quali requisiti di qualità sono più importanti,
• quali vincoli di tempo e budget esistono,
• chi accetterà il risultato,
• se il team deve soltanto consegnare la soluzione o anche gestirla.

Un progetto "creare un'applicazione" e un progetto "progettare, creare, proteggere, distribuire e gestire un'applicazione per un anno" richiedono una copertura del lavoro completamente diversa.

Invece di assegnare subito ruoli, elenca i tipi di lavoro che devono realmente essere svolti.

Per un servizio digitale possono includere:

• comprendere le esigenze degli utenti,
• progettare la soluzione,
• realizzare la parte visibile agli utenti,
• sviluppare logica e integrazioni lato server,
• testare,
• sicurezza,
• accessibilità,
• distribuzione e gestione operativa,
• coordinamento di ambito e decisioni.

Un altro tipo di progetto avrà una lista diversa.

GOV.UK afferma che un team che crea e gestisce un servizio digitale deve disporre di un insieme ampio di competenze, comprese esigenze degli utenti, progettazione, realizzazione, test, sicurezza, distribuzione e gestione operativa. [2]

Non ogni competenza necessaria richiede una persona a tempo pieno nel team.

Per ogni area classifica il bisogno:

Permanente - necessario regolarmente e direttamente coinvolto nelle decisioni quotidiane.
Periodico - necessario in fasi o punti di controllo specifici.
Disponibile esternamente - può essere fornito da un'altra persona o team se tempi di risposta e responsabilità sono sufficientemente chiari.

GOV.UK ammette esplicitamente che il team abbia accesso a competenze specialistiche senza che lo specialista sia necessariamente un membro permanente. [1]

Questo spesso evita di ingrandire artificialmente il team senza perdere competenze importanti.

Due persone possono possedere insieme tutte le competenze necessarie e formare comunque una configurazione debole se tutto il lavoro è disposto in una stretta catena di dipendenze.

Verifica:

• quali attività possono procedere in parallelo,
• quali devono aspettare altre attività,
• chi prende decisioni che bloccano il lavoro successivo,
• da quali team o fornitori esterni dipende il progetto,
• dove l'assenza di una persona fermerebbe più aree contemporaneamente.

GOV.UK include la gestione delle dipendenze da altri team tra le capacità necessarie per creare servizi digitali. [2]

Quando più team lavorano su un servizio, aumenta anche il bisogno di coordinare piani e avanzamento tra i team. [8]

Alcune competenze necessarie non sono visibili in un elenco di funzionalità, ma la loro assenza può essere costosa.

A seconda del progetto possono riguardare:

• sicurezza,
• protezione dei dati,
• accessibilità,
• requisiti legali o di settore,
• affidabilità,
• migrazione dei dati,
• integrazioni con sistemi critici,
• tecnologie mai usate prima dal team.

GOV.UK raccomanda accesso a competenze specialistiche quando il progetto ne ha bisogno e afferma che la composizione dovrebbe riflettere anche le ipotesi più rischiose della fase corrente. [1]

Questo non richiede automaticamente un ruolo a tempo pieno per ogni rischio. Significa però che una persona competente deve avere una responsabilità esplicita e una reale possibilità di influenzare le decisioni.

Una persona può conoscere progettazione, sviluppo, test e distribuzione. Non significa che possa svolgere tutti questi tipi di lavoro contemporaneamente con qualsiasi scadenza.

Il materiale PMI sulla pianificazione delle risorse sottolinea l'importanza di allineare competenze, disponibilità, costo ed esperienza alle esigenze del progetto. [7]

Per ogni persona verifica:

• quanto tempo può davvero dedicare,
• quali attività competono per la sua attenzione,
• se il lavoro richiesto deve procedere in parallelo,
• se la scadenza presuppone passaggi irrealistici tra molti tipi di lavoro,
• se qualcuno deve continuare a gestire la soluzione dopo il lancio.

Coprire le competenze senza coprire il tempo disponibile non significa coprire tutto il progetto.

La composizione minima dovrebbe considerare anche la continuità.

Chiediti:

• cosa succede se una persona chiave non è disponibile,
• se solo una persona comprende una parte critica della soluzione,
• se decisioni e conoscenze sono documentate,
• se qualcun altro può assumere i compiti più importanti,
• se il progetto può fermarsi in sicurezza durante un'assenza.

Non tutti i piccoli progetti richiedono ridondanza completa. In un progetto breve e a basso rischio, accettare consapevolmente questo rischio può essere ragionevole.

In un progetto critico, la stessa dipendenza da una sola persona può essere inaccettabile.

Un progetto non richiede una persona diversa per ogni etichetta di ruolo.

Se una persona possiede davvero le competenze necessarie, ha capacità sufficiente e non crea un rischio inaccettabile, può coprire responsabilmente più aree.

Per esempio, in un piccolo progetto una persona può unire progettazione dell'interfaccia e realizzazione. In un altro, può combinare analisi di business e coordinamento dell'ambito.

Non unire responsabilità solo perché "qualcuno deve farlo". La combinazione ha senso soltanto se la persona può svolgere entrambe al livello richiesto e ha abbastanza tempo.

Una persona può essere una configurazione razionale quando tutte queste condizioni sono vere:

• l'ambito è piccolo e ben definito,
• le competenze necessarie rientrano davvero nelle sue capacità,
• le attività richiedono poco lavoro parallelo,
• le dipendenze esterne sono limitate,
• il rischio è accettabile,
• la scadenza corrisponde alla capacità reale,
• l'assenza di sostituzione è accettata consapevolmente.

Può trattarsi di un piccolo materiale informativo, una semplice analisi, una consulenza una tantum o un'implementazione limitata in un ambiente noto.

Dipende comunque dall'ambito concreto. L'etichetta "piccolo progetto" non decide da sola.

Un team diventa più giustificato quando compaiono diverse di queste condizioni:

• le competenze necessarie sono troppo ampie per una persona,
• molte attività devono procedere in parallelo,
• la scadenza è più breve di una realistica esecuzione sequenziale,
• il progetto ha molte dipendenze e interfacce,
• il rischio richiede conoscenze specialistiche indipendenti,
• la soluzione deve essere costruita e gestita contemporaneamente,
• una persona diventerebbe un punto critico per l'intero progetto,
• la responsabilità comprende discipline molto diverse.

In queste condizioni, aggiungere capacità mancanti conta più che aumentare semplicemente il numero di persone.

Aggiungere persone aumenta il patrimonio di conoscenze e la capacità potenziale, ma può anche aumentare dipendenze, passaggi di lavoro e necessità di allineare le decisioni.

Uno studio di progetti software pubblicato nel Journal of Systems and Software ha mostrato che le relazioni tra dimensione del team, produttività, sforzo e tempo sono complesse e non sempre corrispondono alle aspettative intuitive. [6]

Anche la meta-analisi sulla dimensione dei team mostra che i risultati dipendono dal contesto dell'attività e dai costi dei processi di gruppo. [4]

La domanda quindi non è "quante persone possiamo aggiungere?", ma "la prossima persona elimina un vincolo reale del progetto più di quanto aumenti il costo di coordinamento?"

Non tutte le competenze importanti devono essere presenti ogni giorno.

La presenza permanente ha più senso quando la persona prende regolarmente decisioni, il suo lavoro ha molte dipendenze con altre aree o è necessaria una risposta rapida.

Il supporto periodico può essere sufficiente quando la competenza serve in momenti specifici, ad esempio per revisione, consulenza, valutazione dei rischi o approvazione specialistica.

C'è una condizione: la disponibilità deve essere reale, non nominale. Deve essere chiaro:

• chi è responsabile,
• quando è disponibile,
• quale tempo di risposta è previsto,
• quali decisioni può prendere,
• cosa succede se individua un problema.

L'accesso a uno specialista senza responsabilità definita può sembrare positivo in un organigramma e non funzionare nel progetto reale.

Supponiamo che l'obiettivo sia lanciare un sistema di prenotazione online.

Variante A: prototipo semplice per testare l'idea
L'ambito è limitato, non ci sono pagamenti né dati particolarmente sensibili e l'obiettivo è testare il processo con un piccolo gruppo di utenti. Una persona versatile potrebbe coprire progettazione e realizzazione, con consulenza periodica se necessaria.

Variante B: servizio pubblico con account, pagamenti e integrazioni
Aumentano specializzazione, test, rischio, dipendenze e lavoro parallelo. Un team di più persone diventa molto più giustificato.

Variante C: servizio sempre attivo che richiede risposta rapida ai problemi
Alla costruzione si aggiungono gestione operativa, monitoraggio, risposta agli incidenti e continuità della conoscenza. La composizione necessaria per il lancio potrebbe non bastare per un funzionamento sostenibile.

È lo stesso tipo generale di prodotto, ma ambito, rischio e modello operativo diversi generano esigenze di team diverse.

1. Parti da un elenco pronto di ruoli invece che dal lavoro da svolgere.

2. Presumi che ogni ruolo richieda una persona separata.

3. Guardi solo le competenze e ignori il tempo disponibile.

4. Aggiungi persone senza eliminare dipendenze e colli di bottiglia.

5. Ignori competenze determinate dal rischio perché non producono una funzione visibile.

6. Fai dipendere diverse aree critiche da una sola persona senza accettare consapevolmente il rischio.

7. Tratti la composizione iniziale come fissa fino alla fine del progetto.

GOV.UK afferma esplicitamente che dimensione e ruoli del team cambiano durante le diverse fasi di sviluppo del servizio. [2]

È un principio ragionevole anche fuori dai servizi pubblici:

• all'inizio possono servire più ricerca e definizione del problema,
• durante la realizzazione aumentano le esigenze di esecuzione e test,
• prima del lancio possono crescere le necessità di sicurezza, qualità e preparazione operativa,
• dopo il lancio cambia l'equilibrio tra sviluppo e gestione.

La composizione minima dipende dalla fase e dall'ambito, non è un numero fisso assegnato al progetto per sempre.

Per ogni area importante annota cinque elementi:

Area di lavoro - cosa deve essere fatto?
Competenza - quale conoscenza e abilità servono?
Responsabilità - chi decide e risponde del risultato?
Disponibilità - la competenza è permanente, periodica o esterna?
Rischio di assenza - cosa succede se la competenza manca o la persona non è disponibile?

Solo dopo assegna persone specifiche.

Se una persona copre più righe, controlla tempo e dipendenze. Se una riga richiede più persone, verifica se il motivo è capacità, controllo indipendente o lavoro parallelo.

1. Ogni area di lavoro obbligatoria ha un responsabile?
2. Ogni responsabilità critica ha una persona con la competenza corretta?
3. Qualcuno copre più ruoli e dispone davvero di tempo sufficiente?
4. Il progetto richiede lavoro parallelo che la composizione attuale non può sostenere?
5. Conosciamo le principali dipendenze da altre persone, team e fornitori?
6. I rischi importanti hanno accesso alla giusta competenza specialistica?
7. L'assenza di una persona può fermare l'intero progetto?
8. La composizione è sufficiente non solo per costruire, ma anche per lanciare e gestire la soluzione se ciò rientra nell'ambito?
9. Sappiamo quali competenze possono essere periodiche invece che permanenti?
10. Abbiamo definito momenti in cui rivalutare la composizione dopo cambi di ambito o fase?

La progettazione del team non dovrebbe iniziare con:

"quante persone servono di solito per un progetto come questo?"

Un ordine migliore è:

risultato -> lavoro -> competenze -> dipendenze -> rischio -> capacità -> persone.

Se dopo questa analisi una sola persona copre davvero tutto, una persona può essere la scelta corretta.

Se mancano competenze, tempo, verifica indipendente, continuità o possibilità di lavoro parallelo, servono altre persone o accesso affidabile a specialisti.

L'obiettivo non è il team più piccolo. L'obiettivo è la composizione più piccola che possa realisticamente fornire il risultato richiesto al livello di rischio e qualità necessario.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Apri fonte

[2] GOV.UK Service Manual - Set up a service team at each phase
Apri fonte

[3] The Scrum Guide, 2020 - Scrum Team
Apri fonte

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
Apri fonte

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Apri fonte

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Apri fonte

[7] Project Management Institute - Solving The Resource Puzzle
Apri fonte

[8] GOV.UK Service Manual - Running more than one service team
Apri fonte

Nota metodologica: alcune fonti riguardano servizi pubblici digitali, altre team Scrum, gestione dei progetti o ricerca sui team e sullo sviluppo software. Questa guida usa ogni fonte solo per i punti che realmente supporta. Il metodo in sette passi è una sintesi editoriale di questi principi, non uno standard formale delle organizzazioni citate.