Criterios de aceptación: cómo un founder no técnico define el hecho
Criterios de aceptación, reescritos para quien paga el software, no para quien lo construye. Una forma en lenguaje simple de definir el “hecho” de cada funcionalidad que encargas, acordada antes de que empiece el trabajo, para que el día de la entrega sea una inspección y no una discusión.
Una founder con la que trabajé el año pasado llevaba una firma boutique de contabilidad. Pagaba a un estudio para que construyera un portal de clientes, y la especificación decía, completa: “Los clientes pueden subir sus facturas del mes.” Todos asintieron. Tres semanas después la funcionalidad estaba “hecha”. El cliente podía subir un archivo. Un archivo. Sin forma de saber a qué mes pertenecía, sin confirmación de que había llegado, sin límite de tamaño, y un PDF de más de diez megabytes fallaba en silencio. Ella creía haber comprado una bandeja de entrada de facturas. Había comprado un selector de archivos. Nadie mintió. La frase que aprobó simplemente no era una definición de hecho.
Los criterios de aceptación son las condiciones que un software tiene que cumplir antes de que aceptes que está terminado y correcto. Convierten una petición vaga de funcionalidad en una lista corta de cosas que son verdaderas o falsas el día de la entrega. En los equipos ágiles suelen escribirlos los product managers en una sintaxis rígida. Para un founder no técnico que compra un desarrollo a medida, ese enfoque es el equivocado. No estás escribiendo tickets para un equipo que diriges. Estás definiendo lo que pagas, a personas que no diriges, para que “hecho” signifique lo mismo para ellas que para ti.
Por qué “hecho” es la palabra más cara de tu proyecto
El hueco que atrapó a mi founder de contabilidad es el hueco entre lo que una funcionalidad parece en una reunión y lo que de verdad tiene que hacer por una persona real. “Los clientes pueden subir sus facturas del mes” es un deseo. Suena completo porque lo puedes imaginar. Pero un desarrollador no construye una imagen. Construye la instrucción literal, y donde la instrucción se detiene, hace una suposición razonable. Su suposición razonable la moldea lo que es más rápido de entregar, porque él también tiene un plazo. Tu suposición razonable la moldea lo que tu cliente necesita. Esas dos suposiciones casi nunca son la misma, y la diferencia aparece en el peor momento posible: cuando el trabajo se “entrega” y el pago se debe.
Esta es la discusión del día de entrega que todo founder no técnico acaba teniendo. Tú dices “esto no es lo que quería”. El estudio dice “esto es lo que estaba escrito”. Los dos tenéis razón, y ahora estás negociando una reconstrucción sin ninguna ventaja, porque aquello que señalas nunca se escribió de una forma que alguien pudiera comprobar. Los criterios de aceptación son cómo evitas esa conversación. Mueven el desacuerdo al principio, cuando cuesta un correo en vez de un hito de pago.
Lo que los criterios de aceptación no son
No son el documento de requisitos. El documento de requisitos dice qué construir y por qué. Los criterios de aceptación dicen cómo sabrás que cada pieza se construyó correctamente. El primero es el pedido; el segundo es el recibo contra el que lo compruebas.
Tampoco son las pruebas de aceptación del usuario, aunque ambos se confunden constantemente. Los criterios de aceptación se escriben antes del desarrollo, como una definición. Las pruebas de aceptación del usuario son el proceso al final, donde te sientas y verificas que los criterios se cumplieron. Escribes los criterios una vez; corres la prueba contra ellos después. Sin los criterios, la prueba es solo tú haciendo clic por ahí esperando notar qué está mal, que es como los founders aprueban software que se rompe la primera semana en que un cliente real lo toca.
Y no sustituyen a decidir qué construir, para empezar. Si no has hecho el trabajo de priorización de funcionalidades, escribir criterios de aceptación para cuarenta funcionalidades solo produce cuarenta cosas bien especificadas que no puedes pagar. Los criterios vienen después de haber decidido que una funcionalidad vale la pena, no en lugar de esa decisión.
Las cuatro preguntas que convierten un deseo en criterio
No necesitas Gherkin, “Given-When-Then” ni ninguna sintaxis formal que los blogs de ágil te van a poner delante. Esa sintaxis existe para ayudar a los ingenieros a automatizar pruebas, y tú no estás automatizando pruebas. Necesitas criterios que puedas leer y comprobar tú mismo. Aquí está la prueba que le doy a todo founder no técnico antes de que apruebe una funcionalidad. Pasa cada criterio propuesto por cuatro preguntas.
Uno: ¿es sobre una persona haciendo algo, y no una cualidad que el software tiene? “El portal es fácil de usar” no es comprobable. “Un cliente puede subir una factura y encontrarla de nuevo al mes siguiente” sí. Escribe los criterios como acciones que un usuario real realiza, con un resultado que pueda ver. Cualidades como rápido, limpio e intuitivo son opiniones; las acciones son hechos.
Dos: ¿puedes comprobarlo tú mismo, sin el desarrollador en la sala? Si verificar un criterio exige que la persona que lo construyó explique por qué cuenta como hecho, no es un criterio. Es su opinión vestida de criterio. El sentido entero es que puedas sentarte solo y dictar el veredicto: pasó o no pasó. Si no puedes, reescríbelo hasta que puedas.
Tres: ¿es binario? Un criterio tiene exactamente dos resultados: pasó o no pasó. “Se ve bien” tiene infinitos resultados y por lo tanto no vale nada el día de la entrega. “Una factura subida muestra el mes bajo el que se archivó, y un archivo de más de diez megabytes muestra un error en vez de fallar en silencio” ocurre o no ocurre. En el momento en que un criterio necesita un juicio, divídelo en las cosas específicas que estabas juzgando de verdad.
Cuatro: ¿se acordó antes del desarrollo? Un criterio inventado en la entrega es una renegociación, no un estándar. Toda la ventaja de los criterios de aceptación viene de acordarlos por adelantado y atarlos a lo que estás pagando. Un criterio que añades después de que el trabajo esté hecho es un favor que estás pidiendo, y lo vas a pagar como tal.
La regla de bolsillo detrás de las cuatro: un buen criterio de aceptación es uno que podrías entregar a un desconocido, y él podría decirte pasó o no pasó sin hacerte una sola pregunta. Si un desconocido tuviera que preguntar “qué significa hecho aquí”, tu desarrollador también lo hará, y lo responderá por ti del modo que entregue más rápido.
Cómo se ven los criterios de aceptación en la práctica
Toma la funcionalidad de facturas que empezó esto. “Los clientes pueden subir sus facturas del mes” es el deseo. Pásalo por las cuatro preguntas y se convierte en una lista corta y comprobable:
- Un cliente con sesión iniciada puede subir una factura en PDF o imagen y etiquetarla a un mes específico.
- Tras subirla, el cliente ve la factura en una lista de ese mes, con el nombre del archivo y la fecha.
- Un archivo mayor de diez megabytes se rechaza con un mensaje visible, no con un fallo en silencio.
- El cliente puede borrar una factura que subió por error, y desaparece de la lista.
- El personal de la firma puede ver las facturas de todos los clientes de un mes dado en una sola vista.
Ninguna de esas frases menciona código. Cada una es algo que la founder puede sentarse a comprobar en cinco minutos, sola, el día de la entrega. Esa es la prueba entera. Fíjate en que la lista también hizo algo más callado: sacó a la luz decisiones que nadie había tomado todavía. ¿Debe el personal ver las facturas en una sola vista? ¿Puede el cliente borrar? Esas preguntas son mucho más baratas de responder ahora, por escrito, que después de que un desarrollador haya adivinado las respuestas.
Cinco frases simples no son trabajo extra. Son el trabajo que ibas a hacer de todos modos, movido al único punto del proyecto en el que todavía es barato.
Donde los criterios de aceptación se encuentran con el dinero
Esta es la parte que los blogs de ágil nunca cubren, porque sus lectores no son quienes firman la factura. Para un founder, los criterios de aceptación no son un capricho de documentación. Son la definición de cuándo se debe un pago.
Un contrato de desarrollo de software bien estructurado ata los pagos por hito a la aceptación, no a fechas de calendario. “La fase dos se paga cuando el módulo de facturas pasa sus criterios de aceptación” es una frase limpia y exigible. “La fase dos se paga el 30 de junio” paga por tiempo, funcione o no la cosa. Si tus criterios son vagos, tus hitos son vagos, y estás pagando en efecto por actividad en vez de por resultados. Los criterios apretados son lo que te deja pagar por resultados sin microgestionar el desarrollo, que es la razón entera de que un founder no técnico contrate a un socio en vez de a un equipo al que tiene que vigilar.
Por eso, también, un estudio competente recibirá bien tus criterios en vez de resistirse a ellos. La aceptación vaga es tan peligrosa para quien construye como para ti: nunca sabe cuándo ha terminado, y el “hecho” se sigue moviendo. Los criterios claros protegen a ambas partes. Un socio que se resiste a escribir lo que “hecho” significa te está diciendo algo sobre cómo piensa definirlo más tarde.
Donde los founders se equivocan con los criterios de aceptación
El primer error es escribir demasiados. No necesitas criterios para cada comportamiento concebible. Los necesitas para el puñado de cosas que, si salieran mal, dejarían la funcionalidad inútil o vergonzosa. Cinco criterios afilados en el módulo de facturas valen más que cincuenta que nadie va a comprobar. Los criterios de aceptación que no verificas no son criterios; son decoración.
El segundo error es esconder requisitos dentro de ellos. Un criterio describe una condición que la funcionalidad acordada tiene que cumplir. No es el lugar para colar funcionalidad nueva que olvidaste pedir. Si “los clientes reciben un correo cuando su factura se aprueba” nunca estuvo en el alcance, eso es un cambio, y pertenece a una conversación sobre alcance, no a una lista de aceptación presentada en la entrega.
El tercero, y el más común, es aceptar “se ve bien” de ti mismo. El founder que ojea una demo, ve el camino feliz funcionar una vez y da el visto bueno es el founder que descubre el fallo silencioso de diez megabytes cuando un cliente real lo golpea. La aceptación es una inspección. Corre cada criterio, incluidos los feos, sobre lo que pasa cuando algo sale mal. Los criterios sobre el fallo suelen ser los que separan un software que puedes poner delante de un cliente que paga de un software que solo luce bien en la demo.
Preguntas frecuentes
¿Cuál es un ejemplo de criterio de aceptación?
Para una funcionalidad como “los clientes pueden subir facturas”, un criterio de aceptación útil es: “Un cliente con sesión iniciada puede subir un PDF, etiquetarlo a un mes y verlo en la lista de ese mes después; un archivo de más de diez megabytes se rechaza con un mensaje visible.” Nombra una acción real de usuario y un resultado que verificas tú mismo, con dos desenlaces claros: funciona o no funciona.
¿Cuáles son ejemplos de criterios de aceptación para un founder no técnico?
Los buenos ejemplos son siempre frases simples sobre una persona haciendo algo y viendo un resultado: un usuario puede restablecer una contraseña olvidada e iniciar sesión con la nueva; un admin puede exportar los pedidos del mes a una hoja de cálculo; un cliente que introduce una tarjeta inválida ve un error y no se le cobra. Evita ejemplos escritos en sintaxis de código. Necesitas criterios que puedas leer y comprobar, no criterios hechos para automatización de pruebas.
¿Cuáles son las tres C de los criterios de aceptación?
En la práctica ágil, las tres C son Card, Conversation y Confirmation (tarjeta, conversación y confirmación): la funcionalidad en una tarjeta, la discusión sobre lo que significa y la confirmación de que funciona. Para un founder que compra un desarrollo, la traducción útil es: escribe la funcionalidad, habla sobre lo que “hecho” significa antes de que empiece el trabajo y confírmalo contra esa definición en la entrega. El paso de la confirmación es el que los founders se saltan, y es el que les cuesta.
¿Quién escribe los criterios de aceptación, el founder o el desarrollador?
Redáctalos tú mismo, con tus propias palabras, porque codifican lo que tu cliente necesita y solo tú lo sabes. Luego entrégalos a tu socio de desarrollo y deja que afine los bordes técnicos y señale cualquier ambigüedad. Los criterios escritos solo por quien construye tienden a describir lo que es fácil de construir; los criterios escritos solo por el founder tienden a perder los casos de borde. La versión acordada, cerrada antes del desarrollo, es la que te protege.
Los criterios de aceptación son el seguro más barato de un desarrollo a medida. Un puñado de frases simples, acordado antes de que alguien escriba código, es lo que se interpone entre tú y la discusión del día de entrega en la que ya pagaste y perdiste tu ventaja. Define el “hecho” mientras todavía cuesta un correo. El estudio que se toma en serio tus criterios es el que vale la pena conservar.