Come identifichi e mitichi il rischio tecnico?

Question

Accepted Answer

**Il rischio tecnico** è tutto ciò che potrebbe far deragliare la consegna o rompersi in produzione, le incognite, le dipendenze fragili, i limiti di scalabilità, i singoli punti di guasto. Il compito di un TL è **portare alla luce il rischio presto e ridurlo deliberatamente**, perché il rischio è più economico da affrontare prima di avervi costruito sopra.

## Come gestire il rischio

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

## De-rischiare presto, non tardi

I rischi più pericolosi sono le *incognite*, le cose che non puoi stimare. Affrontale per prime con uno spike o un prototipo, così impari la verità mentre il progetto è ancora economico da modificare. Costruire prima le parti facili e note sembra produttivo, ma lascia la trappola alla fine.

## Un esempio concreto

Un progetto dipende da un'API di terze parti che non hai mai usato in scala. Non progettare l'intero sistema assumendo che funzioni, prototipa con essa nella prima settimana. Se non riesce a gestire il tuo carico, lo scopri ora, non dopo aver costruito tutto intorno ad esso.

## Un errore

Fare prima il lavoro comodo e noto e risparmiare lo sconosciuto spaventoso per ultimo. Questo massimizza il costo di sbagliarsi, esattamente al contrario.

## Perché è importante

I rischi ignorati fino alla fine diventano crisi, costosi, che distruggono il calendario e deprimenti.

Un TL che caccia il rischio presto scambia un piccolo costo noto adesso per evitare un grande costo sconosciuto più tardi.

Questa preveggenza è gran parte di ciò che rende un senior lead degno del suo stipendio.