Cum identifici și atenui riscul tehnic?

Question

Accepted Answer

**Riscul tehnic** este orice lucru care ar putea deraia livrarea sau se rupe în producție, necunoscute, dependențe fragile, limite de scalare, puncte unice de defecțiune. Jobul unui TL este să **scoată riscul la iveală devreme și să-l micșoreze deliberat**, deoarece riscul este cel mai ieftin de abordat înainte ca tu să fi construit deasupra lui.

## De ce conteaza

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

## Reduceți riscul devreme, nu târziu

Cele mai periculoase riscuri sunt *necunoscute*, lucrurile pe care nu le poți estima. Abordează-le mai întâi cu un spike sau prototip, așa că înveți adevărul în timp ce proiectul este încă ieftin de schimbat. A construi mai întâi piesele ușoare și cunoscute pare productiv, dar lasă mina terestră pentru sfârșit.

## Un exemplu concret

Un proiect depinde de un API terță parte pe care nu l-ai folosit niciodată la scară. Nu proiecta tot sistemul presupunând că funcționează, prototipează-l în prima săptămână. Dacă nu poate gestiona încărcarea ta, afli acum, nu după ce ai construit totul în jurul ei.

## O capcană

Facând mai întâi munca confortabilă și cunoscută și salvând pe cea ciudată necunoscută pentru final. Asta maximizează costul de a te înșela, exact invers.

## De ce conteaza

Riscurile ignorate până târziu devin crize, scumpe, care distrug programul și sfărâmă moralul.

Un TL care vânează riscul devreme schimbă un mic cost cunoscut acum pentru a evita un cost necunoscut mare mai târziu.

Acea previziune este mult din ceea ce face ca un lider senior să merite sarea sa.