Checklist antes de empezar un PoC de DX
Un PoC de pago avanza más rápido cuando el equipo del cliente aporta contexto suficiente para tomar decisiones con agilidad. El objetivo no es una documentación perfecta. El objetivo es eliminar los bloqueos que suelen frenar la primera semana.
La mayoría de los PoCs que no llegan a su fecha no fallan porque la tecnología fuera difícil. Fallan porque nadie pudo responder a tiempo una pregunta concreta: qué campo es el autoritativo, quién puede aprobar un borrador, dónde está el entorno de pruebas, quién es el dueño de la API key. Este checklist existe para sacar a la luz esas preguntas antes del kickoff, no después.
Prepara el flujo de trabajo
Nombra al responsable del proceso
Describe el flujo de trabajo actual en cinco a diez pasos
Identifica los traspasos entre pasos, los cuellos de botella y el retrabajo
Define cómo debería ser el éxito después de dos a seis semanas
El responsable del proceso es el elemento más importante de toda la lista. No es el sponsor ejecutivo ni el contacto de IT. Es la persona que hoy hace el trabajo o lo supervisa a diario, que puede responder "¿este borrador es correcto?" en cuestión de horas y que tiene autoridad para decir "sí, esto es lo bastante bueno para salir". Sin ese rol asignado, las demos semanales se convierten en reuniones de estado en lugar de reuniones de decisión.
Al describir el flujo de trabajo, escríbelo con la forma disparador → acción → resultado. Por ejemplo: "Llega un email de cliente a la bandeja compartida → el agente de soporte lo clasifica, redacta una respuesta y adjunta el artículo relevante → respuesta enviada, ticket etiquetado en Zendesk". Cinco a diez pasos bastan. Si no puedes describirlo en diez, el alcance sigue siendo demasiado grande.
Prepara los datos
Trae archivos de muestra seguros, capturas de pantalla, exportaciones, ejemplos de emails o documentación de API. Si los datos reales no se pueden compartir, crea muestras anonimizadas que conserven la estructura real.
En la práctica esto suele significar:
20-50 muestras representativas, no tres. La cola larga es donde la IA se rompe; necesitas variedad suficiente para verla.
Ejemplos tanto del caso típico como de los casos límite. Los PDFs mal formados, los emails de clientes enfadados, los registros con campos vacíos. Estos son los casos que deciden si el PoC llega a producción.
Documentación a nivel de campo para cualquier fuente estructurada: nombres de columnas, tipos, rangos esperados, qué significa null, qué campos son autoritativos cuando dos sistemas no coinciden.
Acceso por API o una vía de exportación estable. Un volcado CSV puntual vale para la primera semana, pero al menos hay que saber cómo fluirían los datos en producción.
Un acuerdo escrito de tratamiento de datos. Qué puede salir de la red corporativa, qué campos deben enmascararse, cuál es la política de retención de los logs de IA. La APPI y cualquier revisión interna de seguridad de la información deberían estar resueltas antes de la primera llamada al modelo.
Anonimizar no es lo mismo que borrar. Sustituye nombres, números de cuenta e identificadores por equivalentes realistas; no elimines campos, porque el flujo de trabajo de IA puede depender de la forma de los datos aunque el contenido esté enmascarado.
Prepara la decisión
Acuerda los criterios de aceptación antes de que empiece el sprint. Al final del PoC, la decisión debería estar clara: parar, refinar, integrar o ampliar.
Los criterios de aceptación deben ser específicos y medibles. Los criterios vagos como "la IA funciona bien" convierten la revisión final en un debate. Ejemplos útiles:
"El modelo clasifica al menos el 85% de los tickets entrantes en la categoría correcta, medido sobre un conjunto reservado de 100 tickets."
"El agente acepta la respuesta redactada sin editarla en al menos el 40% de los casos durante una prueba de una semana."
"El recall de extracción sobre las 20 facturas de muestra es de al menos el 95% para los siete campos requeridos, con una puntuación de confianza visible para el revisor."
Acompaña cada métrica de una vía alternativa: qué pasa con los casos que la IA no puede gestionar. Un PoC que ignora el 10% inferior no es un PoC, es una demo.
Prepara el entorno
Unas pocas decisiones pequeñas de infraestructura eliminan la mayor parte de la fricción de la primera semana:
Un entorno sandbox con credenciales que no sean de producción para cualquier SaaS o sistema interno que toque el flujo de trabajo.
Una identidad para el flujo de trabajo de IA (cuenta de servicio, token de API o JWT firmado) creada con el alcance mínimo necesario.
Un destino de logs que el equipo del cliente pueda leer: incluso una sola tabla compartida de Postgres o un proyecto de Supabase basta para un PoC.
Una URL de demo o un despliegue de staging decididos de antemano. Vercel, Render, Fly o el cloud del propio cliente: cualquier sitio que el responsable de negocio pueda abrir desde el móvil durante la demo semanal.
Esa claridad es lo que convierte un PoC pequeño en una herramienta útil de inversión en DX. El checklist no es burocracia; es lo que hace que "de dos a seis semanas" sea un número honesto en lugar de uno optimista.