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, è 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 condivisa
L'alternativa è pensare alla piattaforma 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, lontana dall'idea di 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 diffusa a tutto il team
- I golden path emergono dal basso: le buone pratiche circolano tra team dal basso verso l'alto. Quando un team risolve un problema in modo efficace, quella soluzione diventa il nuovo standard per adozione spontanea
Se solo un team sa rilasciare in produzione, quello che hai è una dipendenza travestita da piattaforma.
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. Abilita gli altri a possedere l'infrastruttura, senza possederla lui stesso.
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 sono soprattutto 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 sta in 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, costruito insieme ai team, che lo adottano perché funziona davvero
- 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 è un investimento strategico 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.