Por qué importan las demos semanales en DX de alcance cerrado
Los proyectos DX pierden impulso cuando el progreso es invisible. Las demos semanales resuelven ese problema haciendo el trabajo tangible antes de que los supuestos se den por sentados.
En un sprint de automatización con IA de alcance cerrado, la demo no es una ceremonia. Es el sistema de control. Todo lo demás (el email de estado, el tablero de tickets, el gráfico de burndown) viene después. Sin una demo funcional a la que reaccionar, el resto de artefactos del proyecto se convierten en opiniones en lugar de mediciones.
Qué muestra una buena demo
Una demo útil muestra el flujo de trabajo moviéndose de extremo a extremo, aunque la primera versión sea tosca.
Qué datos entraron en el sistema
Qué extrajo, clasificó o resumió la IA
Dónde ocurre la revisión humana
Qué salida se genera
Qué casos límite siguen fallando
Esa visibilidad permite al responsable de negocio corregir el rumbo pronto.
Una estructura de demo que produce feedback útil de forma consistente en 30 minutos:
1. Recapitulación (2 min). Qué se acordó la semana pasada, qué ha cambiado y cuál es el objetivo de la demo de hoy.
2. Recorrido de extremo a extremo (10 min). Datos reales, entorno real, sin diapositivas. Empieza por el trigger y sigue el flujo de trabajo hasta la salida. Haz una pausa donde la IA toma una decisión y muestra la evidencia y la confianza.
3. Casos límite (5 min). Dos o tres ejemplos deliberadamente difíciles. Muestra lo que el sistema hace hoy, incluidos los fallos.
4. Decisiones pendientes (5 min). Una lista corta con una diapositiva o nota por punto: "proponemos X, las alternativas son Y o Z, el responsable de negocio decide antes del viernes".
5. Plan de la próxima semana (5 min). Qué será diferente en la demo dentro de una semana. Puntos específicos y comprobables.
6. Preguntas abiertas (3 min). Con tiempo acotado.
La demo se ejecuta siempre sobre la última build desplegada, no en el portátil de un desarrollador. Si no puede reproducirse desde una URL que el responsable de negocio pueda abrir, no es de fiar.
Por qué protege el alcance
Las demos semanales hacen visibles los intercambios. Si aparece una nueva petición, el equipo puede compararla con el resultado acordado, los criterios de aceptación y el calendario.
Un patrón que funciona para las conversaciones de alcance durante la demo:
Mantén un único documento vivo, el "registro de alcance", con el resultado acordado, los elementos incluidos, las exclusiones y las órdenes de cambio hasta la fecha.
Las nuevas peticiones se anotan en una sección de "cambios candidatos" en el momento en que surgen.
Cada candidato se estima en tiempo de calendario, no en story points, y se presenta en la siguiente demo con dos opciones: mantener el alcance actual y aplazarlo, o intercambiarlo por un elemento existente.
El responsable de negocio toma la decisión en la reunión, por escrito, con las dos opciones a la vista.
Así es como el alcance cerrado se mantiene justo. El cliente ve el progreso y el equipo de entrega evita la expansión silenciosa. El scope creep (expansión del alcance) más caro es el que nadie nombró en su momento, y una demo semanal con un registro escrito es la forma más barata de evitarlo.
El mejor participante
La persona más importante de la demo es el responsable de negocio. Sabe si el flujo de trabajo va a ayudar de verdad al equipo. Su trabajo en la reunión no es aprobar funcionalidades una a una, sino responder a una única pregunta por demo: "¿seguimos en camino hacia una decisión que el negocio pueda usar?"
Una checklist previa a la demo útil para el equipo de entrega:
¿Está la última build desplegada y accesible desde fuera de la red de desarrollo?
¿Hay al menos un ejemplo con datos reales (o representativos)?
¿Puede ejecutarse la demo en menos de 15 minutos incluyendo preguntas?
¿Están las decisiones abiertas escritas de antemano?
¿Hay una pantalla, grabación o URL que el responsable de negocio pueda compartir con dirección después de la llamada?
Sin el responsable de negocio, el sprint puede seguir produciendo software, pero quizá no produzca una decisión. Una demo sin decisión es solo una reunión de estado; una decisión sin demo es solo esperanza. Las demos semanales son la forma en que un sprint de alcance cerrado evita ambas cosas.