Gestión de Cambios y Riesgos
El cambio y la incertidumbre son consustanciales al desarrollo de software. Un proyecto profesional no intenta evitar los cambios de forma rígida ni ignora las amenazas potenciales: establece procedimientos formales de control de cambios y un análisis continuo de riesgos.
1. El Proceso de Control Integrado de Cambios #
Cuando un cliente o interesado solicita añadir o modificar una funcionalidad a mitad del proyecto, aceptar la petición informalmente por correo o chat provoca desbordamientos presupuestarios (Scope Creep).
El estándar de gestión exige seguir un flujo formal de control de cambios:
1Petición de Cambio (Cliente/Equipo) 2 │ 3 ▼ 4 [Análisis de Impacto Técnico y Económico] ──► Evalúa coste extra, retraso en días y riesgos 5 │ 6 ▼ 7 [Comité de Control de Cambios / CCB] ──► Decisión formal: APROBAR / RECHAZAR / POSPONER 8 │ 9 ▼ 10 [Actualización de Línea Base & Change Log] ──► Si se aprueba, se amplía presupuesto o plazo
- Comité de Control de Cambios (Change Control Board - CCB): Grupo responsable de revisar, evaluar y aprobar o rechazar solicitudes de cambio.
- Registro de Cambios (Change Log): Documento vivo donde queda registrado cada cambio solicitado, quién lo pidió, fecha, impacto evaluado y estado de aprobación.
2. Gestión de Riesgos: Definición y Tipología #
Un riesgo es un evento o condición incierta que, si se produce, tiene un efecto positivo (oportunidad) o negativo (amenaza) sobre uno o más objetivos del proyecto (plazo, coste, alcance o calidad).
Diferencia Crítica: Riesgo frente a Problema #
- Riesgo: Suceso potencial futuro que aún no ha ocurrido ("Es posible que la API de la pasarela de pago cambie su versión antes del lanzamiento"). Se previene.
- Problema / Incidencia (Issue): Suceso perjudicial que ya ha ocurrido en el presente ("La base de datos de producción se ha caído hoy"). Se resuelve.
Tipos de Riesgos en Software: #
- Técnicos: Obsolescencia de librerías, problemas de escalabilidad bajo alta carga, vulnerabilidades de seguridad (zero-day).
- De Recursos: Pérdida o baja médica del desarrollador clave de la arquitectura, falta de formación en un nuevo framework.
- Organizativos / Negocio: Recorte imprevisto de presupuesto por la dirección, quiebra de un cliente principal.
- Externos / Legales: Cambios en normativas de privacidad (RGPD) o nuevas exigencias de las tiendas de apps (App Store / Play Store).
3. Matriz de Evaluación de Riesgos y Nivel de Exposición #
Para priorizar qué riesgos requieren atención inmediata, se calcula el Nivel de Severidad:
1IMPACTO 2 1 (Muy bajo) 2 (Bajo) 3 (Medio) 4 (Alto) 5 (Crítico) 3 ┌─────────────┬──────────┬───────────┬──────────┬─────────────┐ 4 5 (Muy alta│ 5 │ 10 │ 15 │ 20 │ 25 │ ◄── Zona Crítica 5 4 (Alta) │ 4 │ 8 │ 12 │ 16 │ 20 │ (Acción inmediata) 6P 3 (Media) │ 3 │ 6 │ 9 │ 12 │ 15 │ 7R 2 (Baja) │ 2 │ 4 │ 6 │ 8 │ 10 │ 8O 1 (Muy baja│ 1 │ 2 │ 3 │ 4 │ 5 │ ◄── Zona Baja 9 └─────────────┴──────────┴───────────┴──────────┴─────────────┘ (Monitorizar)
4. Las Cuatro Estrategias de Respuesta a Riesgos Negativos #
| Estrategia | Descripción | Ejemplo Real en Software |
|---|---|---|
| 1. Evitar (Avoid) | Cambiar la arquitectura o el plan para eliminar completamente la amenaza. | No utilizar una librería beta inestable y programar la solución con tecnología probada. |
| 2. Mitigar (Mitigate) | Reducir la probabilidad de que ocurra o minimizar el daño potencial. | Implementar réplicas automáticas de bases de datos y backups horarios para mitigar pérdida de datos. |
| 3. Transferir (Transfer) | Trasladar el impacto y la gestión del riesgo a un tercero. | Contratar un servicio cloud administrado (AWS RDS) con SLA del 99.99% en lugar de mantener servidores propios. |
| 4. Aceptar (Accept) | Asumir conscientemente el riesgo si su probabilidad/coste es muy bajo. | Aceptar de forma activa asignando una reserva económica de contingencia por si se produce. |
5. Caso Práctico: Plan de Contingencia #
Un equipo desarrolla una aplicación de banca móvil. Identifica el riesgo de que la pasarela SMS para autenticación en dos pasos (2FA) sufra caídas temporales de servicio:
- Probabilidad: Media (3). Impacto: Crítico (5). Severidad: 15 (Zona alta).
- Plan de Mitigación: Integrar un proveedor de SMS secundario en la nube con failover automático si el proveedor principal no responde en 3 segundos.
Resumen del tema
Conceptos clave #
- Control Integrado de Cambios: proceso formal de solicitud, análisis de impacto en la triple restricción, aprobación/rechazo por comité (CCB) y registro en el Change Log.
- Riesgo vs Problema: el riesgo es una incertidumbre potencial futura (amenaza u oportunidad); el problema es un hecho consumado que ya impacta en el proyecto.
- Matriz de Evaluación de Riesgos: cuantificación cualitativa mediante la fórmula .
- Estrategias de Respuesta a Riesgos Negativos:
- Evitar: alterar el plan para eliminar la amenaza.
- Mitigar: reducir la probabilidad de ocurrencia o el impacto del daño.
- Transferir: trasladar el impacto y la propiedad a un tercero (ej. pólizas, externalizaciones).
- Aceptar: asumir el riesgo de forma activa (con reserva de contingencia) o pasiva.
Qué debes recordar #
La gestión proactiva de riesgos (probabilidad e impacto) y el control sistemático de solicitudes de cambio protegen el proyecto frente a desviaciones presupuestarias y de plazos.