Hur identifierar och minskar du teknisk risk?

Question

Accepted Answer

**Teknisk risk** är allt som kan förhindra leverans eller gå sönder i produktion, okända faktorer, skör beroenden, skalbegränsningar, enskilda felpunkter. En TL:s jobb är att **få upp risker tidigt och minska dem medvetet**, eftersom risk är billigast att hantera innan du byggt på den.

## Hur man hanterar risk

```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
```

## Minska risk tidigt, inte sent

De farligaste riskerna är *okända faktorer*, saker du inte kan uppskatta. Tackla dem först med en spike eller prototyp, så du lär dig sanningen medan projektet fortfarande är billigt att ändra. Att bygga de enkla, kända delarna först känns produktivt men lämnar sprängämnet för slutet.

## Ett konkret exempel

Ett projekt är beroende av ett tredjepartsAPI som du aldrig använt i skala. Designa inte hela systemet under antagandet att det fungerar, prototypa mot det i vecka ett. Om det inte kan hantera din belastning, vet du det nu, inte efter att du byggt allt runt det.

## En fallgrop

Att göra det bekväma, kända arbetet först och spara det skrämmande okända för sist. Det maximerar kostnaden för att ha fel, helt baklänges.

## Varför det spelar roll

Risker ignorerade till sent blir kriser, dyra, schema-förstörande och moralförstörande.

En TL som jagar risk tidigt byter ett litet känt kost nu mot att undvika ett stort okänt kost senare.

Den framsynthet är mycket av vad som gör en senior ledare värd sitt värde.