Cuando una feature que antes tardaba tres meses ahora tarda una semana, el problema ya no es cuánto tiempo tienes — el problema es qué construyes primero. La IA ha desplazado el cuello de botella del desarrollo a la priorización, y la mayoría de los equipos aún no ha actualizado su proceso.
El nuevo cálculo de priorización en la era de entrega acelerada
En el modelo tradicional, el costo de construcción dominaba las decisiones de roadmap. La IA cambia esa ecuación: el costo de construcción cae drásticamente, pero el costo de oportunidad sigue siendo el mismo. Ahora la pregunta relevante no es «¿podemos construir esto?» — es «¿qué deberíamos construir esta semana para generar el mayor impacto posible?» Este cambio favorece la experimentación controlada: iterar semana a semana, validar hipótesis más rápido y pivotar con menos costo.
WSJF adaptado para FAST Delivery
El Weighted Shortest Job First (WSJF) es una de las mejores herramientas para priorizar cuando el costo de desarrollo varía. En FAST Delivery ese costo es relativamente uniforme (una semana por feature), lo que hace que el diferenciador sea el valor del negocio y el costo del delay. La adaptación práctica: puntúa cada feature en tres dimensiones — valor para el usuario, valor estratégico, costo de no construirlo esta semana. La feature con mayor puntaje combinado entra a la semana siguiente.
«Un roadmap diseñado para velocidad mensual es un freno cuando tu equipo entrega semanalmente. El proceso de priorización debe correr al ritmo del equipo.»
Cómo comunicar entrega predecible a stakeholders
La comunicación efectiva tiene tres componentes: (1) un tablero visible del backlog priorizado con criterios de puntuación transparentes, (2) un resumen semanal de lo entregado versus lo comprometido, y (3) una distinción clara entre el horizonte confirmado (2-3 semanas) y el horizonte exploratorio (6-8 semanas). Esta distinción es honesta y genera más confianza que un Gantt detallado que siempre se incumple. El equipo que entrega predeciblemente semana a semana tiene más influencia sobre su roadmap que el que entrega grandes releases cada trimestre y siempre llega tarde.
La IA no falla por falta de capacidad técnica — falla por falta de definición precisa. Cuando un equipo entrega prompts vagos a un Delivery Master, el resultado es ciclos de corrección, ambigüedad acumulada y features que nunca terminan de encajar con lo que el negocio necesitaba. La definición no es burocracia: es el verdadero acelerador.
El documento del lunes: qué debe incluir
En FAST Delivery, cada semana empieza con un documento de definición que el PO entrega el lunes. No es un brief creativo — es un contrato funcional. Responde cinco preguntas sin dejar lugar a interpretación: ¿Qué comportamiento nuevo aparece? ¿Cuál es el estado actual del sistema? ¿Cuáles son los criterios de aceptación verificables? ¿Qué está explícitamente fuera de alcance? ¿Cuál es el caso de error principal? Si el documento genera preguntas el lunes, se refina el lunes. Si las genera el miércoles, la feature está en riesgo.
Los criterios INVEST adaptados para construcción dirigida por IA
Small: La IA puede construir features grandes, pero el riesgo de desviación aumenta con la complejidad. Testable: Si no puedes escribir el criterio de aceptación antes de construir, no estás lista para construir. Independent: Las dependencias externas son el principal asesino de la cadencia semanal.
«Una feature bien definida no necesita reuniones de clarificación a mitad de la semana. Una mal definida las necesita todas.»
Ejemplos: buena vs mala definición de feature
Mala: «Mejorar el flujo de onboarding para que los usuarios entiendan mejor el producto.» Sin criterio de aceptación, sin estado inicial definido, no verificable.
Buena: «Agregar un modal de bienvenida que aparece una sola vez al primer login del usuario, muestra tres pasos ilustrados del flujo principal y tiene un botón Comenzar que lo cierra y marca el flag onboarding_completed en el perfil. No incluye animaciones. Criterio: el modal aparece en primer login, no aparece en logins subsecuentes, el flag se guarda correctamente.»
El PO que domina la definición precisa es el PO que convierte la velocidad de la IA en valor real para el negocio — semana tras semana.
La mayoría de los debates sobre calidad ocurren demasiado tarde — el viernes por la tarde, cuando la feature está construida y nadie quiere rehacerla. El PO efectivo en un modelo de entrega con IA no debate calidad al final: la define al principio, con criterios que no dejan margen de interpretación.
Criterios de aceptación que son verificables, no aspiracionales
Un criterio aspiracional suena así: «La experiencia debe ser intuitiva y fluida.» Un criterio verificable: «El usuario puede completar el registro en menos de 3 pasos sin ver mensajes de error si ingresa un email válido.» Si dos personas del equipo leen el criterio y llegan a conclusiones distintas sobre si la feature lo cumple, el criterio está mal escrito. Vuélvelo a escribir antes del lunes.
El PO como guardián de la definición, no de la construcción
El PO no es el QA ni el arquitecto. Es el guardián de la definición. Su trabajo es garantizar que lo que entra al proceso es lo suficientemente preciso para salir como valor entregable el viernes. Esto significa que el PO no interviene durante la construcción para «mejorar» la feature. Si hay algo que mejorar, va al backlog. La semana en curso tiene un alcance fijo.
«Velocidad y calidad no son opuestos — son el resultado natural de una definición precisa hecha con tiempo suficiente.»
El ritual de QA del viernes en FAST Delivery
El viernes no es el día en que se improvisa la revisión — es el día en que se ejecuta un ritual estructurado. Cuatro momentos: (1) el QA ejecuta los criterios de aceptación definidos el lunes; (2) el DM revisa los puntos técnicos; (3) el PO firma el «listo» contra los criterios originales; (4) si algo no pasa, va al backlog como nueva feature, no como bloqueador del deploy. Un bug menor que no afecta el valor principal de la feature se convierte en deuda técnica documentada — no en pretexto para retrasar la entrega. El PO que aprende a decir «esto cumple los criterios» con confianza libera a su equipo para seguir construyendo.
