Jak identyfikujesz i łagodzisz ryzyko techniczne?

Question

Accepted Answer

**Ryzyko techniczne** to wszystko, co mogłoby uniemożliwić dostarczenie lub złamać się w produkcji, nieznane czynniki, kruche zależności, limity skalowania, pojedyncze punkty awarii. Zadaniem TL jest **ujawnić ryzyko wcześnie i celowo je zmniejszać**, ponieważ ryzyko jest najtańsze do rozwiązania, zanim zbudujesz na nim.

## Dlaczego to ważne

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

## Zmniejszaj ryzyko wcześnie, nie późno

Najniebezpieczniejsze ryzyka to *niewiadome*, rzeczy, których nie potrafisz oszacować. Zajmij się nimi najpierw szpikulcem lub prototypem, abyś poznał prawdę, gdy projekt jest jeszcze tani do zmiany. Zbudowanie najpierw łatwych, znanych części wydaje się produktywne, ale pozostawia minę na koniec.

## Konkretny przykład

Projekt zależy od interfejsu API strony trzeciej, którego nigdy nie używałeś na dużą skalę. Nie projektuj całego systemu zakładając, że działa, prototypuj go w pierwszym tygodniu. Jeśli nie radzi sobie z Twoim obciążeniem, dowiesz się tego teraz, a nie po zbudowaniu wokół niego wszystkiego.

## Pułapka

Robienie wygodnych, znanych prac najpierw i oszczędzanie straszliwego nieznanego na koniec. To maksymalizuje koszt bycia w błędzie, dokładnie odwrotnie.

## Dlaczego to ważne

Ryzyka ignorowane do późna stają się kryzysami, kosztowne, niszczące harmonogram i demoraluzujące.

TL, który poluje na ryzyko wcześnie, wymienia małą znaną cenę teraz za uniknięcie dużej nieznanej ceny później.

Ta dalekowzroczność to wiele z tego, co sprawia, że starszy lider jest wart swojej soli.