By name: nav-deep-interview description: Strukturert intervju som avdekker blindsoner i Nav-prosjekter — personvern, auth, avhengigheter og observerbarhet license: MIT metadata: domain: general tags: planning requirements interview onboarding
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 + Azure AD)
- 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:
# 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