10 prerequisiti di scalabilità da conoscere prima di crescere
Preparati, perché sto per dirti la dura verità sulla scalabilità.
Cominciamo facendo chiarezza sullo scaling nel business:
La maggior parte dei tentativi di scalare fallisce.
Quindi, qual è il segreto? Come si scala con successo un team e perché è così difficile?
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Se lavori da tempo nello sviluppo software, probabilmente hai già vissuto questo incubo:
- Al cliente vengono promesse tantissime funzionalità in tempi irrealistici (che nessuno ha il coraggio di mettere in discussione).
- Quando la scadenza è ormai pericolosamente vicina, qualcuno in posizione di comando decide di aggiungere altri team al progetto per rispettare la deadline.
- Le cose iniziano a crollare.
Ti suona familiare?
In questo articolo ti spiegherò cosa devi fare per evitare nuovamente questa situazione da incubo (o, se sei stato abbastanza fortunato da non averla ancora vissuta, per evitarla del tutto).
Le mie riflessioni in questo articolo provengono dall’esperienza nello scalare team di sviluppo software, ma puoi applicare la teoria fondamentale anche allo scaling di un’azienda o alla crescita di un team in qualsiasi settore. Troverai queste informazioni utili anche se stai adottando uno dei framework di scaling “chiavi in mano” come Large Scale Scrum (LeSS), Scrum@Scale, SAFe.
Questo perché metto l’accento su diversi aspetti importanti della scalabilità che non vengono mai menzionati in quelle metodologie: la verità fondamentale sulla natura dello scaling che spesso viene dimenticata o ignorata.
La Legge Fondamentale della Scalabilità
La Legge Fondamentale della Scalabilità è un’osservazione empirica su ciò che accade nei progetti quando si aumenta la scala:
Lo scaling amplifica il negativo e rende il positivo più difficile da ottenere.
La formulazione è mia, ma non sono né l’unico né il primo ad aver avuto questa intuizione.
Vediamo cosa significa questa Legge nella pratica con alcuni esempi relativi alla scalabilità.
1. Esempio: Comunicazione e Scalabilità
Il primo e più ovvio è la comunicazione. È risaputo che quando aumenta il numero di persone in un progetto, crescono anche i canali di comunicazione. Se i canali di comunicazione non sono già efficienti dall’inizio, scalare aggraverà il problema.
Al contrario, se i canali di comunicazione funzionano bene all’inizio, scalare introdurrà comunque delle nuove sfide, non solo per il crescente numero di persone ma anche per la loro distribuzione. Spesso i nuovi team vengono creati in sedi diverse, costringendo a cambiare i canali di comunicazione—ad esempio, passando dagli incontri di persona alle videoconferenze o sostituendo una lavagna a muro con uno strumento elettronico.
2. Esempio: Continuous Integration/Continuous Delivery e Scalabilità
Possiamo osservare la Legge Fondamentale della Scalabilità anche nelle pipeline di Continuous Integration (CI) e Continuous Delivery (CD). Quando c’è un solo team, il tutto è relativamente semplice.
Passando da uno a due team, i sistemi di CI e CD diventano notevolmente più complessi—di solito, quando ci sono n team, il numero di pipeline CI tende a essere n+1 (una pipeline per ciascun team, più una per l’integrazione). Questo ha delle ovvie ripercussioni sulla fornitura degli ambienti e sul coordinamento tra team.
3. Esempio: Cicli di Feedback e Scalabilità
Un ultimo esempio: i cicli di feedback. Nei progetti più grandi, i cicli di feedback si allungano. Perciò, migliorare il sistema in modo iterativo diventa molto più difficile, aumentando le probabilità di costruire il prodotto sbagliato.
Questi sono solo tre esempi delle sfide introdotte dallo scaling. Sono certo che tu stesso potrai individuarne molte altre.
Siccome supponiamo che tu sia disposto ad accettare i compromessi necessari, la prossima cosa di cui hai bisogno è che il tuo progetto soddisfi alcune condizioni fondamentali per poter dimostrare la propria scalabilità.
10 Prerequisiti per Scalare
Che tu abbia o meno un business, un progetto o un team scalabile dipende da diversi prerequisiti che trovi elencati qui sotto. Se soddisfi questi prerequisiti, allora la scalabilità sarà elevata. Al contrario, se anche solo uno di questi viene a mancare, le probabilità di fallimento aumentano drasticamente.
1. La Presenza di Obiettivi Chiari e Condivisi
Dovrebbe essere scontato, ma per esperienza posso dire che l’assenza di obiettivi chiari e condivisi è molto comune. Senza questi, i team tenderanno a muoversi in direzioni diverse, rendendo più difficile la realizzazione di soluzioni utili.
2. L’Uso di Metriche Appropriate
Più grande è il progetto, più è importante essere in grado di misurare l'impatto delle decisioni prese. Ad esempio, l'aggiunta di un nuovo team ha migliorato la capacità del progetto di consegnare? Stiamo spingendo i team così tanto che la qualità sta diminuendo? I team lavorano bene insieme, oppure si ostacolano a vicenda?
3. Un'Architettura Adeguata
Se la “forma” del sistema non corrisponde alla struttura dei team, aggiungere più team peggiorerà soltanto la situazione. Questo è un effetto diretto della Legge di Conway, un'osservazione empirica ben nota che è stata provata nella pratica.
4. Disponibilità di Competenze Manageriali e Tecniche
I problemi dovuti alla mancanza di competenze avranno un effetto negativo amplificato man mano che il progetto cresce.
5. Buoni Canali di Comunicazione
Più persone sono coinvolte, più comunicazione avviene. Un'espansione di successo richiede una comunicazione efficiente.
6. Buona Pianificazione e Definizione delle Priorità
La mancanza di un'adeguata pianificazione e definizione delle priorità, secondo la mia esperienza, è un fattore molto comune nelle cause di fallimento dei progetti. In particolare, quando sono coinvolti più team, le attività di prioritizzazione e pianificazione devono prevedere misure per mitigare gli effetti di ritardi e mancate sincronizzazioni.
7. Buona Raccolta e Gestione dei Requisiti
Questo va di pari passo con la pianificazione e la definizione delle priorità. Inoltre, l'effetto di requisiti errati, fraintesi o non necessari sarà amplificato man mano che cresce il numero dei team.
8. Lavoro di Alta Qualità
Più grande è il progetto, più grande sarà l'effetto negativo della cattiva qualità. In alcuni scenari patologici (e comuni), alcuni bug possono diventare funzionalità, poiché i cicli di feedback per correggerli possono essere così lunghi che altri team potrebbero aver già progettato soluzioni alternative per neutralizzarli.
9. Disponibilità di Risorse
Più team richiedono più scrivanie, computer, strumenti e ambienti.
10. Automazione Implacabile
Ogni attività manuale costituisce un collo di bottiglia i cui effetti peggiorano con l’aumentare delle persone e dei team. Un caso (molto comune): le attività di test manuali per garantire che non siano state introdotte regressioni prima di una release in produzione. Nella mia esperienza questo rappresenta uno dei maggiori colli di bottiglia in tutti i progetti, ma in particolare nei progetti con più di un team.
Attenzione alla Scalabilità Prematura
La scalabilità è in cima ai pensieri di startup e imprenditori seriali — e hanno sicuramente qualche lezione da insegnarci sulla scalabilità prematura.
Se tenti di scalare prima di aver veramente soddisfatto i prerequisiti per scalare con successo un'azienda, un team o un'organizzazione, ottieni quello che la comunità delle startup chiama "scalabilità prematura".
Una semplice definizione di scalabilità prematura dell’imprenditore seriale Jim Pitkow:
Scalabilità prematura: crescere in previsione della domanda invece che per una crescita guidata dalla domanda.
Infatti, scalare in modo corretto richiede tempo — e la vera scalabilità è guidata da un reale bisogno dovuto alla domanda, non da una nozione imposta artificialmente di dover semplicemente diventare più grandi e fare più cose velocemente.
La comunità delle startup offre alcune lezioni che possiamo applicare ai nostri team e progetti quando riflettiamo se sia davvero arrivato il momento di scalare. Ecco alcune statistiche dal Startup Genome Report Extra on Premature Scaling:
- Le startup che scalano correttamente impiegano il 76% di tempo in più per crescere nella loro dimensione rispetto a quelle che scalano prematuramente.
- Il 74% delle startup internet ad alta crescita fallisce a causa della scalabilità prematura.
- Le startup che scalano correttamente crescono circa 20 volte più velocemente di quelle che scalano prematuramente.
Se sei interessato ad altre statistiche sull'imprenditorialità, dai un'occhiata al nostro studio sugli stati più imprenditoriali d'America.
Sei Davvero Pronto a Scalare?
Se il tuo progetto è ben gestito e soddisfa i prerequisiti sopra, la prossima domanda da porsi è:
“Quanti team possono contribuire produttivamente?”
Risponderemo a questa domanda nella prossima sezione.
Qual è il Limite della Scalabilità? Le Leggi di Brooks e di Amdahl
È un fatto ben noto che aggiungere più persone a un progetto software non aumenta necessariamente la produttività.
In realtà, nella maggior parte dei casi, aggiungere più persone causerà un grave calo della produttività.
Fred Brooks fece questa osservazione nel suo libro The Mythical Man Month, nota come Legge di Brooks:
“Aggiungere personale a un progetto software in ritardo lo fa ritardare ancora di più […] Il numero di mesi di un progetto dipende dai suoi vincoli sequenziali. Il numero massimo di persone dipende dal numero di sottocompiti indipendenti. Da queste due quantità si possono derivare pianificazioni utilizzando meno personale e più mesi […]. Tuttavia, non è possibile ottenere pianificazioni fattibili utilizzando più persone e meno mesi.”
La seconda parte della citazione sopra è, a mio avviso, la più interessante. In effetti, è fondamentalmente la versione descrittiva di la Legge di Amdahl—una formula che fornisce l'incremento massimo teorico della velocità di un sistema concorrente:
La Legge di Amdahl
Speedup = 1 / (s + p / n )
Dove:
s = percentuale di attività seriali
p = percentuale di attività in parallelo
s + p = 1
n = numero di processori (team, nel nostro caso)
In pratica, un progetto con più team è una sorta di sistema concorrente in cui ogni team è un'unità di elaborazione. In sostanza, la Legge di Amdahl afferma che la quantità massima di lavoro concorrente è limitata dalla quantità di lavoro sequenziale che deve essere eseguito.
In parole semplici, ciò significa che le cose che devono essere svolte in un determinato ordine porranno dei limiti alla quantità di attività che i team possono svolgere contemporaneamente.
Cosa Si Intende per Lavoro Sequenziale in un Contesto di Sviluppo Software?
Potresti chiederti quale tipo di lavoro sia costituito da attività sequenziali che influiscono sui team di sviluppo software.
Ecco alcuni esempi (sono sicuro che te ne verranno in mente molti altri):
- Qualsiasi lavoro sulle pipeline di integrazione e deployment
- Unione di modifiche software in codice condiviso da diversi team
- Qualsiasi tipo di sincronizzazione—ad esempio, un team che dipende dai deliverable di un altro prima di poter proseguire il lavoro
- Attesa per la fornitura delle risorse
Applicazione della Legge di Amdahl alla Scalabilità dei Team
Il grafico seguente mostra le implicazioni della Legge di Amdahl quando si aumenta il numero di team rispetto alla produttività.
Si può notare che la produttività aumenterà in modo sub-lineare con l'incremento del numero di team—fino a un picco, dopo il quale inizierà nuovamente a diminuire.
Un'illustrazione della Legge di Amdahl: la velocità di consegna aumenta con il numero di team, ma solo fino a un certo punto—che di solito non è quello che i manager si aspettano.
Se dovessi ricordare una sola cosa di questo articolo, questa è la più importante:
Aumentare il numero di team può aumentare la produttività—ma solo fino a un certo punto.
Quindi, Qual è il Numero Ideale di Team per un Progetto?
Purtroppo, non esistono formule che permettano di calcolare in anticipo il numero ideale di team per un dato progetto. L'unico modo è utilizzare un insieme di metriche di progetto per misurare parametri come la produttività e la qualità, e osservare cosa succede aggiungendo o rimuovendo dei team. Il mio consiglio è di iniziare in piccolo, con un solo team di 3-6 persone, e aumentare solo quando e se necessario.
A un certo punto, potresti scoprire di aver già raggiunto il numero massimo di team, ma il progetto potrebbe comunque non essere in grado di rispettare i propri impegni. È qui che entrano in gioco le tue capacità di prioritizzazione e comunicazione, perché potresti dover affrontare conversazioni difficili con i clienti.
Considerazioni sulla Struttura dei Team: Team per Funzionalità o per Componenti?
Quando si aggiunge un nuovo team al progetto, come dovrebbe lavorare? Per iniziare, chiediti queste due domande:
- Saranno responsabili dello sviluppo di funzionalità visibili al cliente dall'inizio alla fine, oppure dovranno modificare qualcosa nel sistema per raggiungere il loro obiettivo?
- Saranno responsabili di lavorare su un componente specifico che fornisce parte di una funzionalità visibile all'utente?
Se hai risposto sì alla domanda n. 1, il team sarà un team di funzionalità.
Se hai risposto sì alla domanda n. 2, sarà un team di componenti.
Consigli per scegliere la giusta struttura di team
Scegliere la struttura e l’organizzazione del team più adatta è molto importante, ma non è facile. Al momento, i team di funzionalità sembrano essere l’opzione preferita nella maggior parte delle situazioni. Tuttavia, questa scelta spesso si basa sull’abitudine o sulla routine invece che sui dati.
La realtà è che “dipende”. Più nello specifico, dipende dall’architettura del sistema. I progetti software tendono a seguire quella che è nota come Legge di Conway—una osservazione empirica di Mel Conway:
“Le organizzazioni che progettano sistemi... sono costrette a produrre progetti che sono copie delle strutture di comunicazione di queste organizzazioni”
In altri termini, la “forma” della struttura dei team deve corrispondere alla “forma” del sistema, altrimenti il progetto incontrerà seri problemi.
Questo è il motivo per cui raccomando sempre ai manager di coinvolgere architetti senior e technical lead nelle decisioni relative alla struttura dei team—altrimenti, i manager stanno davvero facendo progettazione di sistema senza rendersene conto (e senza le competenze appropriate). Questo, a sua volta, può aumentare notevolmente il rischio di fallimento del progetto.
Due paradossi della scalabilità
Nella mia esperienza come consulente su numerosi progetti di larga scala, sono giunto alla conclusione che, nella maggior parte dei casi, i progetti vengono scalati per i motivi sbagliati.
Ho inventato due paradossi che riassumono ciò che ho visto in pratica:
Primo paradosso della scalabilità
La maggior parte dei progetti viene scalata perché non soddisfa i prerequisiti per la scalabilità
Secondo paradosso della scalabilità
I progetti che soddisfano i prerequisiti per la scalabilità hanno meno bisogno di essere scalati
Il primo paradosso dice che, nella maggior parte delle situazioni, i progetti procedono lentamente semplicemente perché non sono ben gestiti.
Il secondo dice che i progetti ben gestiti avranno meno bisogno di scalare proprio perché sono ben gestiti.
Di fatto, i progetti più produttivi che ho visto avevano solo uno o due piccoli team e soddisfacevano tutti i prerequisiti per la scalabilità. Di tutti quelli di vasta scala a cui ho partecipato, non ne ho visto uno solo in cui tutti i prerequisiti fossero soddisfatti. Anzi, tutti avevano notevoli difficoltà nel soddisfare anche uno solo dei prerequisiti.
Se sei coinvolto in un progetto che sta riscontrando problemi e ritardi, il miglior consiglio che posso darti è di ridurre il caos prima di pensare ad aumentare la scala del progetto.
Conclusioni per scalare i tuoi team nel modo giusto
Scalare i team di sviluppo software non è facile e va fatto con estrema attenzione. Prima di congedarti, ecco alcune riflessioni finali su come trovare il modo più efficace per aumentare una squadra di sviluppo software:
- Se lavori per soddisfare i prerequisiti della scalabilità, potresti scoprire che ti basta mantenere il team piccolo ed evitare tutti i problemi che derivano dall'aumento di dimensioni.
- Al contrario, se il tuo progetto è già ampio e in difficoltà, concentrati innanzitutto nel ridurre il caos.
Ecco i primi passi che ti suggerisco di compiere dopo aver letto questo articolo:
- Scopri cosa sta realmente accadendo sul campo
- Implementa alcune metriche per poter valutare la situazione attuale, così come la qualità delle decisioni prese.
