El problema real
No era "falta de tecnología". Era que el conocimiento operacional vivía en la cabeza de una persona. Cuando esa persona se iba de vacaciones, la planificación se resentía. Y cuando hablábamos de muelles, grúas y turnos de 500+ trabajadores, "resentirse" significaba miles de dólares en demoras por hora.
El cliente ya había intentado dos soluciones "enterprise" que fracasaron porque los equipos de implementación nunca entendieron la operación real. Nos pidieron un MVP con una condición: en 8 semanas tenía que estar funcionando con datos reales.
Semana 1 — Inmersión
No empezamos codeando. Pasamos 3 días en terreno: entrevistas con planners, supervisores de turno, operadores de grúas. Encontramos tres cosas que ningún requerimiento formal había capturado:
- La planificación no era algorítmica, era heurística. El planner no "optimizaba" — aplicaba reglas no escritas: "nunca programes mantenimiento de grúa en turno de alta marea"
- Los datos no estaban sucios, estaban en dialectos. Cada área nombraba los eventos distinto. "Carga general" para unos era "break bulk" para otros
- El MVP no podía reemplazar al planner, tenía que aumentarlo. El objetivo no era automatizarlo todo, sino darle una recomendación que él pudiera aceptar, modificar o rechazar en 30 segundos
Semana 2-3 — Datos y baseline
Consolidamos 4 fuentes de datos dispares:
- Excel histórico de planificación (3 años, 14 columnas, 0 normalización)
- CSV exportado del sistema de muelles (formato propietario)
- Bitácora de incidencias en PDFs escaneados
- Planillas manuales de asignación de grúas
Usamos Python + pandas para limpiar y unificar. La IA nos ayudó a interpretar los PDFs escaneados (OCR + extracción semántica con Claude). En paralelo, construimos el baseline: un predictor naive que usaba promedios históricos para tener con qué comparar.
Dato concreto: El baseline naive ya era mejor que la planificación manual en un 12% de precisión. Eso no era mérito del algoritmo — era porque el humano no podía procesar 3 años de datos históricos en cada decisión. La máquina sí.
Semana 4-6 — Modelo y frontend funcional
Entrenamos un modelo XGBoost con características de: hora, día de semana, marea, tipo de carga, grúas disponibles, histórico de demoras. Output: probabilidad de atraso por ventana de 2 horas, con ranking de causas probables.
El frontend era una SPA liviana (HTML + JS plano, sin framework) con un dashboard que mostraba: grid de turnos con semáforo (verde/amarillo/rojo) y un panel de "recomendación del día". El planner podía hacer clic para aceptar o ajustar.
Stack completo: Python (FastAPI + XGBoost) + SQLite + vanilla JS. Sin Kubernetes, sin cola de mensajes, sin overengineering. El MVP se deployó en una VM con 4 GB de RAM.
Semana 7 — Validación en paralelo
Durante 7 días, el sistema corrió en paralelo con la operación real. El planner planificaba normal, y después comparábamos su plan con la recomendación del modelo. Resultados:
- Precisión del modelo: 78% vs 63% del baseline naive
- En 3 de los 7 días, el planner adoptó la recomendación completa
- Tiempo de planificación diaria bajó de 2 horas a 25 minutos (con revisión)
- El modelo detectó 2 patrones de demora que el planner no había identificado: correlación entre turno nocturno de jueves y falta de repuestos de grúa
Lección importante: El MVP no reemplazó al planner — lo hizo más efectivo. Él seguía tomando las decisiones finales, pero ahora llegaba preparado. En sus propias palabras: "Antes pasaba la mañana armando el rompecabezas. Ahora empiezo validando."
Lo que aprendimos
- El 50% del tiempo del MVP fue entender el dominio, no escribir código. Saltarse la inmersión en terreno es la razón #1 por la que los MVPs de IA fallan.
- La precisión del 78% fue suficiente porque el humano estaba en el loop. Si hubiera necesitado 95% para ser útil, el MVP habría fracasado. Diseñar para aumento humano, no para reemplazo total.
- Stack minimalista gana en MVPs. Si hubiéramos armado una arquitectura de microservicios con Kafka y GraphQL, las 7 semanas no habrían alcanzado ni para el infra.
- Los datos chicos pero relevantes vencen a datos grandes pero ruidosos. 3 años del mismo puerto bien curados > datasets gigantescos con señales débiles.