Hvordan identifiserer og reduserer du teknisk risiko?

Question

Accepted Answer

**Teknisk risiko** er alt som kan få leveringen til å stramme eller bryte i produksjon, ukjente forhold, skjøre avhengigheter, skalerings grenser, enkelt feilpunkt. En TLs jobb er å **bringe risiko fram tidlig og forminske det bevisst**, fordi risiko er billigst å løse før du har bygget på toppen av det.

## Hvordan håndtere risiko

```text
1. IDENTIFY — what could go wrong? (unknowns, deps, scale, security, people)
2. ASSESS — likelihood x impact. Focus on the high-high quadrant.
3. ATTACK the biggest unknowns FIRST — spike, prototype, load-test
4. MITIGATE — reduce likelihood or blast radius (redundancy, flags, fallbacks)
5. MONITOR — track known risks; have a plan if they materialize
```

## Redusjoner risiko tidlig, ikke sent

De farligste risikoen er *ukjente*, tingene du ikke kan estimere. Takle dem først med en spike eller prototype, så du lærer sannheten mens prosjektet fortsatt er billig å endre. Å bygge de enkle, kjente delene først føles produktivt, men lar deg landminen for slutten.

## Et konkret eksempel

Et prosjekt avhenger av en tredjeparts API du aldri har brukt i stor skala. Ikke design hele systemet forutsatt at det fungerer, lage prototype mot det i uke en. Hvis det ikke kan håndtere belastningen din, finner du det ut nå, ikke etter at du har bygget alt rundt det.

## En fallgruve

Å gjøre det komfortable, kjente arbeidet først og spare det skumle ukjente for slutten. Det maksimaliserer kostnaden for å ta feil, nøyaktig bakvendt.

## Hvorfor det er viktig

Risiko ignorert til sent blir kriser, dyre, tidsplan-ødeleggelse og moralen-knusende.

En TL som jager risiko tidlig bytter en liten kjent kostnad nå for å unngå en stor ukjent kostnad senere.

Den framsyn er mye av det som gjør en senior leder verdt sin salt.