Cómo escribir criterios de aceptación para software de alcance cerrado
«Un panel que funcione» deja demasiado a la interpretación. Los criterios de aceptación por escrito describen la entrada, el comportamiento esperado y la evidencia que utilizará quien revise para aceptar una entrega.
Acuerda esos criterios junto con el alcance, las exclusiones y las condiciones de entrega antes de empezar. Proporcionan una forma compartida de comprobar si el trabajo está terminado; no garantizan resultados de negocio ni eliminan todos los riesgos.
Incluye cinco elementos en cada criterio
Escenario: quién utiliza el sistema, con qué permisos y con qué entrada.
Comportamiento esperado: qué puede observar o hacer esa persona.
Condición de aprobación: qué debe cumplirse, incluido cualquier umbral acordado.
Evidencia: qué prueba, demostración, salida o registro recoge el resultado.
Revisión: quién lo acepta y cuándo lo comprueba.
Sustituye «la integración es fiable» por un escenario concreto. Los ejemplos siguientes muestran cómo redactarlo: son propuestas de comprobación, no resultados de un proyecto de cliente.
Ejemplo 1: una app de aprobación de solicitudes
Una persona del piloto con permisos de solicitante envía una solicitud válida. Se crea un registro con responsable y estado. Quien tiene permiso de revisión puede aprobarla y consultar la decisión registrada. La persona solicitante no puede aprobarla, tampoco mediante la API.
La evidencia es el recorrido acordado y las pruebas de permisos en el entorno de prueba. Añade comprobaciones separadas para campos obligatorios vacíos y errores al guardar. Identifica los perfiles y pantallas incluidos para que el criterio no se convierta, sin acordarlo, en la especificación de un producto completo.
Ejemplo 2: una integración de API
Con un pedido de prueba aprobado, el destino recibe una sola vez los campos acordados. Repetir el evento no crea otro pedido. Si el destino no está disponible, el fallo queda registrado y el procedimiento de recuperación acordado permite completar la transferencia sin duplicados.
Este escenario es relevante en sistemas basados en eventos: Stripe documenta que los eventos de webhook pueden llegar más de una vez. Consulta su guía de webhooks.
Define la interrupción que se probará, los pasos de recuperación y la evidencia. Una recuperación correcta en una prueba no demuestra que estén cubiertas todas las caídas futuras.
Ejemplo 3: un flujo de IA para documentos
Acuerda tipos de documento, campos, respuestas de referencia y método de puntuación. Reserva ejemplos representativos para la evaluación que no se utilicen para ajustar el sistema. En cada ejecución, conserva las salidas, los errores, los campos ausentes y las correcciones necesarias para valorar el resultado.
Si propones un umbral de acierto, define sobre qué total se calcula, cómo cuentan los resultados parciales y qué errores son inaceptables. Acuerda repeticiones cuando la variabilidad pueda cambiar la decisión. La confianza que declara el modelo no es una prueba de corrección.
Comprueba también la revisión: las entradas incompletas o no admitidas deben llegar al paso de revisión humana acordado, y el sistema no debe ejecutar una acción sujeta a aprobación antes de recibirla.
Distingue entre terminar el PoC y estar listo para producción
Un PoC puede entregar un experimento ejecutable y una evaluación que muestre que el enfoque no sirve. Aclara antes si el encargo compromete un experimento, un umbral medido o ambas cosas, y qué ocurre si no se alcanza el umbral.
Para un piloto operativo, incluye expresamente los permisos, el despliegue, la supervisión, la recuperación y el soporte necesarios. Añade acceso al repositorio, instrucciones de puesta en marcha y comprobaciones de traspaso cuando corresponda. Una demo convincente no demuestra por sí sola esas condiciones.
Revisa el avance y los cambios con la misma lista
Utiliza los criterios en las demos de progreso. Registra qué comprobaciones pasan, cuáles fallan y qué dependencias siguen pendientes. Si hace falta otro sistema, idioma o proceso, documenta su efecto en entregables, precio y plazo, y acuerda la revisión antes de hacer ese trabajo.
El primer borrador debe trabajarse entre ambas partes: quien desarrolla hace que cada comprobación sea verificable, y quien conoce el proceso confirma que evalúa la tarea de negocio prevista.
Lleva un brief de proyecto de una página a esa conversación. Si aún no has elegido el proceso, empieza por qué construir primero.
Explora los paquetes de alcance cerrado para elegir un punto de partida con entregables y criterios de aceptación acordados para tu proyecto.