Questo articolo è stato pubblicato in origine su The New Stack.
Il Platform engineering è sempre più importante e dominante nel mondo cloud native, ma c’è ancora molto da imparare sulla creazione di piattaforme di successo. Questa sfida potrebbe sembrare schiacciante all’inizio, ma esiste un metodo potente che rende più semplice iniziare: l’approccio Platform as a Product.
Platform engineering è la disciplina di progettazione e realizzazione di Internal Developer Platform (IDP). Secondo il white paper sulle piattaforme redatto da Cloud Native Computing Foundation (CNCF) , una IDP è:
“… una base di API self-service, strumenti, servizi, conoscenze e supporto… organizzati come un prodotto interno convincente. I team di delivery autonomi possono utilizzare la piattaforma per fornire funzionalità di prodotto a un ritmo più elevato, riducendo i tempi di coordinamento ridotto”.
Per avere successo, i platform team devono creare una IDP che sia efficace e convincente. Le piattaforme efficaci risolvono problemi reali per sviluppatori, manager e dirigenti. Ma l’efficacia da sola non è sufficiente per guidare l’adozione. I platform team devono progettare e commercializzare l’IDP in modo che gli sviluppatori vogliano utilizzarlo. L’approccio Platform as a Product aiuta i platform team a identificare come una IDP efficace e convincente appare per la loro organizzazione.
Cosa si intende con Platform as a Product?
L’idea che le piattaforme debbano essere trattate come prodotti risale all’articolo del 2018 di Evan Bottcher “What I Talk About When I Talk About Platforms“:
“Un ingrediente chiave per il successo nel trovare questo equilibrio è che le piattaforme devono essere convincenti da utilizzare, non possono basarsi solo su un mandato.”
Gli autori di “Team Topologies” Manuel Pais e Matthew Skelton hanno approfondito il tema del platform product management.
L’approccio Platform as a Product implica la definizione della tua mission, la ricerca degli utenti, l’utilizzo del Minimum Viable Product (MVP) e del Thinnest Viable Platform (TVP) per allocare le risorse interne in modo efficiente e fare marketing della tua piattaforma internamente per ottenere adesioni. Nei successivi paragrafi vi riassumerò ciò che hanno condiviso i professionisti della community del Platform Engineering sulla base della loro esperienza.
1. Definisci la tua mission
Nuovi platform team spesso hanno a che fare con prospettive contrastanti sulle responsabilità del loro dominio, su come collaborare con altri team e l’aspetto del successo. Definire un mission statement può aiutare a definire l’identità del platform team. In Doma, il team di Michael Galloway ha intervistato sviluppatori, parlato con altri gruppi di stakeholder e valutato metriche quantitative delle prestazioni per identificare il loro scopo: “rendere veloce e facile la creazione di grandi prodotti”.
Mission statement forti sono come le canzoni pop di successo: sono semplici, significative e fanno provare qualcosa alle persone. “Affinché uno scopo funzioni, devi sentirlo, non solo conoscerlo”, afferma Galloway.
2. Fai le tue ricerche
Creare una piattaforma che risolva problemi reali e conquisti il cuore degli sviluppatori richiede una profonda comprensione dei loro workflow, delle sfide e di come le soluzioni esistenti siano carenti. I platform team di successo utilizzano vari metodi di ricerca e di feedback degli utenti per aggiornare la loro roadmap dell’IDP. Trovano un equilibrio tra la quantità e la qualità del feedback scegliendo metodi di ricerca “low-touch” e “high-touch”.
- Low touch: I sondaggi raccolgono in modo rapido ed efficiente il sentiment generale e identificano i pain point comuni di un ampio bacino di sviluppatori.
- Medium touch: Le richieste di commenti (in inglese, Requests for Comments) e le interviste individuali richiedono più tempo, ma consentono agli sviluppatori di elaborare questioni specifiche e proporre soluzioni.
- High touch: L’integrazione di platform advocate o di team di abilitazione direttamente nei team di sviluppo fornisce miglior feedback e contesto. Questo approccio consente l’osservazione real time dei workflow e dell’esperienza diretta delle frustrazioni degli sviluppatori.
Secondo Nicki Watt di OpenCredo , un product manager tecnico della piattaforma svolge un ruolo cruciale in questo caso. Agisce come traduttore, sintetizzando prospettive potenzialmente contrastanti in una roadmap praticabile. Il suo lavoro sarà comprendere le esigenze degli sviluppatori e costruire qualcosa di cui hanno realmente bisogno.
Ricorda, la ricerca degli utenti non dovrebbe essere un’attività svolta una tantum. È un processo continuo per tutto il ciclo di vita della piattaforma. Raccogliendo feedback in modo costante, i platform team possono garantire che la piattaforma rimanga rilevante e risponda alle esigenze aziendali in evoluzione.
3. Realizzare un Minimum Viable Product e mantenere il Thinnest Viable Platform
Le piattaforme hanno un potenziale infinito, ma i platform team hanno risorse limitate. Minimum Viable Product (MVP) e Thinnest Viable Platform (TVP) sono concetti che aiutano ad allocare in modo ottimale tali risorse.
Con un approccio MVP, i platform team creano la versione più semplce del prodotto richiesta per ottenere feedback dagli utenti. Gli MVP aiutano i platform team a convalidare le ipotesi iniziali ed evitare di sprecare risorse su funzionalità non necessarie o inefficaci. Una documentazione self-service può essere intesa come un MVP.
TVP è un concetto complementare introdotto da Skelton e Pais:
“Il più piccolo set di API, documentazione e strumenti necessari per accelerare i team che sviluppano moderni servizi e sistemi software.”
Ciò che costituisce un TVP si evolve naturalmente nel tempo. Man mano che le soluzioni di terze parti diventano competitive con gli strumenti interni di un’organizzazione, i platform team devono scegliere tra la manutenzione dei componenti realizzati o l’outsourcing a un fornitore. Con un approccio TVP, i platform team assegnano risorse interne solo a ciò che fornisce un valore aziendale unico.
