«La página del pedido debe ser rápida, estar disponible y ser segura» deja al equipo con varias decisiones pendientes. Hace falta acordar qué recorrido se está midiendo, las condiciones en las que debe funcionar y las acciones que se permite realizar a cada persona. El Product Owner puede ayudar a convertir esas expectativas en condiciones que el equipo pueda revisar, comprobar y observar en producción.
Este artículo utiliza una página de pedidos hipotética de Mercato para desarrollar ejemplos medibles. Las cifras son propuestas ilustrativas del caso, no estándares del sector ni resultados observados. Elegir objetivos reales requiere evidencias sobre las necesidades del cliente, el comportamiento actual y el coste de cumplirlos.
Relacionar el requisito de calidad con una operación concreta
Un requisito funcional describe un comportamiento, como mostrar el pedido de un cliente. Un requisito no funcional suele describir una cualidad o restricción de ese comportamiento: con qué rapidez aparecen los detalles, con qué fiabilidad funciona la consulta o qué condiciones se aplican a su uso. Algunas cuestiones atraviesan esa frontera. La autorización, por ejemplo, puede describirse como un requisito de seguridad y mediante operaciones concretas permitidas o prohibidas.
La clasificación importa menos que el acuerdo que permite alcanzar. En Mercato, «rápida» se aplica primero a abrir los detalles después de que un cliente identificado seleccione un pedido. Cambiar la dirección de entrega es otra operación, con dependencias distintas. Reunir ambas en una media puede ocultar que un recorrido funciona mientras el otro falla.
Rendimiento: concretar el recorrido, la carga y la medición
El equipo propone que al menos el 95 % de las aperturas del detalle muestre la información esencial acordada en dos segundos dentro de una prueba representativa. Para que la frase resulte útil, hay que definir el inicio y el final de la medición. Medir solo la respuesta del servidor deja fuera la red y el renderizado del navegador; una medida de la experiencia del cliente puede abarcar desde que selecciona el pedido hasta que aparecen su estado, artículos y datos de entrega.
Las condiciones de la prueba también forman parte del requisito. En este ejemplo, el equipo utiliza un dispositivo móvil y un perfil de red acordados, un entorno representativo de producción con pedidos sintéticos y 50 aperturas del detalle por segundo mantenidas durante 15 minutos después del calentamiento. Ingeniería todavía debe valorar si esa carga representa el tráfico esperado de la campaña y cómo se modelan las sesiones, la caché y las dependencias. El ejemplo no constituye una especificación completa de una prueba de carga.
El objetivo debe acompañarse de una condición sobre la proporción de aperturas correctas. Una respuesta rápida de error no debería mejorar el resultado de latencia mientras oculta consultas fallidas. El equipo puede definir como correcta una apertura que muestre bien la información requerida, registrar los fallos por separado y revisar las peticiones lentas además del umbral del percentil 95. Superar una prueba con un perfil concreto no demuestra la misma experiencia en cualquier dispositivo o red.
Disponibilidad: definir qué cuenta como servicio correcto
Para producción, Mercato propone un objetivo de nivel de servicio: al menos el 99,9 % de las consultas elegibles del detalle debe devolver la información correcta del pedido durante una ventana móvil de 30 días. Es un objetivo basado en peticiones, no en el porcentaje de tiempo transcurrido. Requiere acordar la fuente de medición, definir qué consultas son elegibles y detectar las respuestas incorrectas, además de los códigos HTTP que indican éxito.
Una consulta válida de un pedido existente que falla porque una dependencia no está disponible debe contar como fallo de la operación comprometida. Los datos de entrada inválidos y los intentos desde una cuenta sin permisos necesitan sus propias respuestas esperadas. Estas distinciones deben documentarse antes de revisar las cifras, para que la definición no se ajuste después de una caída únicamente con el fin de mejorar el resultado.
Un objetivo de nivel de servicio orienta las decisiones operativas; no se convierte automáticamente en un acuerdo contractual de nivel de servicio. Una prueba breve antes del lanzamiento tampoco demuestra que se cumplirá durante los próximos 30 días. Antes de publicar, el equipo comprueba la instrumentación y el comportamiento ante los fallos relevantes; durante la operación mide el objetivo y acuerda qué hará si no se alcanza. El artículo sobre los nueves de disponibilidad desarrolla el significado de estos objetivos y su contexto de medición.
Permisos: hacer comprobable el acceso que debe impedirse
«Solo el cliente puede ver su pedido» debe abarcar la petición subyacente y la pantalla. Ocultar un botón o enlace no impide que alguien envíe directamente una petición. En Mercato, el equipo puede acordar que un cliente identificado consulte sus propios pedidos, mientras una petición sobre el pedido de otra persona no revela ninguno de sus detalles ni lo modifica.
La comprobación incluye cambiar el identificador del pedido en una petición y verificar la denegación, utilizando cuentas de prueba con distintos propietarios y permisos. El acceso de Soporte necesita una política propia que indique qué roles pueden consultar o modificar un pedido. Son casos observables dentro de un enfoque de seguridad más amplio; superarlos no demuestra que todo el producto sea seguro. La guía de autenticación y autorización explica la distinción que sustenta estas reglas.
Un registro breve que conserve las condiciones de medición
La tabla resume los requisitos propuestos. El elemento del backlog o la especificación enlazada debe conservar los detalles sobre los datos, el entorno, las reglas de elegibilidad y las evidencias. Copiar el objetivo sin esas condiciones elimina buena parte de su significado.
| Aspecto | Condición propuesta | Evidencia |
|---|---|---|
| Rendimiento | Al menos el 95 % de las aperturas muestra los detalles esenciales en dos segundos con el perfil de prueba documentado; los fallos se evalúan por separado. | Tiempos del recorrido y resultados de fallos de la prueba de carga acordada. |
| Disponibilidad | Al menos el 99,9 % de las consultas elegibles del detalle devuelve información correcta en una ventana móvil de 30 días. | Medición en producción con reglas documentadas de éxito y elegibilidad. |
| Autorización | Un cliente no puede leer ni modificar pedidos de otro, tampoco mediante peticiones directas. | Comprobaciones de permisos permitidos y denegados con cuentas de prueba representativas. |
Situar el requisito donde se vaya a utilizar
Una condición de calidad propia de un cambio puede aparecer entre sus criterios de aceptación, enlazada al procedimiento de comprobación acordado. Una medida de calidad que se aplica a cada Incremento puede formar parte de la Definition of Done. Un objetivo del servicio en producción también necesita responsables y medición operativa. Cada lugar cumple una función distinta; anotar una cifra en una tarea no proporciona la monitorización necesaria para evaluarla después.
El Product Owner aporta la necesidad del cliente y las consecuencias de incumplir el objetivo. Ingeniería y QA valoran la viabilidad, el coste, las condiciones de prueba y las evidencias disponibles. Si el objetivo no se puede alcanzar con el alcance actual, el equipo necesita discutir las alternativas de forma explícita: una activación menor, un recorrido más acotado, trabajo técnico adicional u otra fecha de lanzamiento. Los requisitos de seguridad no se pueden tratar simplemente como capacidad disponible para otra cosa.
El artículo sobre preguntas técnicas durante el refinamiento ayuda a detectar estas incógnitas antes de planificar. Los ejemplos de criterios de aceptación abordan la redacción del comportamiento acordado. Para profundizar en las evidencias de calidad, puede consultarse Testing, bugs y calidad para Product Managers; Seguridad para Product Managers desarrolla las decisiones de acceso y riesgo.
Referencias
- Google SRE: indicadores, objetivos de nivel de servicio y medición.
- OWASP: comprobación de permisos en peticiones y recursos.
- La Guía Scrum: Definition of Done y medidas de calidad.