Cómo los sprints DX a precio cerrado evitan el scope creep
La entrega DX a precio cerrado puede funcionar bien, pero solo con disciplina de alcance. Sin esa disciplina, el scope creep (expansión del alcance) convierte silenciosamente un pequeño sprint de automatización en un amplio proyecto de transformación.
La respuesta no es alargar la propuesta. La respuesta es hacer los límites más claros. Un Statement of Work (SOW) de 30 páginas que lo enumera todo en párrafos vagos crea más riesgo de alcance, no menos, porque a posteriori cualquier cosa puede defenderse como parte del alcance. Un SOW corto y específico, con exclusiones explícitas, hace lo contrario: obliga a que cada petición de "ya que estamos" se convierta en un cambio por escrito.
Qué hay que dejar por escrito
Antes de empezar a construir, el proyecto debe definir:
Resultado de negocio
Flujos de trabajo incluidos
Sistemas e integraciones incluidos
Supuestos sobre el modelo de IA y los datos
Supuestos de seguridad
Criterios de aceptación
Exclusiones
Responsabilidades del cliente
Proceso de órdenes de cambio
Estos puntos protegen a ambas partes.
Una plantilla útil para cada sección:
Resultado de negocio. Una frase con las palabras del propio equipo. "Reducir un 50% el tiempo hasta la primera respuesta en los tickets de soporte de nivel 1 con una cola de borradores de IA aprobados por humanos."
Flujos de trabajo incluidos. Flujos con nombre, con su trigger y su salida. Todo lo que no esté en la lista queda fuera del alcance.
Sistemas incluidos. Cada integración listada con su método de autenticación, lectura o escritura, sandbox o producción. "Lectura desde Zendesk vía OAuth en sandbox; escritura solo en el Postgres interno."
Supuestos de IA. Proveedor, familia de modelos, idiomas esperados, residencia de datos, política de retención, tamaño del conjunto de evaluación.
Supuestos de seguridad. Qué datos salen de la red corporativa, qué se enmascara, qué logs se retienen, quién tiene acceso de administrador.
Criterios de aceptación. Medibles, escritos antes del kickoff, firmados por el responsable de negocio. "85% de precisión de enrutado sobre un conjunto reservado de 100 tickets, con la confianza visible en cada decisión."
Exclusiones. Explícitas y específicas. Ver la siguiente sección.
Responsabilidades del cliente. Datos de muestra en X días, acceso al sandbox en Y días, disponibilidad del responsable de negocio de Z horas por semana, calendario de la revisión de seguridad.
Proceso de órdenes de cambio. Cómo una nueva petición se convierte en un intercambio o en un extra de pago. Plantilla adjunta como anexo.
Por qué importan las exclusiones
Las exclusiones no son algo negativo. Son lo que hace posible el primer sprint. Una primera versión acotada puede generar prueba suficiente para un segundo paso más ambicioso.
Exclusiones concretas que conviene nombrar pronto, por categoría:
Flujos de trabajo. "Los mensajes proactivos salientes quedan fuera del alcance. El soporte multilingüe más allá del japonés y el inglés queda fuera del alcance."
Integraciones. "La integración con Salesforce queda fuera del alcance; la entrega se hace por exportación CSV. El SSO con el IdP corporativo queda fuera del alcance; se usa autenticación por magic link."
Comportamiento de la IA. "Las decisiones automáticas sin aprobación humana quedan fuera del alcance. El fine-tuning de modelos a medida queda fuera del alcance."
Operaciones. "La monitorización 24/7 queda fuera del alcance. La rotación de guardias queda fuera del alcance. El backfill de datos más allá de los últimos 90 días queda fuera del alcance."
Cumplimiento. "La documentación formal ISO 27001 queda fuera del alcance. Se incluye una nota de seguridad breve que cubre el despliegue del sprint."
Si todas las ideas futuras se incluyen en el primer sprint, el calendario se vuelve poco fiable y la demo final pierde claridad. La lista de exclusiones no dice "no" para siempre: dice "no en este sprint". Es un marco útil para ambas partes: nada se rechaza, todo tiene su lugar, y ese lugar es ahora o más adelante.
El papel de las demos semanales
Las demos semanales facilitan las conversaciones de alcance porque todo el mundo puede ver el progreso. Cuando aparece una nueva petición, el equipo puede preguntarse si apoya el resultado acordado o pertenece al siguiente sprint.
Un ritmo de órdenes de cambio que funciona durante el sprint:
1. Captura. Las nuevas peticiones se anotan en una sección de "cambios candidatos" en cuanto aparecen, con quién las pide, la fecha y un resumen de una frase.
2. Estimación. Cada candidato se estima en días de calendario, no en puntos, asumiendo que el presupuesto es fijo.
3. Presentación. En la siguiente demo, el equipo muestra cada candidato con dos opciones: mantener el alcance actual y aplazarlo, o intercambiarlo por un elemento existente.
4. Decisión. El responsable de negocio decide por escrito durante la demo. Todo lo aplazado pasa a alimentar la propuesta del siguiente sprint.
5. Firma. Cualquier elemento que añada tiempo o coste se recoge en una orden de cambio de una página, firmada antes de empezar el trabajo.
Así es como un sprint a precio cerrado se mantiene rápido y justo. El mecanismo no es burocracia: es la mínima cantidad de escritura que evita la expansión silenciosa que mata la entrega a precio cerrado. Bien hecho, el proceso de órdenes de cambio es invisible: simplemente significa que cada demo semanal termina con el equipo y el cliente acordando, en la misma sala, los próximos siete días.