02. Diagnóstico de raíz
Antes de actuar, entender de verdad.
Analizo la situación técnica y operativa completa para separar síntomas, deuda, causas y decisiones pendientes.
01. Punto de partida
Poner un parche rápido puede salir muy caro.
Una web lenta puede esconder una arquitectura defectuosa. Un proceso manual puede existir porque los datos no son fiables. Un proyecto bloqueado puede ser un problema de responsabilidad, no de desarrollo. El diagnóstico evita invertir sobre una explicación incompleta.
Los fallos se repiten aunque cada incidencia se resuelva por separado.
No hay certeza sobre si mantener, sustituir o reconstruir un sistema.
Un proveedor propone una solución, pero dirección no puede evaluar si es la adecuada.
El problema afecta a varias áreas y nadie dispone de una lectura común.
02. Principio de intervención
No doy por válida la primera explicación ni convierto una auditoría en una colección de fallos. Investigo hasta poder conectar causa, impacto y decisión.
03. Arquitectura
Del síntoma a una decisión defendible.
El alcance se adapta a la situación, pero la responsabilidad siempre queda explícita.
Lectura completa
Sistemas, procesos, personas, datos, dependencias, riesgos y contexto de negocio.
Causa y alternativas
Qué está ocurriendo, por qué, qué opciones existen y qué implica cada una.
Plan de acción
Prioridades, alcance, responsables, secuencia y criterios para ejecutar o dirigir la mejora.
04. Proceso
Qué ocurre durante el trabajo.
No aplico una secuencia rígida, pero sí mantengo una responsabilidad continua: comprender, decidir, ejecutar y comprobar.
Definir la pregunta correcta.
Acordamos qué duele, a quién afecta, qué decisiones están bloqueadas y qué información hace falta para responder sin abrir un análisis infinito.
Observar sistema y operación.
Reviso arquitectura, datos, rendimiento, seguridad, procesos, personas y proveedores según el caso. Contrasto documentación con el trabajo real.
Relacionar los hallazgos.
Separo incidencias puntuales, deuda acumulada y causas estructurales. Valoro impacto, urgencia, dependencia y coste de no actuar.
Construir una salida viable.
Presento alternativas, renuncias, prioridades y una ruta de actuación. Si continúa el proyecto, el diagnóstico se convierte directamente en dirección de la ejecución.
05. Capacidades y herramientas
Tecnología cuando aporta control.
No impongo un stack. Estas son capacidades y herramientas que pueden formar parte de la intervención cuando encajan con el problema.
Evidencia
- Logs
- Lighthouse
- Datos
- Flujos reales
Análisis
- Arquitectura
- Rendimiento
- Seguridad
- Dependencias
Decisión
- Escenarios
- Riesgos
- Impacto
- Hoja de ruta
06. Criterio de éxito
Lo que debe haber cambiado al terminar.
El problema deja de depender de opiniones y cuenta con una explicación sustentada.
Dirección puede comparar alternativas y decidir con una lectura común del riesgo.
Las urgencias quedan separadas de las mejoras estructurales y ordenadas por impacto.
El siguiente equipo recibe contexto, prioridades y criterios suficientes para actuar.
07. Siguiente paso