Hvordan identificerer og afbøder du teknisk risiko?

Question

Accepted Answer

**Teknisk risiko** er alt, der kan få projektet til at køre af sporet eller går ned i produktion – det ukendte, skrøbelige afhængigheder, skaleringsgrænser, single points of failure. En TL's job er at **blive opmærksom på risiko tidligt og reducere den bevidst**, fordi risiko er billigst at håndtere før du har bygget oven på det.

## Sådan styrer du 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
```

## Reducer risiko tidligt, ikke sent

De farligste risici er *det ukendte*, de ting du ikke kan estimere. Tackle dem først med en spike eller prototype, så du lærer sandheden mens projektet stadig er billigt at ændre. At bygge de lette, kendte dele først føles produktiv, men efterlader minefældet til slutningen.

## Et konkret eksempel

Et projekt afhænger af et tredjeparts-API som du aldrig har brugt i stor skala. Design ikke hele systemet under antagelsen om, at det virker, prototype mod det i uge et. Hvis det ikke kan håndtere din belastning, finder du det ud nu, ikke efter at du har bygget alt omkring det.

## En fælde

At gøre det komfortable, kendte arbejde først og gemme det skræmmende ukendte til sidst. Det maksimerer omkostningen ved at have uret, præcis det modsatte af hvad du vil have.

## Hvorfor det betyder noget

Risici, der ignoreres til sent, bliver kriser – dyre, planlægnings-ødelæggende og moralkrussende.

En TL, der jager risiko tidligt, handler en lille kendt omkostning nu for at undgå en stor ukendt omkostning senere.

Den fremsyn er meget af det, der gør en senior lead værd deres salt.