En todos los sectores, la prevención es más rentable que la corrección. En medicina, llevar una vida saludable cuesta menos que tratar una enfermedad grave. En la automoción, invertir en calidad evita costes multimillonarios por retiradas de producto. En desarrollo de software, ocurre lo mismo, arreglar bugs tras el lanzamiento puede ser hasta 100 veces más caro que prevenirlos en fases tempranas.
Yo mismo, he priorizado la velocidad sobre la calidad. Pensaba que lanzar rápido era mejor que entregar bien. Pero a medida que el equipo se ahogaba en errores, el usuarios o cliente malinterpreta funcionalidades, entre otros dolores de cabeza, me di cuenta que sin calidad, no hay progreso sostenible.
Es por ello que en este artículo reflexiono sobre una posible técnica para intentar ayudar en la definición de requisitos y controles la calidad en los proyectos de desarrollo.
El coste de un bug aumenta con cada fase
Estudios de IBM y el Instituto Nacional de Estándares y Tecnología (NIST) demostraron que arreglar un error tras el lanzamiento puede ser hasta 10.000% más caro que solucionarlo durante la fase de definición de requisitos. Este principio se aplica tanto a enfoques en cascada como a metodologías ágiles.
La clave está en la calidad incorporada “Built-in Quality”, un concepto originado en el Toyota Production System (TPS), desarrollado por Taiichi Ohno. Este sistema, que revolucionó la industria japonesa tras la Segunda Guerra Mundial, es la base de metodologías como Lean, Scrum y DevOps.
¿Cómo prevenir errores desde el principio?
En Agile, hay tres técnicas fundamentales para definir correctamente los requisitos y evitar errores:
1. User Story
Una historia de usuario resume qué quiere hacer el usuario, por qué y para qué.
Formato:
Como [tipo de usuario] quiero [acción] para que [beneficio].
Ejemplo:
Como usuario, quiero usar credenciales únicas para acceder a la plataforma, para que mi sesión sea segura.
Las user stories son útiles para todos los roles, pero no son suficientes por sí solas.
Sergio Vergara
2. Criterios de aceptación (Acceptance Criteria)
Aquí está el verdadero poder de prevención. Los criterios de aceptación definen con detalle cómo debe comportarse el sistema para considerar que una historia está completa. Además, se utilizan como base para las pruebas de validación.
El formato más eficaz es el lenguaje Gherkin, usado por Cucumber:
Ejemplo:
Escenario: Inicio de sesión exitoso
Dado que el usuario tiene una cuenta
Cuando introduce su email y contraseña y pulsa "login"
Entonces accede correctamente a la plataforma
Esto permite:
- Validar requisitos funcionales
- Cubrir casos de error y rendimiento (NFRs)
- Reducir malentendidos entre negocio y desarrollo
Ejemplo con NFR (requisitos no funcionales):
Escenario: Manejo de error
Dado que el usuario no tiene cuenta
Cuando introduce sus datos y pulsa "login"
Entonces aparece el mensaje: “No tienes una cuenta”
Sergio Vergara
3. Imágenes visuales
El texto tiene sus límites. Por eso, wireframes, mockups o bocetos ayudan a entender lo que se quiere construir. No hace falta alta fidelidad, lo importante es que el equipo vea lo mismo.
Sergio Vergara
Sergio Vergara
¿Quién debe revisar los requisitos?
La revisión de requisitos no debería ser una tarea aislada ni exclusiva de una sola persona. Para garantizar una comprensión completa y evitar errores en fases posteriores, es fundamental abordarla como una actividad colaborativa que involucre múltiples perspectivas desde el inicio.
Una de las prácticas más efectivas en entornos ágiles es reunir a tres perfiles esenciales:
- Negocio / Product Owner: representa los intereses del cliente o usuario final. Su papel es asegurarse de que cada requisito esté alineado con los objetivos del producto y aporte verdadero valor. Valida que las funcionalidades solicitadas resuelvan necesidades reales del mercado o del negocio.
- Desarrollador: analiza los requisitos desde el punto de vista técnico. Evalúa su viabilidad, identifica posibles obstáculos o dependencias, y contribuye a estimar el esfuerzo necesario. Su participación permite detectar riesgos técnicos antes de que se conviertan en problemas de implementación.
- Tester / QA: aporta una visión enfocada en la calidad y la prevención de errores. Examina los requisitos en busca de ambigüedades, lagunas o escenarios límite que podrían pasar desapercibidos. También valida que los criterios de aceptación sean claros, medibles y comprobables.
Aunque este enfoque parte de tres roles clave, no debe limitarse a ellos. En función de la naturaleza del proyecto, puede ser muy valioso incorporar a otros perfiles como diseñadores UX/UI, expertos en accesibilidad, stakeholders técnicos, responsables legales o de compliance, etc. Cuantas más perspectivas se integren desde el principio, más robustos y completos serán los requisitos, reduciendo así el riesgo de malentendidos o retrabajo.
Conclusión
Incorporar la calidad desde las primeras fases del desarrollo no es solo una buena práctica, sino una estrategia fundamental para el éxito de cualquier proyecto digital. Tal como demuestran estudios de IBM y NIST, corregir errores tras el lanzamiento puede ser hasta 100 veces más costoso que prevenirlos durante la definición de requisitos.
Inspirados en principios como el Toyota Production System (TPS) y su filosofía de “calidad incorporada”, las metodologías ágiles ponen un fuerte énfasis en prevenir defectos, no simplemente detectarlos. Herramientas como las user stories, los criterios de aceptación bien definidos y el uso de imágenes visuales permiten construir una base sólida que favorece la calidad desde el inicio.
Además, la revisión colaborativa garantiza que cada requisito sea evaluado desde múltiples perspectivas, negocio, técnica y calidad, lo que reduce errores, mejora la comunicación entre equipos y permite desarrollar software más eficiente, robusto y alineado con las expectativas del usuario.
La calidad no es algo que se añade al final, se construye desde el principio.