La mayoría de los proyectos que fracasan no fracasan por el código: fracasan porque nadie acordó qué problema se estaba resolviendo.
Un diagnóstico nuestro no es un documento de recomendaciones generales. Es un inventario de lo que tienes, una arquitectura objetivo y un plan de migración con orden, costo y fecha.
Trabajamos sobre el sistema real, no sobre la descripción que alguien hizo de él. Leemos el código, miramos la base de datos, revisamos los despliegues y hablamos con quien lo opera todos los días.
Entrevistas con negocio y con quienes operan. Acceso al código y a la infraestructura. No pedimos documentación: si existiera, no nos habrían llamado.
Revisión técnica real: calidad del código, modelo de datos, puntos únicos de falla, costos de infraestructura y cuellos de botella medidos, no supuestos.
Arquitectura objetivo, plan por fases y estimación. Presentación de resultados con las decisiones abiertas explícitas, para que las tome quien debe tomarlas.
La mayoría de las iniciativas de datos mueren en el piloto. Normalmente no por el modelo, sino porque nadie resolvió de dónde salen los datos ni quién mantiene el resultado.
Ver →Construimos sistemas que otra gente va a mantener. Eso cambia cómo se escriben.
Ver →Una interfaz se juzga con un usuario cansado, con prisa y con el sol de frente. No en una pantalla de presentación.
Ver →Diagnóstico inicial sin costo. Respondemos con un alcance concreto, con costo y fecha.