Escribir una especificación que el equipo lea de verdad

Qué entra y qué no

Una especificación que describe cada píxel se convierte en un documento que nadie actualiza a las dos semanas. Una que solo describe una visión genera veinte preguntas al día. El punto intermedio: por cada capacidad, quién la usa, qué pasa en el camino normal, qué pasa cuando algo falla y bajo qué condición decimos que está terminada.

Los criterios de aceptación ahorran la mayoría de las discusiones. “El usuario recibe un aviso en menos de un minuto” es un criterio; “el proceso será rápido” es un deseo.

Describe flujos, no pantallas

Describe el flujo como una secuencia: estado inicial, acción, resultado. Después escribe los caminos de fallo: sin conexión, el usuario cerró a medias, el archivo está dañado, permiso denegado. En proyectos reales, los caminos de fallo son la mitad del trabajo y un cuarto de la especificación.

Las pantallas se rediseñan; los flujos permanecen. Por eso el diseño se enlaza desde la especificación en lugar de incrustarse en ella.

La parte que todos se saltan

Escribe explícitamente qué queda fuera del alcance de esta versión. Una lista de “ahora no” es una herramienta de gestión, no una disculpa: permite decir “cierto, y eso viene después” en lugar de volver a debatirlo en cada reunión.

Añade los supuestos en los que te apoyas. Un supuesto escrito es un riesgo gestionado; uno que se queda en la cabeza es una sorpresa.