Hoe identificeer en beperkt je technisch risico?

Question

Accepted Answer

**Technisch risico** is alles wat de aflevering kan doorkruisen of in productie kan breken, onbekenden, fragiele afhankelijkheden, schaallimieten, enkelvoudige foutpunten. De taak van een TL is om **risico vroegtijdig aan het licht te brengen en opzettelijk te verkleinen**, omdat risico het goedkoopst is om aan te pakken voordat je er op gaat bouwen.

## Waarom het belangrijk is

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

## Risico snel afbouwen, niet laat

De gevaarlijkste risico's zijn *onbekenden*, dingen die je niet kunt inschatten. Pak ze eerst aan met een spike of prototype, zodat je de waarheid leert terwijl het project nog goedkoop kan worden gewijzigd. Als eerste de makkelijke, bekende onderdelen bouwen voelt productief, maar laat je de landmijn achter voor het einde.

## Een concreet voorbeeld

Een project is afhankelijk van een derde-API die je nog nooit op schaal hebt gebruikt. Ontwerp het hele systeem niet aangenomen dat het werkt, maak prototype tegen in week één. Als het je belasting niet kan verwerken, kom je het nu te weten, niet nadat je alles eromheen hebt gebouwd.

## Een struikelpunt

Eerst het comfortabele, bekende werk doen en het enge onbekende voor het einde sparen. Dit maximaliseert de kosten van ongelijk hebben, precies het tegenovergestelde.

## Waarom het belangrijk is

Risico's die tot laat worden genegeerd, worden crises, duur, planning-verwoestend en moreel-vernederend.

Een TL die vroeg risico jaagt, verkoopt een kleine bekende kostprijs nu voor het vermijden van een grote onbekende kostprijs later.

Die vooruitziendheid is veel van wat een senior lead hun zout waard maakt.