Regelbok og portefølje

Hold ordet 'dataprodukt' nyttig: produkt vs komponent, livsløp, domener og eierskap.

Regelbok: Hva vi mener når vi sier “dataprodukt”

Begrepet mister verdi når alt kalles produkt. Regelboken under er laget for å holde ordet dataprodukt praktisk nyttig: få produkter med høy signalverdi, mange komponenter uten falske løfter.

Ti regler som skiller produkt fra komponent

1 Ingen forvaltning → ingen produktstatus.
Hvis dere ikke har kapasitet til å holde et løfte over tid, er “produkt” bare en dyr merkelapp.

2 Eier må være navngitt – og ha beslutningsrett.
“Eier” betyr: hvem kan bestemme definisjoner, prioritering og endring – og hvem svarer når noe ryker?

3 Dataproduktet må ha navngitte kunder.
Hvis målgruppen er “alle”, er det et tegn på at dere ikke vet hvem som bruker det.

4 Dataproduktet må ha en tydelig bruk.
Ikke “for analyse”, men “for å gjøre X mulig for Y”.

5 Løftet må være tydelig nok til at andre tør å bygge på det.
Tilgang, oppdatering, kvalitetssignal og endringspraksis er som regel nok.

6 Produktflate først, implementasjon etterpå.
Det dere lover er grensesnittet mot bruk. Motorrommet skal kunne refaktoreres uten at alt blir en hendelse.

7 Kritiske avhengigheter er en del av ansvaret.
Hvis løftet avhenger av pipelines, referansetabeller eller kvalitetsjobber, må produktteamet eie konsekvensene, selv om implementasjonen kan ligge flere steder.

8 Kvalitet betyr “godt nok til bruk”.
Få tester som treffer bruken slår mange generiske tester dere ikke reagerer på.

9 Bruk må være synlig.
Hvis dere ikke vet hva som brukes, kan dere heller ikke prioritere, forvalte eller fase ut på en ryddig måte.

10 Livsløp må være definert.
“Pilot”, “aktiv”, “utfases” og “avviklet” er en enkel måte å unngå at alt blir stående for alltid.

“Team” og “eier” betyr ikke en Slack-kanal

Produktstatus gir først mening når dere kan peke på fire ting – kort, konkret og uten heltehistorier:

• Mandat: hvem tar beslutninger om definisjoner og endring?
• Kapasitet: hvem har kapasitet til hendelser og forespørsler?
• Kontaktpunkt: hvor får kunder svar uten å være personavhengig?
• Run cost: hvem eier prioriteringen av drift/compute/support? (Det holder å eie prioriteringen. Dere trenger ikke fakturere hver query.)

Hvis dere ikke har dette, er det bedre å kalle leveransen en komponent inntil videre.

Livsløp: gjør status synlig

Produkt vs komponent handler om hva noe er. Livsløp handler om hvor trygt det er å bygge på det akkurat nå, og hva som skjer når det endrer seg. Uten en synlig livsløpsstatus ender katalogen som en liste over “ting som finnes”, og deling blir personavhengig: folk spør i private meldinger om dette er støttet, om definisjonene er stabile, eller om det er på vei ut.

En enkel status på produktsiden er nok til å gjøre katalogen mer sann:

• Utkast – idé/arbeid, ingen løfter
• Pilot – noen få kunder, begrenset løfte
• Aktiv – produktløfte gjelder
• Utfases – erstatter er definert, frist og migrering er beskrevet
• Avviklet / nedgradert – ikke produkt lenger (komponent eller fjernet)

Poenget er ikke å innføre et styringsregime. Poenget er å gjøre forventninger eksplisitte før noen bygger to kvartaler med logikk på noe dere egentlig hadde tenkt å kaste. Færre overraskelser, tydeligere prioritering, ryddigere opprydding.

Tre nivåer som gjør porteføljen mer pragmatisk

I praksis trenger dere et språk for tre typer leveranser:

• Dataprodukt: forvaltet produktflate med kunder, løfte og livsløp
• Komponent: byggestein (tabell, modell, pipeline) uten produktløfte
• Eksperiment: midlertidig leveranse for å lære, kan oppgraderes senere

Lakmustesten: Hvis dere fjerner leveransen i morgen, vet dere hvem som savner den? Vet de hvem som tar telefonen?

Porteføljestyring: produkt, komponent eller eksperiment?

Når dere har et språk, kan dere styre porteføljen. To grep som gir mest effekt per kalori:

1. Gi produktstatus til det lille som er viktig og deles.
2. Gi komponentstatus til resten – men gjør eierskap og formål synlig.

Dataprodukt eller komponent? En enkel beslutningstabell

Komponenter: minimumspraksis

Minimumspraksis for komponenter:

• hvilket domene den tilhører
• hvem som eier den (team) og kontaktpunkt
• én setning om formål
• klassifisering (særlig ved sensitivitet/PII)
• enkel livsløpsstatus (aktiv / under endring / på vei ut)
• lineage/avhengigheter (grovt)

Når det finnes navngitte kunder som ville klage hvis dette endret seg uten varsel, er dere i dataprodukt-land.

Eierskap og domener: hvem bestemmer, og hvem forvalter?

Dette er stedet mange “dataprodukt”-initiativer glipper: man blir enig om en definisjon, men ikke om hvem som skal stå i den når hverdagen kommer.

Hva mener vi med “domene” her?

Domene er et område der noen har mandat til å definere begreper og regler, fordi de eier prosessen og konsekvensene.

Det betyr ikke at domenekartet må være perfekt før dere starter. Det betyr at dere må ha en adresse for uenighet.

Dataeierskap: det dere ikke slipper unna

To ting som ofte blandes:

1. Forretningsmessig eierskap til semantikk og regler Hvem bestemmer definisjonen når det er uenighet?

2. Produktmessig/operativt eierskap til produktflaten Hvem forvalter løftet til kundene: tilgang, kvalitetssignal, endring og support?

Dette kan være samme team eller delt, men ansvaret må være tydelig. Ellers blir det mye “vi trodde dere eide det”.

Plattformteam vs produktteam

• Plattformteamet leverer standarder og “golden paths” (bygging, test, deploy, katalog, tilgang, observability).
• Produktteamet eier semantikk, produktflate, prioritering og endring.
• Domeneeier/forretning møter opp når definisjoner må landes.

Skala: hvor mange dataprodukter tåler dere?

Så mange som dere klarer å forvalte med kvalitet, med kunder, løfte og et team som svarer.

Antallet dataprodukter bør ikke styres av antall tabeller, men av antall produktflater dere har kapasitet til å holde stabile over tid.

• For få → monolitt: én stor leveranse ingen tør å endre
• For mange → lav signalverdi: vanskelig å finne “det anbefalte”

Det siste er mer vanlig enn det første. Resultatet ser gjerne slik ut: 1 000 oppføringer i katalogen, 13 reelle produkter – og ingen som finner dem, fordi de andre 987 komponentene hevder de er det samme. Katalogen gir null trygghet, og folk spør i private meldinger i stedet.

Velg 1–2 brukssignaler og start enkelt: konsum i BI/semantisk lag, query-/tilgangslogger på produktflater, antall navngitte konsumentmiljøer i katalog/README, eller upstream/downstream i pipelines.

Typologi: fire vanlige dataprodukttyper

En typologi gjør det enklere å velge riktig forventningsnivå, og unngå at alt havner i samme “generisk datasett”-boks.

I neste kapittel bruker vi en type A (Kunde 360 – Core) som gjennomgående eksempel på business canvas og MVDP: Business canvas og MVDP.