Como você identifica e mitiga o risco técnico?

Question

Accepted Answer

**Risco técnico** é qualquer coisa que possa prejudicar a entrega ou quebrar em produção, incógnitas, dependências frágeis, limites de escala, pontos únicos de falha. O trabalho de um TL é **trazer o risco à tona cedo e diminuí-lo deliberadamente**, porque o risco é mais barato de resolver antes de você ter construído em cima dele.

## Por que isso importa

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

## Reduzir risco cedo, não tarde

Os riscos mais perigosos são *incógnitas*, as coisas que você não consegue estimar. Aborde-as primeiro com um spike ou protótipo, para que você aprenda a verdade enquanto o projeto ainda é barato de alterar. Construir as partes fáceis e conhecidas primeiro parece produtivo, mas deixa a armadilha para o final.

## Um exemplo concreto

Um projeto depende de uma API de terceiros que você nunca usou em escala. Não projete todo o sistema assumindo que funciona, faça um protótipo contra ele na primeira semana. Se não conseguir lidar com sua carga, você descobre agora, não depois que construiu tudo ao redor.

## Uma armadilha

Fazer o trabalho confortável e conhecido primeiro e deixar o desconhecido assustador para o final. Isso maximiza o custo de estar errado, exatamente ao contrário.

## Por que isso importa

Riscos ignorados até o final se tornam crises, caras, que destroem cronogramas e destroem moral.

Um TL que caça riscos cedo troca um pequeno custo conhecido agora para evitar um grande custo desconhecido depois.

Essa visão é muito do que torna um líder sênior digno de seu sal.