¿Cómo identificas y mitiga el riesgo técnico?

Question

Accepted Answer

**Riesgo técnico** es cualquier cosa que podría detener la entrega o fallar en producción, incógnitas, dependencias frágiles, límites de escalabilidad, puntos únicos de fallo. El trabajo de un TL es **surfaciar el riesgo temprano y reducirlo deliberadamente**, porque el riesgo es más barato de abordar antes de que hayas construido sobre él.

## Por qué es importante

```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-riesgo temprano, no tarde

Los riesgos más peligrosos son las *incógnitas*, las cosas que no puedes estimar. Abórdalas primero con un spike o prototipo, para que aprendas la verdad mientras el proyecto sigue siendo barato de cambiar. Hacer primero las partes fáciles y conocidas se siente productivo pero deja la mina antipersonal para el final.

## Un ejemplo concreto

Un proyecto depende de una API de terceros que nunca has usado a escala. No diseñes todo el sistema asumiendo que funciona, haz un prototipo contra ella en la semana uno. Si no puede manejar tu carga, lo descubrirás ahora, no después de haber construido todo alrededor de ella.

## Una trampa

Hacer primero el trabajo cómodo y conocido, guardando lo desconocido y aterrador para el final. Eso maximiza el costo de estar equivocado, exactamente al revés.

## Por qué es importante

Los riesgos ignorados hasta tarde se convierten en crisis, costosas, destructoras del cronograma y desmoralizantes.

Un TL que busca riesgo temprano intercambia un costo conocido pequeño ahora por evitar un costo desconocido grande después.

Esa previsión es gran parte de lo que hace que un lead senior valga su peso en oro.