Criterios de aceptación por escrito: lo que hace seguro un proyecto de alcance cerrado
«Alcance cerrado» suena seguro. Un entregable definido, un precio definido, una fecha definida. Pero un alcance descrito solo en prosa («un dashboard funcionando», «un asistente de IA para soporte») no está cerrado en absoluto. Cada parte imagina algo distinto, y la brecha entre esas dos imágenes aflora en el peor momento posible: la entrega.
Lo que de verdad cierra un alcance es una lista corta de criterios de aceptación: frases escritas y verificables que definen qué significa «terminado» antes de empezar.
Cómo es un buen criterio
Un criterio útil es algo que una persona no técnica puede verificar mirando el sistema en marcha. Compara:
Vago: «El sistema clasifica los emails de soporte entrantes.»
Verificable: «Con los 50 emails de muestra aportados por el cliente, el sistema asigna categoría y respuesta sugerida a un mínimo de 45, y cada clasificación aparece en la cola de revisión con su puntuación de confianza.»
La segunda versión hace tres trabajos a la vez. Le dice al ingeniero exactamente qué construir, te dice a ti exactamente qué comprobar en la demo, y convierte la conversación final de aceptación de un intercambio de opiniones en una checklist.
El conjunto mínimo que evita la mayoría de disputas
No hacen falta docenas de criterios. Para una construcción de 2 a 6 semanas, una lista de una página suele bastar:
1. Criterios funcionales. De tres a ocho frases como la del ejemplo, cada una ligada a datos de muestra o a un escenario concreto acordado de antemano.
2. Exclusiones. Lo que el proyecto deliberadamente no incluye. Las exclusiones no son pesimismo; son el borde honesto del presupuesto. Todas las disputas que he visto empezaron en el espacio no escrito.
3. Puertas de calidad. Dónde debe ejecutarse el sistema (tu cuenta cloud), con qué se entrega (documentación, un entorno reproducible, notas de traspaso) y qué pasa con el código (tu repositorio, cedido por escrito).
4. Una cadencia de demos. Demos semanales de software funcionando, con tu aprobación registrada. Unos criterios revisados cada semana no pueden desviarse mucho.
Cambiar está bien. Cambiar en silencio, no.
Alcance cerrado no significa alcance congelado. Los proyectos reales aprenden cosas. La protección es un proceso formal de cambios: cuando nueva información altera el plan, la lista de criterios se actualiza por escrito, con el impacto en plazo y precio declarado antes de hacer el trabajo. Lo que nunca debe ocurrir es el cambio silencioso en cualquier dirección: ni el proveedor recortando esquinas sin decirlo, ni el cliente añadiendo «una cosita más» cada semana.
Quién debería escribir el primer borrador
El proveedor. Escribir criterios verificables exige saber qué es técnicamente comprobable, y un proveedor que se resiste a ponerlos por escrito te está diciendo algo importante sobre cómo irá la entrega. Tu trabajo es revisar el borrador y asegurarte de que describe tu problema de negocio, no solo salidas técnicas convenientes.
En Urbano DX, los criterios de aceptación y las exclusiones se fijan en el SOW antes de empezar, las demos semanales se contrastan con ellos, y un hito que no cumple sus criterios se corrige antes de contar como entregado. Esa última frase es todo el mecanismo de seguridad: los criterios solo te protegen si incumplirlos tiene consecuencias.
Si quieres ver cómo sería un alcance con criterios primero para tu proyecto, la auditoría de pago produce exactamente ese documento.