Erfaringsdeling fra kurset “Platform as a Product”
Intro
Thea og jeg har vært på kurs! Manuel Pais, en av forfatterne av boka Team Topologies, holdt et heldagskurs med temaet «Platform as a product». Kurset tok for seg hvordan et plattformteam kan øke flyten i en virksomhet, dersom man innretter det riktig. Med flyt mener han hvor raskt og effektivt en virksomhet leverer verdi (som ikke må forveksles med fart, eksempelvis målt ved DORA-metrikkene).
I denne artikkelen vil vi ta for oss de viktigste læringspunktene fra kurset. Kurset forutsatte en grunnleggende forståelse for Team Topologies, og det gjør vår erfaringsdeling her også.
Du må behandle plattformen som et produkt!
I Team Topologies er det verdistrømteamene som er hovedteamene som leverer verdi. Alle andre team eksisterer for å støtte disse, og sørge for at de leverer best mulig. Rollen til et plattformteam spesifikt, er å ta ned den kognitive lasten i verdistrømteamene som nyttiggjør seg av plattformen.
I starten av kurset tydeliggjorde Manuel at spesielt den kognitive lasten som distraherer teamet fra sitt hovedformål, bør adresseres av plattformteam. Dette kan eksempelvis være en deploy pipeline. I kraft av dette vil man øke flyten i verdistrømteamene, som gir økt verdi for virksomheten. Det første hovedpoenget blir da:
Plattformteam eksisterer for å ta ned kognitiv last i verdistrømteam, og dette øker flyten i virksomheten.
For å ta ned den kognitive lasten kan man enten lage egne tjenester, eller bistå et team direkte i deres kodebase. Manuel påpekte at det å lage og vedlikeholde en felles tjeneste har en kost, og at man bør ha et edruelig og pragmatisk syn på når man velger å ta den kosten. Ofte er det bedre og billigere å implementere funksjonalitet for ett team, og han slår et tydelig slag for at det bør være flytende grenser for ansvarsdelingen mellom team. Dersom man velger å implementere noe hos et team, kan man alltid endre på dette senere.
En tendens man gjerne ser, er at plattformteam starter med en rekke krav og en mengde funksjonaliteter som de tenker at må på plass. Heller enn å adressere ett spesifikt behov, eller ett konkret team, starter man ofte større, for å forsvare den relativt dyre investeringen det er å ha et plattformteam. Kurset argumenterer for det motsatte: tenk MVP! Ved å anse plattformen som et produkt, gir det mer mening å løse ett konkret behov eller bistå ett team. På denne måten vil funksjonene til produktet organisk vokse frem på en behovsdrevet måte.
Brukerne av plattformen er dine kunder
I tråd med at plattformen er et produkt, må teamet være innforstått med at de har kunder å forholde seg til. Verdistrømteamene er brukerne av plattformen, og må behandles som kunder. Kurset argumenterer for at plattformteam må begynne med de rette og enkle oppgavene. For å vurdere hva disse er, er det behov for å:
- innrette seg som et produktteam (med blant annet en produkteier og designer)
- sette seg inn i brukerbehovene til sine kunder
- levere et produkt som skaper verdi for kundene
Videre må man ha tankegangen at en plattform er frivillig å bruke: Et produkt er ikke noe du kan påtvinge en kunde. Kurset mener det er et anti-pattern dersom man bruker en plattform for å tvinge ettergivenhet. Verdistrømteam må selv få kjenne på sine behov og prioriteringer. Når en plattform er med på å bane vei for tjenestene, vil verdistrømteamene hekte seg på.
Plattformteam må justere sine planer etter verdistrømteamene sine behov, og være tilpasningsdyktige. Skal en plattform skape verdi, må prioriteringene til teamet stemme overens med fokuset til verdistrømteamene. Manuel poengterte at dette bør løses med et fleksibelt veikart: Et fastlåst veikart er et anti-pattern. Det sentrale er at veikartet til plattformteamet ikke er låst langt frem i tid, samt at det samsvarer med konsumerende teams behov.
For å kartlegge disse behovene er det viktig at teamet utøver product discovery, på lik linje som man gjør for andre produkter. Et spørsmål som ble stilt under kurset, var hvor mange plattformteam som tilnærmer seg dette (med tilhørende fagkompetanse) på samme måte som verdistrømteam. Dessverre er fasit at dette gjelder de færreste plattformteam.
Synliggjøring av verdi fra en plattform er krevende, men svært viktig
Ettersom en plattform ikke leverer verdi direkte, men effektiviserer andre team, er det vanskelig å synliggjøre verdien av selve plattformen. Dette gjør finansieringsdiskusjoner vanskelige, spesielt når virksomheten skal gjennomføre kutt. Som Manuel sa i kurset:
“With platforms, you have unclear revenue, and clear costs”. Det er ikke et ideelt utgangspunkt for finansieringsdiskusjoner, og han sa videre at dette er hans hovedfokusområde for tiden: Å forbedre hvordan vi kommuniserer verdien av en plattform til resten av virksomheten (og spesielt beslutningstakere).
Selv om det er vanskelig, kan vi ikke bare gi opp: Vi må kommunisere verdien som plattformen gir, så godt vi kan! Vi må forsøke å kommunisere den økte effektiviteten for andre team. Her kan vi for eksempel hente frem metrikker som underbygger verdiskapningen, eller fortelle om suksesshistorier for hvordan hverdagen i teamene har blitt bedre. Dette henger tett sammen med å tenke på plattformen som et produkt: Et modent produktteam vil være ansvarlig for å kommunisere forretningsverdien av sitt produkt, og dersom plattformteamet skal sees på som et produktteam, bør vi utfordre dem på det samme.
Jobben vår ligger i å oversette den nytten plattformen bidrar med, til verdien man skaper for virksomheten.
Noen refleksjoner fra oss
Kurset tok for seg et viktig konsept som vi opplever at ofte undervurderes. Plattformer er kraftige verktøy, som kan ha betydelig påvirkning på et teams evne til å levere effektivt og med høy kvalitet. Alle som har jobbet kodenært vet hvor viktig det er med gode plattformer, og dette kurset bidrar til å sette tematikken på agendaen.
Mange av hovedpoengene er momenter vi ikke har tenkt over eksplisitt før, men som gir god mening umiddelbart når man får det presentert. Her skal Manuel ha kudos for en god oppbygning, tydelig begrepsbruk, og relevante eksempler for å innramme budskapet.
Vi tror definitivt at tilnærmingen som skisseres er god, og at flere med fordel kunne sett på plattformer på denne måten. Ved å starte med en kartlegging av den kognitive lasten i verdistrømteam, vil man se hvor det er potensiale. Videre er det viktig å bemanne opp plattformteamet med de samme fagprofilene som et vanlig produktteam for å få et best mulig produkt. Det er noe som dessverre ofte nedprioriteres, i vår erfaring.
