DX en semanas, no en meses
Los grandes programas de DX pueden ser necesarios, pero a menudo son demasiado lentos para equipos que necesitan pruebas ya. Un sprint enfocado plantea una pregunta más pequeña y más útil: ¿puede un flujo de trabajo problemático volverse más rápido, más claro y más fácil de gestionar en unas pocas semanas?
La respuesta honesta a esa pregunta es el artefacto más valioso que un programa de DX puede producir. Es más útil que un deck de estrategia, más creíble que un benchmark de proveedor y más práctico que una puntuación de madurez. Cuando un equipo ha convivido dos semanas con una versión funcional del flujo de trabajo, la siguiente decisión de inversión deja de ser un debate y se convierte en un plan.
Por qué importa la velocidad
Entregar rápido no consiste en saltarse la calidad. Consiste en acotar el problema hasta que usuarios reales puedan juzgar la primera versión.
Un flujo de trabajo
Un responsable de negocio
Una métrica de éxito
Una cadencia de demos
Una decisión al final
Esa estructura ayuda a los equipos a evitar el trabajo estratégico amplio que nunca llega al terreno. También fuerza una respuesta temprana a las preguntas que suelen descarrilar las fases posteriores: quién es de verdad el responsable de los datos, quién aprueba la salida de la IA, qué sistema recibe el resultado y qué pasa cuando el modelo se equivoca.
Un benchmark interno útil: si la primera versión usable no está delante de un usuario real en diez días laborables, el alcance casi siempre es demasiado amplio. Recorta hasta que encaje.
Cómo es un buen primer sprint
Un primer sprint sólido suele empezar con un flujo de trabajo que ya tiene datos de muestra y un problema operativo visible. Las colas de soporte, los flujos de onboarding, las apps de administración, la entrada de documentos, los traspasos por API, la búsqueda de conocimiento y los informes mensuales son buenos ejemplos.
El objetivo no es automatizarlo todo. El objetivo es crear una prueba fiable de que la siguiente inversión merece la pena.
En la práctica, una entrega de PoC de dos semanas se parece a esto:
Días 0-2: discovery y cierre del alcance. Recorre el flujo de trabajo actual con su responsable. Identifica las entradas, los puntos de decisión, las personas que hoy toman esas decisiones y el sistema de registro que recibe la salida. Congela el alcance por escrito antes de escribir una sola línea de código.
Días 3-7: camino principal. Construye el camino de datos de extremo a extremo, aunque sea tosco. Un pipeline funcional de CSV de entrada, clasificación con LLM y JSON de salida vale más que una UI preciosa sin backend. Enséñalo el día cinco aunque te dé vergüenza.
Días 8-12: interfaz de revisión humana. Añade la interfaz que tocará el usuario real: una pequeña app de administración en Next.js o FastAPI, una cola clara de elementos, referencias a las fuentes, un botón de corrección y registro de auditoría. Aquí es donde se gana o se pierde la adopción.
Días 13-14: traspaso y decisión. Documenta la arquitectura, entrega el código fuente, haz una demo final y produce una recomendación por escrito: integrar, ampliar, refinar o parar.
Una base técnica razonable para un primer sprint:
TypeScript o Python en el backend; React/Next.js en el frontend
Postgres para el estado, con una única tabla `events` o `runs` que registre cada acción de la IA
Un proveedor de LLM (OpenAI o Anthropic) detrás de un wrapper fino, nunca llamado desde el frontend
Salidas estructuradas vía JSON schema, no parseo de texto libre
Una pantalla de revisión humana para cualquier decisión en la que el negocio no pueda permitirse un error silencioso
Nada de esto es exótico. La disciplina está en elegir un pequeño conjunto de herramientas aburridas y negarse a añadir más hasta que el flujo de trabajo esté probado.
Qué viene después de la prueba
Una vez que un PoC funcional se gana la confianza, el siguiente paso puede ser un sprint de MVP, una integración o una bolsa mensual de horas. Esa secuencia mantiene el riesgo controlado mientras da a la dirección pruebas visibles de progreso.
El camino de expansión suele seguir el mismo patrón: reforzar los contratos de datos, añadir autenticación real y permisos basados en roles, sustituir las integraciones simuladas por los SaaS o las APIs internas reales, añadir monitorización y alertas, y escribir el runbook. Cada uno de esos pasos es pequeño por sí solo, pero saltárselos es lo que convierte un PoC prometedor en una herramienta interna que nadie quiere mantener.
La gracia del enfoque de semanas-no-meses no es que la DX pueda terminarse rápido. Es que la primera respuesta creíble debería llegar rápido, para que el resto del programa se construya sobre resultados reales en lugar de diapositivas.