Nelle organizzazioni che crescono, gli sviluppatori iniziano a passare una quota crescente del tempo su problemi che non riguardano il prodotto: pipeline fragili, ambienti incoerenti, rilasci che richiedono conoscenze esoteriche. La risposta istintiva è creare un "team piattaforma" che si occupi di tutto questo.
Spesso è la risposta sbagliata. Un team piattaforma dedicato rischia di diventare il nuovo collo di bottiglia: il vecchio team infrastruttura con un nome più moderno. I team di prodotto restano dipendenti, le richieste si accumulano in coda, e l'autonomia che si voleva creare diventa l'ennesima dipendenza da gestire.
Il platform engineering, quando funziona, non è un team: è un insieme di pratiche e strumenti condivisi che rendono ogni team autonomo nel rilascio.
L'anti-pattern del team piattaforma
Lo schema è ricorrente. L'organizzazione cresce, i problemi infrastrutturali si moltiplicano, qualcuno propone di creare un team dedicato. Il team piattaforma nasce con buone intenzioni: standardizzare, automatizzare, semplificare. In pochi mesi, però, si verifica un pattern prevedibile:
- I team di prodotto smettono di occuparsi degli strumenti condivisi perché "c'è il team piattaforma"
- Ogni richiesta passa attraverso il team piattaforma, che diventa un collo di bottiglia
- Le priorità del team piattaforma non coincidono con quelle dei team di prodotto
- La conoscenza infrastrutturale si concentra in poche persone; il resto dell'organizzazione perde competenza
- Quando il team piattaforma è sovraccarico, i team di prodotto aspettano
Il risultato è paradossale: si è creato un team per dare autonomia, e si è ottenuta una nuova dipendenza. È lo stesso meccanismo che genera le dipendenze tra team: ogni punto di centralizzazione diventa un punto di rallentamento.
La piattaforma come pratica, non come team
L'alternativa è pensare alla piattaforma non come a un team che costruisce strumenti per gli altri, ma come a un insieme di pratiche condivise che tutti i team conoscono, usano e contribuiscono a far evolvere.
In concreto:
- La pipeline CI/CD è responsabilità di tutti: ogni team sa come funziona, può modificarla per le proprie esigenze, e contribuisce ai miglioramenti. Non è una scatola nera gestita da un team separato. Se la CI/CD è reale, ogni sviluppatore la capisce e la possiede
- L'infrastruttura come codice è nel repository di tutti: gli ambienti sono definiti in codice, versionati, riproducibili. Ogni team può creare, modificare e distruggere i propri ambienti senza chiedere permesso a nessuno
- L'osservabilità è una competenza diffusa: non c'è un team che monitora per conto degli altri. Ogni team sa leggere i propri log, le proprie metriche, i propri alert. Il debugging è una competenza di tutti, non di pochi specialisti
- I golden path emergono dal basso: le buone pratiche vengono condivise tra team, non imposte dall'alto. Quando un team risolve un problema in modo efficace, quella soluzione diventa il nuovo standard. Non per decreto; per adozione spontanea
Se solo un team sa rilasciare in produzione, non hai una piattaforma: hai una dipendenza.
Quando la centralizzazione ha senso
Questo non significa che un ruolo dedicato alla piattaforma sia sempre sbagliato. Oltre una certa scala (30-40 sviluppatori), la complessità infrastrutturale può giustificare persone dedicate. La differenza è nel mandato.
Un team piattaforma che funziona opera come un enabling team: affianca i team di prodotto, trasferisce competenze, costruisce strumenti che altri poi possiedono. Non possiede l'infrastruttura; abilita gli altri a possederla.
I segnali che la centralizzazione sta funzionando:
- I team di prodotto rilasciano più velocemente di prima, in autonomia
- Le richieste al team piattaforma diminuiscono nel tempo perché i team diventano autonomi
- La conoscenza infrastrutturale è distribuita: se il team piattaforma va in vacanza, niente si ferma
I segnali che sta diventando un anti-pattern:
- Le richieste al team piattaforma aumentano nel tempo
- I team di prodotto hanno smesso di capire come funzionano pipeline e infrastruttura
- Il team piattaforma ha un backlog di settimane e tutti aspettano
L'impatto sul business
Il platform engineering, quando è fatto bene, ha un impatto moltiplicativo. Ogni miglioramento alla piattaforma viene moltiplicato per il numero di team che ne beneficia. Una pipeline più veloce di 5 minuti, moltiplicata per 10 rilasci al giorno di 5 team, è un risparmio significativo ogni settimana.
Le metriche che contano non sono tecniche; sono di business:
- Tempo dal commit alla produzione: è la misura più diretta dell'efficacia della piattaforma. Se cala, la piattaforma funziona
- Tempo di onboarding: quanto ci mette un nuovo sviluppatore a fare il primo rilascio? Una piattaforma efficace abbatte questo tempo da settimane a giorni
- Percentuale di tempo su problemi infrastrutturali: se i team passano il 30% del tempo su tooling e infrastruttura, c'è un problema. L'obiettivo è sotto il 10%
Cosa fare concretamente
Tre azioni per iniziare senza creare un team dedicato:
Nelle organizzazioni che affianchiamo con Innesto, il team piattaforma centralizzato nasce quasi sempre da una frustrazione reale: ogni team ha la propria pipeline, il proprio modo di fare deploy, il proprio setup di ambiente. La risposta ovvia è centralizzare. Il risultato quasi invariabile è un nuovo collo di bottiglia: ogni richiesta di infrastruttura diventa un ticket in attesa. L'alternativa che funziona — e che vediamo funzionare — è costruire strumenti di self-service talmente buoni che i team non hanno bisogno di chiedere. La differenza non è tecnica: è una scelta di chi serve chi.
- Rendere la pipeline comprensibile a tutti: se solo due persone nell'organizzazione sanno come funziona la pipeline, è un rischio. Documentare, semplificare, e assicurarsi che ogni sviluppatore possa leggerla, capirla e modificarla
- Standardizzare un golden path: scegliere l'operazione che ogni team fa in modo diverso (creare un ambiente, configurare il monitoring, rilasciare un nuovo servizio) e definire un percorso standard. Non imposto dall'alto; costruito insieme ai team e adottato perché funziona
- Misurare il tempo perso: per una settimana, tracciare quanto tempo ogni team dedica a problemi di tooling, pipeline, ambienti. Se supera il 20%, le pratiche di piattaforma sono il miglior investimento possibile
La piattaforma non è un progetto infrastrutturale: è un investimento sull'autonomia dell'organizzazione. Ogni competenza trasferita ai team è una dipendenza in meno. Ogni strumento condiviso che tutti sanno usare è un collo di bottiglia eliminato.
Se l'organizzazione è cresciuta e i team hanno perso autonomia nel rilascio, le pratiche di piattaforma si costruiscono lavorando insieme ai team: è il tipo di trasferimento che facciamo con l'innesto nell'organizzazione.