Questo articolo è stato pubblicato in origine su The New Stack.
È il peggior incubo di ogni platform engineer: i vostri sviluppatori odiano la Internal Developer Platform che il vostro team ha impiegato mesi (o anni!) a realizzare. L’adozione della piattaforma è scarsa e i principali stakeholder sono disposti a fare a meno del platform engineering. Cosa è andato storto? E come può il vostro platform team evitare questo sfortunato destino?
I professionisti imparano rapidamente che nel platform engineering che fare le cose in grande non sempre rappresenta la soluzione migliore. Al contrario, il successo arriva ai platform team che iniziano in piccolo e rimangono snelli. Come dice Manuel Pais, coautore di “Team Topologies”, “Una buona piattaforma è grande quanto basta, ma non più grande del necessario”.
Questo non significa lesinare sulla qualità ma piuttosto ricorrere a due concetti chiave: Minimum Viable Product (MVP) e Thinnest Viable Platform (TVP). Utilizzando questi approcci, i platform team possono allocare in modo ottimale le risorse interne, assicurandosi di effettuare rapidamente delivery delle funzionalità giuste e di massimizzare il business value unico della piattaforma.
Iniziare in piccolo: Utilizzare il Minimum Viable Product
Eric Ries, autore di “The Lean Startup”, definisce un Minimum Viable Product (MVP) come “la versione di un nuovo prodotto che consente a un team di raccogliere la massima quantità di informazioni convalidate sui clienti con il minimo sforzo”.
In altre parole, un MVP è la versione più semplice del prodotto necessaria per ottenere il feedback degli utenti. Iniziando in piccolo, i platform team possono convalidare le ipotesi di base ed evitare di sprecare risorse in funzionalità che gli sviluppatori non vogliono o non reputano utili.
Seguendo un approccio MVP, i platform team iniziano a parlare con gli sviluppatori della loro organizzazione. Conducono ricerche sugli utenti per identificare e comprendere le sfide più significative degli sviluppatori. È probabile che gli sviluppatori abbiano già trovato e implementato diverse soluzioni per problemi persistenti. I platform team devono identificare i limiti delle soluzioni esistenti e progettare un’alternativa convincente. L’MVP deve essere uno strumento di apprendimento, non un prodotto finito, quindi non deve cercare di coprire tutti i casi d’uso. I platform team devono creare le funzionalità minime necessarie per risolvere il problema.
Francesca Carta, ex Mia-Platform’s delivery manager, raccomanda di distribuire l’MVP a un piccolo “team pioniere” per i test. I platform team possono quindi utilizzare il feedback dei team team pioniere per lavorare ancora sulla soluzione prima di rilasciarla a una base di utenti più ampia.
Lo sviluppo di un MVP richiede in genere da uno a tre mesi. Questa tempistica abbreviata consente ai platform team di conoscere rapidamente le esigenze degli sviluppatori. I platform team possono adeguarsi in base ai primi feedback e creare una piattaforma efficace e convincente con un investimento minimo.
Secondo l’esperienza di Francesca Carta, i platform team possono utilizzare un approccio MVP anche per implementare con successo strumenti di terze parti:
“Non iniziate cercando di automatizzare tutto, ma risolvendo il problema principale del vostro team. Ad esempio, se le implementazioni rappresentano un grande pain point, dovreste concentrarvi sul renderle una funzionalità self-service. Poi, nella seconda fase, potrete aggiungere il plug-in per la configurazione dell’infrastruttura”.
I platform team possono così iterare sul successo di implementazioni più limitate di nuovi strumenti. Un feedback rapido è comunque importante, perché la migrazione degli sviluppatori a soluzioni di terze parti può creare attriti tanto quanto la migrazione degli sviluppatori a strumenti interni.
Realizzare un MVP non significa solo coinvolgere gli sviluppatori. Troppe iniziative di piattaforma falliscono perché i platform team non riescono a dimostrare il loro valore agli stakeholder abbastanza velocemente. Secondo Francesca Carta, questo problema si verifica spesso quando i platform team cercano di progettare considerando tutti i casi d’uso fin dall’inizio, invece di concentrarsi sull’MVP. Francesca consiglia ai team di assicurarsi l’impegno degli stakeholder iniziando con un risultato rapido e rilevante, per poi continuare a iterare.
Rimanere snelli: Thinnest Viable Platform
Mentre l’approccio MVP aiuta i platform team a sviluppare nuove funzionalità, l’approccio TVP (Thinnest Viable Platform) aiuta i team ad allocare in modo ottimale le risorse interne per l’intero ciclo di vita della piattaforma. Manuel Pais e il suo coautore Matthew Skelton definiscono TVP come:
“il più piccolo insieme di API, documentazione e strumenti necessari per accelerare i team che sviluppano moderni servizi e sistemi software”.
Il TVP di un’organizzazione cambia nel tempo. Poiché gli strumenti di terze parti diventano sempre più competitivi, i platform team devono scegliere se migliorare i componenti personalizzati o acquistare dai fornitori. Quando si definisce un TVP, Francesca Carta dice: “Bisogna scegliere ragionando come azienda: Cosa costruire all’interno della propria azienda? Che cosa manterrai?”. Con un approccio TVP, i platform team allocano le risorse interne solo a ciò che fornisce un business value unico.
Abby Bangser di Syntasso ha raccontato come lo strumento di osservabilità personalizzato di MOO sia stato ritirato a favore di opzioni fornite dal fornitore, nonostante le preoccupazioni riguardo allo spreco di investimenti passati e i timori legati al vendor lock-in. I vantaggi sono stati evidenti pochi mesi dopo il passaggio:
“”Poiché MOO stava finanziando un’azienda esterna per innovare nel settore del tracciamento, il team interno di platform engineering ha potuto concentrarsi su livelli più avanzati dello stack, fornendo vantaggi mirati per MOO invece di gestire un servizio interno ormai superato”.
L’autore Gregor Hohpe, nel suo intervento alla PlatformCon 2022 “La magia delle piattaforme”, ha parlato della delicatezza delle piattaforme, riferendosi alla loro capacità di restare a galla o di sprofondare. Immaginate che tutte le piattaforme poggino su una piattaforma di base come Kubernetes. Nel corso del tempo, questa piattaforma di base acquisisce nuove caratteristiche e funzionalità. Hohpe lo paragona all’innalzamento del livello dell’acqua. Le piattaforme che non si adattano alla marea crescente affonderanno; continueranno a duplicare le funzionalità offerte dalla piattaforma di base. Con una piattaforma “galleggiante,” il platform team esternalizza o rimuove strategicamente le funzionalità superflue. Questo libera le risorse interne, permettendo di focalizzarsi sull’innovazione e di sviluppare funzionalità che superano quelle della piattaforma di base.
Secondo Hohpe, nessuna delle due opzioni è intrinsecamente migliore dell’altra. La chiave è decidere in modo proattivo se la piattaforma galleggerà o affonderà, quindi comunicare il piano agli stakeholder. Quando si costruisce una piattaforma galleggiante (cioè si mantiene un TVP), i platform team devono essere trasparenti riguardo alla possibilità di esternalizzare o ritirare le funzionalità sviluppate internamente. In caso contrario, gli stakeholder potrebbero irritarsi nel vedere mesi o anni di lavoro accantonati in favore di una soluzione esterna.
Allo stesso modo, i platform team devono essere consapevoli dell’impatto che il mantenimento di una TVP ha sugli sviluppatori. Nel suo intervento alla QCon, Jessica Andersson di Kognic ha spiegato che i platform team guadagnano “crediti di fiducia” quando risolvono i problemi e adottano un approccio orientato al prodotto. Al contrario, le migrazioni, sebbene inevitabili, comportano una perdita di crediti di fiducia. I platform team devono cercare di mantenere un equilibrio tra i benefici ottenuti e i costi sostenuti.
