El costo de la ambigüedad
"Que el usuario pueda exportar sus datos." ¿En qué formato? ¿Todos los datos o un período? ¿Lo puede hacer cualquier usuario? ¿Qué pasa si son millones de filas? Cada una de esas preguntas tiene una respuesta, y si no se escribe antes, la decide quien programa, sin saberlo, a las once de la noche.
Luego llega la revisión, la respuesta no era la esperada y se rehace. Ese ciclo, repetido decenas de veces, es la mayor parte del tiempo perdido en un proyecto de software.
Qué contiene una especificación útil
No hace falta un documento largo. Hacen falta cinco cosas:
El problema. Para quién, qué le pasa hoy y por qué importa. Un párrafo.
El alcance. Qué va a hacer la aplicación, en frases concretas.
Lo que queda fuera. Es la parte más olvidada y la que más discusiones evita. Escribir "no incluye exportación a PDF" cierra una conversación antes de que empiece.
Los criterios de aceptación. Cómo se sabrá que está terminado, en términos comprobables: "exporta hasta un millón de filas en menos de un minuto en formato CSV".
Los requisitos de calidad. Disponibilidad, seguridad, costo: lo que nadie dice pero todos esperan (lo vimos en la serie de arquitectura).
La especificación como contrato vivo
- Es la compuerta de entrada a la construcción: sin especificación aprobada, no se empieza.
- Se versiona con el código, en el mismo repositorio.
- Se cambia, pero por escrito. Si durante la construcción algo cambia, se actualiza la especificación primero y el código después. Así nunca hay dos verdades.
- Los criterios de aceptación se convierten en pruebas, que son las que deciden la compuerta de aceptación.
Con la especificación aprobada, la aplicación puede nacer. Y conviene que nazca siempre igual.
Cómo lo aplicamos: Ingeniería de Plataforma.