Deep Interview — Nav Project Clarification
Kjør et strukturert intervju for å avdekke blindsoner før implementering starter. Basert på vanlige feil og oversikter i Nav-prosjekter.
Workflow
- Identifiser arketype — hva slags ting bygges?
- Still domene-spesifikke spørsmål — basert på arketypen
- Oppsummer funn — krav, risiko, ikke-mål
- Generer output — strukturert kravdokument
Steg 1: Arketype
Still dette spørsmålet først:
Hva slags ting bygger du?
- Backend API (Kotlin/Ktor eller Spring Boot)
- Hendelsekonsument (Kafka / Rapids & Rivers)
- Frontend for innbygger (Next.js + ID-porten)
- Frontend for saksbehandler (Next.js + Entra ID)
- Batchjobb (Naisjob)
- Fullstack (frontend + BFF + backend)
Steg 2: Domene-spesifikke spørsmål
Still spørsmål fra alle fire domener. Tilpass rekkefølge basert på arketype.
Personvern og data
Disse spørsmålene glemmes oftest. Still dem først.
| # | Spørsmål | Hvorfor |
|---|---|---|
| D1 | Behandler tjenesten personopplysninger? Hvilke kategorier? | Bestemmer dataklassifisering og lagringsregler |
| D2 | Hvem har tilgang til dataene — innbygger, saksbehandler, system? | Bestemmer auth og tilgangskontroll |
| D3 | Hva er formålet med behandlingen? (Hjemmel) | Nødvendig for GDPR-vurdering |
| D4 | Hvor lenge skal data lagres? Finnes det sletteregler? | Påvirker database-design og retensjon |
| D5 | Skal data deles med andre tjenester? Hvilke? | Påvirker API-design og accessPolicy |
| D6 | Trenger dere audit-logging av hvem som har sett/endret data? | Påkrevd for sensitive personopplysninger |
Se data-classification.md for Navs dataklassifiseringsnivåer.
Plattform og autentisering
| # | Spørsmål | Hvorfor |
|---|---|---|
| P1 | Hvem initierer forespørsler — bruker, annen tjeneste, batch, ekstern? | Bestemmer auth-mekanisme |
| P2 | Hvilke andre tjenester kaller dere? Hvilke cluster? | Bestemmer outbound accessPolicy og token exchange |
| P3 | Er tjenesten eksponert eksternt (internett) eller bare internt? | Bestemmer ingress og nettverkspolicy |
| P4 | Hva skjer når en avhengighet er nede? | Påvirker retry-strategi og circuit breaker |
| P5 | Trenger dere asynkron kommunikasjon (hendelser)? | Kafka-oppsett eller ikke |
| P6 | Finnes det eksisterende tjenester dere kan gjenbruke? | Unngå duplikering |
Observerbarhet og drift
| # | Spørsmål | Hvorfor |
|---|---|---|
| O1 | Hvilke forretningsmetrikker viser at tjenesten fungerer? | Definerer Prometheus-metrikker |
| O2 | Hva skal trigge varsling? | Definerer alerting-regler |
| O3 | Hvordan vet dere at en deploy gikk bra? | Smoke test-strategi |
| O4 | Hvem er on-call? Finnes det en vaktordning? | Påvirker varslings-setup |
| O5 | Forventet trafikkmønster? (Jevnt, kontortid, sesong?) | Påvirker skalering og ressurser |
Team og prosess
| # | Spørsmål | Hvorfor |
|---|---|---|
| T1 | Nytt prosjekt eller utvidelse/modernisering av eksisterende? | Påvirker scaffold vs. migrasjonsstrategi |
| T2 | Avhenger dere av andre team? Hvilke? | Koordineringsbehov |
| T3 | Er det en deadline (regulatorisk, politisk, annet)? | Påvirker scope og prioritering |
| T4 | Har teamet erfaring med stakken? | Påvirker kompleksitetsnivå |
Modernisering og migrasjon
Still disse spørsmålene hvis T1 avdekker modernisering/refaktorering:
| # | Spørsmål | Hvorfor |
|---|---|---|
| M1 | Hva finnes i dag — hvilken teknologi, arkitektur og datamodell? | Kartlegger utgangspunktet |
| M2 | Hva er feil med dagens løsning? (Ytelse, vedlikeholdbarhet, sikkerhet?) | Avklarer motivasjon og prioritet |
| M3 | Må gammel og ny løsning kjøre parallelt? Hvor lenge? | Bestemmer migreringsstrategi (big bang vs. gradvis) |
| M4 | Finnes det andre team eller tjenester som konsumerer API-er/hendelser som endres? | Koordineringsbehov og bakoverkompatibilitet |
| M5 | Hva er rollback-planen hvis migreringen feiler? | Må defineres FØR implementering starter |
| M6 | Hvordan vet dere at migreringen er ferdig? (Exit criteria) | Definerer når gammel løsning kan dekommisjoneres |
| M7 | Finnes det data som må migreres? Hvor mye? | Påvirker migreringspipeline og nedetid |
| M8 | Har dere karakteriseringstester som låser dagens adferd? | Nødvendig for trygg refaktorering |
Steg 3: Sjekk blindsoner
Etter intervjuet, sjekk om noen av disse vanlige blindsonene ble avdekket. Hvis ikke — still oppfølgingsspørsmål.
Se blind-spots.md for en komplett liste over vanlige oversikter.
Kritiske blindsoner (still alltid):
- Er auth-mekanismen verifisert mot caller-typen?
- Er
accessPolicy.inbounddefinert i Nais-manifestet? - Er PII-logging unngått?
- Er HikariCP pool-størrelse tilpasset container (3-5, ikke 10)?
- Er det satt opp structured logging (JSON)?
- Finnes det en strategi for dependency failure?
Ekstra blindsoner for modernisering (still hvis T1 = modernisering):
- Er bakoverkompatibilitet vurdert? (Kan gammel kode lese nytt skjema?)
- Er rollback-plan definert og testet?
- Er exit criteria for migreringen definert?
- Er berørte konsumenter identifisert og informert?
- Er dekommisjoneringsplan for gammel løsning laget?
- Er feature toggle satt opp for gradvis utrulling?
- Er rekonsiliering planlagt (sammenligning av gammel og ny)?
Endringskonsekvensanalyse (still alltid for brownfield)
Kartlegg påvirkning systematisk. Disse spørsmålene avdekker risiko som ofte oppdages for sent:
| # | Spørsmål | Formål |
|---|---|---|
| K1 | Hvem kaller dine API-er i dag? (sjekk accessPolicy.inbound) | Identifiser direkte konsumenter |
| K2 | Hvem konsumerer dine Kafka-hendelser? | Finn downstream-avhengigheter |
| K3 | Har andre tjenester tilgang til databasen din? | Avdekk delt database-risiko |
| K4 | Påvirker endringen data som vises til innbyggere? | Brukerreise-konsekvens |
| K5 | Påvirker endringen data som brukes til utbetaling? | ⚠️ Høy risiko — krever ekstra review |
| K6 | Finnes det dashboards eller varsler som må oppdateres? | Operasjonell påvirkning |
| K7 | Krever endringen koordinert deploy med andre team? | Logistisk risiko |
| K8 | Finnes det API-kontrakter (eksplisitte eller implisitte) som endres? | Kontraktsbrudd |
| K9 | Hva er testtilstanden for koden som endres? (dekning, type tester) | Endringssikkerhet |
| K10 | Hvordan verifiserer dere at endringen fungerer i produksjon? | Observerbarhet |
Steg 4: Output
Generer et strukturert kravdokument:
markdown# Prosjekt: [navn] ## Arketype [Backend API / Hendelsekonsument / Frontend / ...] ## Scope - [Hva som skal bygges] - [Ikke-mål: hva som er utenfor scope] ## Dataklassifisering - Nivå: [Åpen / Intern / Fortrolig / Strengt fortrolig] - PII-kategorier: [fnr, navn, helseopplysninger, ...] - Hjemmel: [...] ## Arkitekturbeslutninger | Beslutning | Valg | Begrunnelse | |-----------|------|-------------| | Auth | [mekanisme] | [hvorfor] | | Kommunikasjon | [sync/async] | [hvorfor] | | Database | [PostgreSQL/ingen/BigQuery] | [hvorfor] | | Observerbarhet | [metrikker] | [hva måles] | ## Migrasjonsstrategi (kun ved modernisering) | Aspekt | Beslutning | |--------|-----------| | Endringstype | [Nybygg / Modernisering / Refaktorering] | | Utrulling | [Big bang / Gradvis med toggle / Parallellkjøring] | | Rollback | [Toggle av / Revert migrasjon / Beholde gammel] | | Exit criteria | [Når er migreringen ferdig?] | | Dekommisjonering | [Plan for å fjerne gammel løsning] | ## Identifiserte risikoer 1. [risiko + foreslått mitigering] ## Endringskonsekvenser (kun ved brownfield) | Berørt komponent | Type påvirkning | Risiko | Handling | |-----------------|----------------|--------|---------| | [tjeneste/team] | [API/Kafka/DB/UI] | [Lav/Middels/Høy] | [Informere/Migrere/Teste] | ## Teststrategi | Lag | Testnivå | Hva dekkes | |-----|----------|-----------| | [Forretningslogikk] | [Unit] | [Beregninger, validering] | | [API] | [Slice/integrasjon] | [Ruting, feilkoder, auth] | | [Database] | [Integrasjon] | [CRUD, migreringer] | | [Brukerreise] | [E2E] | [Kritiske flyter] | ## Avhengigheter - [team/tjeneste + hva som trengs] ## Neste steg - [ ] [konkret aksjonspunkt]
Boundaries
✅ Always
- Still personvernspørsmål først — de glemmes oftest
- Verifiser auth-mekanisme mot caller-type
- Dokumenter ikke-mål eksplisitt
- Identifiser minst én risiko
⚠️ Ask First
- Foreslå arkitektur som avviker fra teamets eksisterende stack
- Anbefale å endre auth-mekanisme på eksisterende tjenester
🚫 Never
- Anta at auth ikke trengs
- Hoppe over personvernspørsmål
- Foreslå at PII kan logges
- Ignorere spørsmål om avhengigheter til andre team
