«El ambiente de pruebas lleva caído desde el martes.»
«Nadie sabe regenerar los datos.»
«Se enfermó el único que entiende ese módulo.»
Los tres son riesgos, y de los que se llevan un sprint por delante. Pero como se dicen en el daily y no en el refinamiento, nadie los dimensiona, nadie los escala y nadie decide nada sobre ellos. Se comentan.
Esta es la parada 02 de la serie de gestión de riesgos. En la parada 01 vimos cómo se contesta la pregunta en la reunión. Hoy vamos a la disciplina: cuántas respuestas tiene un riesgo, qué hace en cada ceremonia —que no es solo el refinamiento—, cuál es el número que sí le sirve a quien firma y de quién es el riesgo. Después llegan la matriz, para cuando son doce y no uno, y la IA.
Primero, dos palabras que casi siempre se mezclan
En ISTQB el riesgo se parte en dos.
Riesgo de producto. Que el software haga algo que no debe, o no haga algo que debe. El pago que se duplica, la sesión que no expira, la pantalla que no carga en un teléfono de gama baja. Es el que se ataca probando.
Riesgo de proyecto. Lo que amenaza que el equipo pueda entregar. El ambiente de pruebas que lleva tres semanas caído, los datos de prueba que nadie sabe regenerar, el proveedor que no entregó su parte, la persona que entiende ese módulo y se va de vacaciones el jueves.
Como QA cargas los de producto. Cuando lideras, cargas los dos — y los de proyecto son los que nadie te va a preguntar.
Es una distinción práctica, no académica. En un refinamiento, decir «esto es riesgoso» sin decir de cuál de los dos hablas hace que la mitad de la sala entienda otra cosa. Y los riesgos de proyecto casi nunca aparecen en las matrices, aunque son los que más releases atrasan.
Qué hace el riesgo en cada ceremonia
Escribiendo esta serie conté cuántas veces había escrito «refinamiento» en mis propios artículos. Seis. «Daily», «planning», «review» y «retro», ninguna.
No era una decisión: era usar «refinamiento» como sinónimo de «temprano». Y encoge el trabajo de QA a una sola reunión, cuando el riesgo pasa por todas y en cada una hace algo distinto.
Antes de que exista la historia. El primer documento, la idea suelta, el mockup que alguien mandó por chat. Ahí nace el riesgo de producto y ahí sale más barato, porque todavía no hay ni historia que corregir. Si esperas a que haya una historia escrita para opinar, llegaste tarde a la parte gratis.
En el refinamiento se nombra y se dimensiona. Con el equipo delante, que es cuando se puede discutir la probabilidad con quien conoce el código.
En el planning se ordena. Qué se prueba primero, cuánto, y qué no se prueba — decidido a propósito, no por lo que dio tiempo.
En el daily aparecen los de proyecto. El ambiente caído desde el martes, el dato de prueba que nadie sabe regenerar, la persona que se enfermó. Casi nunca se reportan como riesgo, se reportan como comentario, y son los que más releases atrasan.
En la review los ve el negocio. Con el producto funcionando delante aparecen riesgos que no se ven leyendo: el flujo que técnicamente cumple y que nadie va a usar así.
En la retro se calibra el criterio. Esta es la que menos se usa y la que más te hace mejorar. Miras los riesgos que aceptaste el sprint pasado: si explotó uno, tu criterio estaba flojo en algún eje. Y si no explotó ninguno, en varios sprints seguidos, probablemente estás sobreestimando y frenando cosas que podían salir.
Si tu análisis de riesgo es un archivo que nadie abrió desde el sprint 3, no tienes gestión de riesgos. Tienes un documento.
Probar produce información. No seguridad.
Hay algo que atraviesa las seis ceremonias y conviene tenerlo claro antes de seguir, porque cambia lo que pides en cada una.
Cuando corres una prueba pasan dos cosas posibles. Encuentra algo, y entonces sabes que había un problema. O no encuentra nada, y entonces sabes un poco más sobre dónde no lo hay. En ninguno de los dos casos el producto cambió.
Lo que baja el riesgo es lo que hacen después: el arreglo, el flag que apaga la función, la alerta que montaron, la decisión de no sacarlo todavía.
Las dos dicen que probaste. Solo la segunda dice qué cambió en el producto por haberlo hecho: dos arreglos y un flag. Eso es lo que bajó el riesgo, no los dos días.
Por eso «necesito más tiempo para probar» funciona tan mal. Del otro lado de la mesa se escucha así: el mismo producto, pero el jueves en vez del martes. Estás pidiendo dos días para saber más, y quien decide no está comprando saber más. Está comprando poder decidir.
Lo que sí funciona es decir de antemano qué vas a hacer con lo que encuentres:
«Con dos días te digo si el flujo de renovación aguanta. Si aguanta, salimos sin tocar nada. Si no, lo sacamos de este release o sale con un flag para apagarlo.»
Eso ya no es pedir tiempo. Son tres finales posibles sobre la mesa, con la decisión todavía en manos de quien tiene que tomarla.
Las cuatro respuestas a un riesgo
Un riesgo tiene cuatro salidas posibles.
A la mayoría de los equipos se les ocurre una sola, y por eso todo termina siendo una discusión sobre el calendario.
Evitar — quitar el escenario
El riesgo desaparece porque desaparece la situación que lo produce. No construyes esa parte, o la sacas de este release, o cambias el diseño para que el caso no exista.
Sacar el pago con tarjeta guardada de la entrega del jueves elimina el riesgo de cobro duplicado. No lo reduce: lo elimina, porque esta semana no hay cobro con tarjeta guardada.
Es la respuesta más barata y la que menos se propone, porque suena a rendirse. No lo es. Un alcance más chico que sale y funciona vale más que uno completo que hay que revertir.
Mitigar — bajar la probabilidad o el daño
Es la familia grande, y tiene dos ramas que conviene no confundir.
Bajar la probabilidad de que llegue vivo. Acá entra el testing, pero indirectamente: la prueba revela, alguien arregla, y ese arreglo es el que baja la probabilidad. También entran la revisión de código, los criterios de aceptación bien escritos y los controles automáticos en el pipeline.
Bajar el daño si igual pasa. Un feature flag para apagar la función sin desplegar. Un rollback ensayado —ensayado, no documentado—. Un límite de monto. Una alerta que avise en dos minutos en vez de en tres semanas.
La segunda rama es la que casi nunca propone QA, y muchas veces cuesta menos que la primera.
Transferir — que la consecuencia sea de otro
Transferir significa que, si el riesgo se materializa, la consecuencia la paga otro.
El caso más claro en software son los pagos. Si guardas los números de tarjeta en tu base de datos, un robo de datos es tu problema: tuyo el incidente, tuya la multa, tuyo el correo a los clientes. Si nunca tocas el número —lo captura la pasarela y tú solo recibes un token— ese riesgo dejó de ser tuyo. No lo redujiste: se lo pasaste a alguien que se dedica a eso y que responde por ello.
Funciona igual con un proveedor de verificación de identidad que certifica la validación.
O con un SLA —Service Level Agreement, acuerdo de nivel de servicio—, que es la cláusula del contrato donde el proveedor se compromete a un número medible: 99,9% de disponibilidad, respuesta en menos de 300 ms, incidencias críticas resueltas en 4 horas. Si no lo cumple, hay consecuencia: descuentos, penalización o que puedas irte sin pagar la salida.
Un apunte que casi nadie aprovecha: ese número del SLA es verificable. Si tu producto depende de un proveedor con un compromiso de disponibilidad, medir si lo está cumpliendo es trabajo de QA, y casi ningún equipo lo hace.
Casi nunca es una decisión tuya, y por eso casi nunca se nombra. Pero en una discusión de riesgo pesa más decir «esto lo cubre el proveedor si se cae» que pedir dos días de pruebas.
No la confundas con un canary release: sacar primero al 1% de los usuarios no le pasa el riesgo a nadie. Reduce el daño, así que es mitigación. La diferencia aparece el día que alguien pregunta quién responde.
Aceptar — vivir con él, a propósito
Alguien con autoridad decide que el riesgo es tolerable y se sale igual.
Aceptar no es lo mismo que ignorar. Un riesgo aceptado tiene tres cosas: nombre, dueño y fecha en la que se vuelve a mirar. Un riesgo ignorado no tiene ninguna, y la diferencia se nota el día que explota, cuando la pregunta pasa a ser quién sabía.
Es una respuesta legítima y madura. Los equipos que nunca aceptan riesgos no es que sean más cuidadosos: es que no los están nombrando.
Probar no es ninguna de las cuatro. Vive dentro de mitigar, y solo en una de sus dos ramas: revela para que alguien arregle. El arreglo es el que baja el número.
Lo que sí hace probar es dejarte elegir entre las cuatro con información en vez de a ciegas.
Cómo se ve esto en el próximo riesgo que reportes
Casi todos reportamos un riesgo así: una sola frase que termina en un pedido.
Pártelo en dos bloques. Arriba el riesgo, con las tres frases de la parada 01 —qué pasa, a quién le duele, cómo nos enteraríamos—. Abajo, una línea nueva que diga Opciones, con dos o tres de las cuatro salidas y lo que cuesta cada una.
Escrito, se ve así:
El mismo riesgo, reportado con opciones
Riesgo. Si la tarjeta está vencida, la renovación falla sin avisar. El usuario deja de pagar creyendo que sigue activo, y no lo vemos hasta el cierre del mes.
Opciones.
- Probar y arreglar. Dos días, sale el jueves.
- Sacar la renovación automática de este release. Cero días, sale el martes sin esa función.
- Salir el martes con una alerta si las renovaciones caen más de un 10%. Medio día, y nos enteramos en horas en vez de en un mes.
Ninguna de las tres es «probar más». La primera es mitigar, la segunda evitar, y la tercera baja el daño en vez de la probabilidad — esa tercera casi nunca se propone, aunque suele ser la más barata.
Y lo que cambia no es el tono. Quien decide pasa a tener entre qué elegir, tu nombre deja de estar pegado a «pedir tiempo», y si eligen la opción rápida, la eligieron sabiendo qué aceptaban.
Riesgo residual: el número que sí le sirve a quien firma
Terminas de probar. ¿Qué reportas?
Casi todos reportamos lo mismo: casos ejecutados, porcentaje de éxito, cobertura. Y ninguno de esos números contesta la pregunta que tiene en la cabeza quien va a firmar la salida.
Esa pregunta es: ¿qué puede salir mal que todavía no sepamos?
Eso es el riesgo residual — lo que queda después de todo lo que se hizo. No se calcula, se declara. Y se declara en frases, no en porcentajes:
La primera suena mejor y no dice nada. Con la segunda se puede decidir.
Y tiene un efecto lateral que no esperaba la primera vez que lo hice: cuando reportas riesgo residual, la conversación deja de ser una evaluación de tu trabajo. Pasa a ser una decisión del equipo.
De quién es el riesgo
El riesgo no es tuyo.
Tu trabajo es identificarlo, dimensionarlo y ponerlo sobre la mesa con sus opciones y sus costos. Quien decide asumirlo es quien puede pagar la consecuencia: producto, negocio, quien firma la salida.
El límite corre para los dos lados:
- Si hiciste visible el riesgo con evidencia y opciones, y el equipo decidió salir igual, hiciste tu trabajo. Que después explote no lo cambia.
- Si el riesgo nunca se nombró, o se nombró en un mensaje que nadie leyó, ahí sí faltó algo tuyo.
La pregunta después de un incidente no es quién lo dejó pasar. Es si alguien lo sabía y no encontró la forma de que se entendiera.
Muchos QAs cargamos culpa de decisiones que no tomamos. Y la culpa, además de ser injusta, es mala consejera: lleva a pedir más tiempo en vez de a mostrar mejor.
La próxima parada
Todo esto vale para un riesgo. En una sesión real salen doce, y ahí ya no alcanza con el criterio: hace falta un lugar donde ponerlos y una forma de ordenarlos.
En la parada 03 armamos esa matriz. La que cabe en el tiempo que dura una reunión —la que sea— y no la plantilla de cuarenta celdas que se completa una vez y nadie vuelve a abrir.