Hvordan etablere tekniske standarder som faktisk etterleves

Det er lett å bli enige om at man trenger standarder. At ting burde gjøres på samme måte. At vi burde “rydde litt” og bli mer konsekvente.
Så noen tar ansvar, lager et dokument, lenker det i Slack – og så skjer det… ingenting.

Standarder er nemlig ikke verdifulle i seg selv. De får først verdi når de faktisk etterleves. Og det skjer sjelden av seg selv.

Standarder som ingen bruker

Mange team har hatt “den store ryddepraten”. Kanskje i en retro, kanskje i en workshop. Man blir enige om hvordan logging skal se ut, hvordan man navngir ting, hvordan man skriver tester.
Så går det noen uker, og man er tilbake der man startet. Fordi standardene ikke fikk plass i hverdagen.

Jeg har vært med på det selv: et flott dokument i Confluence. Gjennomtenkt. Enig i alt. Men aldri brukt.

Så hva gjør man for at det faktisk skal fungere?

Det begynner med eierskap

Det viktigste spørsmålet å stille seg er: Hvem eier standardene våre?
Hvis svaret er “han ene som liker å rydde”, har man et problem. Standarder må være forankret i teamet. De må oppstå fra praksis – ikke bare fra teori.

Ofte skjer det i de små øyeblikkene: når noen kommenterer på en pull request og spør: “Burde vi hatt en felles måte å logge dette på?”
Det er der standarder blir født – i samtalen, ikke i styringsdokumentet.

TDR – et minne om hvorfor

Et undervurdert verktøy for å forankre beslutninger over tid er Technical Decision Records (TDRs).

En TDR er kort og konkret, gjerne lagret i docs/decisions/2025-01-logging-strategy.md, og svarer på tre spørsmål:

Hva har vi valgt?
Eksempel: Vi logger med ILogger<T> og bruker strukturerte JSON-logger.
Hvorfor valgte vi dette?
Eksempel: For bedre støtte for søk i Seq og enklere parsing i observability-verktøy.
Hva vurderte vi og forkastet?
Eksempel: Vi vurderte direkte bruk av Serilog, men ville unngå vendor lock-in.

Når beslutningene er dokumentert slik, slipper man diskusjonene om hvorfor ting ble som de ble.
Det skaper historikk, kontinuitet og trygghet for nye utviklere.

Flere repoer – ett felles minne

I større organisasjoner er det sjelden bare ett repo. Ofte finnes det mange – med delte standarder på tvers. Da oppstår spørsmålet: Hvor er kilden til sannhet?

Her er et mønster som fungerer i praksis:

Ha én sentral “engineering standards”-repo som eies av teamet (eller et kompetansefellesskap).
Her ligger de overordnede standardene og TDR-ene som gjelder på tvers av prosjekter.
Lenk fra de enkelte prosjektene – aldri kopier.
Du kan inkludere lenker i hver README eller CONTRIBUTING.md til den sentrale repoen.
Duplicering fører raskt til avvik og usikkerhet.
Bruk per-repo TDR-er kun for lokale valg.
For eksempel: en bestemt cache-strategi i ett system, eller bruk av en tredjeparts-tjeneste som gjelder lokalt.
Da bør TDR-en lenke tilbake til den sentrale standarden og forklare avviket.

�� Prinsippet er enkelt:
Felles standarder skal ha ett hjem, lokale tilpasninger skal forklares der de skjer.

Dokumentasjon som faktisk blir brukt

Standarder må være korte, presise og tilgjengelige.
Ikke PDF-er på delte disker, men Markdown i repoet – side om side med koden.
Et sted man faktisk jobber.

Del dokumentasjonen opp etter tema – navngivning, logging, API-design – og lenk til den fra CONTRIBUTING.md.
Og hvis noe ikke lenger er relevant: slett det.
En utdatert standard er verre enn ingen standard.

Hvordan standarder blir praksis

Å skrive standarder er én ting. Å bygge dem inn i hverdagen er noe helt annet.

Pull request-maler

PR-maler er et enkelt grep som hjelper teamet å huske egne prinsipper:

Pull Request-mal:

Hva gjør denne endringen?
Kort beskrivelse og hensikt.

Har du vurdert:
☐ Logging i henhold til konvensjon
☐ Inputvalidering
☐ Riktig navnekonvensjon
☐ Trenger denne endringen en TDR?

Testet:
☐ Lokalt
☐ I testmiljø

En slik sjekkliste minner oss om standardene – akkurat i det øyeblikket vi trenger dem – uten å tvinge noen.

Automatisert håndheving

Noen regler kan ikke overlates til hukommelsen. De bør håndheves automatisk:

Kodeformatering: .editorconfig og dotnet format
Analyzers: Roslyn-regler for naming, obsolete API-er og testkonvensjoner
CI/CD: Pipelines som stopper merges ved brudd på kritiske standarder

Når verktøyet sier ifra, blir det ikke personlig.
Det blir bare praksis.

Kultur spiser dokumentasjon til frokost

Du kan ha verdens beste dokument, men det betyr lite hvis det ikke er en del av kulturen.
Og kultur bygges gjennom praksis.

Når de erfarne følger standardene konsekvent, sender det et signal.
Når noen får tilbakemelding med lenke til en TDR – ikke bare en pekefinger – lærer de noe nytt.
Når man faktisk sier “takk for at du fulgte konvensjonen”, forsterkes kulturen.

Og når noen bryter standarden med god grunn – og det blir en ny TDR – da vokser systemet på en sunn måte.

Levende standarder

Standarder må leve. De bør evalueres og justeres jevnlig. Retrospektiver er et godt sted å starte:
Hva fungerer? Hva gjør ikke det? Skal vi oppdatere dokumentet – eller skrive en ny TDR?

På den måten blir standardene et uttrykk for felles læring, ikke kontroll.

Til slutt

Å etablere tekniske standarder som faktisk etterleves handler ikke om regler, men om samarbeid.
Om å skape en felles rytme som gjør hverdagen mer forutsigbar og frigjør energi til det som betyr mest – å løse problemer sammen.

Standarder er i bunn og grunn et uttrykk for tillit: en enighet om hvordan vi skal bygge sammen.

Når de er forankret, synlige og brukt med fornuft – da blir de en støtte. Ikke en tvangstrøye.

‍