Haz un análisis premortem en Jira: detecta los riesgos del lanzamiento antes de que ocurran

Un lanzamiento puede parecer listo en Jira mientras el equipo sigue teniendo preocupaciones que nadie ha escrito. La implementación está casi terminada, las pruebas están en marcha y la fecha de lanzamiento se acerca. Alguien sospecha que las cuentas antiguas se comportan de forma distinta. Otra persona teme que soporte explique mal los nuevos controles.

Un premortem ofrece un punto de partida útil para esas preocupaciones: imagina que el lanzamiento ya ha salido mal y describe qué lo ha causado. El ejercicio facilita hablar de fallos plausibles antes de que el equipo esté ocupado respondiendo a ellos.

En esta guía realizaremos un premortem práctico para un lanzamiento ficticio de un portal de clientes y organizaremos los resultados en Risk & Pre-Mortem Grid de Power Pack. El resultado será un conjunto breve de riesgos con responsables claros, señales de alerta y trabajo de mitigación.

Elige un resultado concreto para el lanzamiento

Nuestro equipo añade preferencias de correo a un portal de clientes. Los clientes podrán activar o desactivar correos opcionales de la cuenta y seguirán recibiendo mensajes esenciales. Maya responde del resultado de producto, Leo implementa el cambio, Priya dirige las pruebas y Sam prepara el soporte.

Eligen como lugar del premortem la incidencia de Jira que describe el resultado compartido del lanzamiento. Los tickets relacionados de implementación y pruebas siguen enlazados mediante su proceso habitual de Jira. Mantener la conversación junto a la incidencia de lanzamiento ofrece un lugar evidente al que volver.

Antes de la sesión, Maya escribe una declaración sencilla de alcance: revisar la experiencia del cliente, el comportamiento de los correos y la preparación de soporte para la primera versión de los controles de preferencias. El equipo considerará el lanzamiento y su primera semana de uso. Ese límite evita convertir la conversación en una revisión de todos los posibles problemas del portal.

Imagina un fallo antes de hablar de soluciones

Empieza con una propuesta concreta: «Ha pasado una semana desde el lanzamiento. Los clientes están confundidos, han aumentado las solicitudes de soporte y hemos tenido que pausar el despliegue. ¿Qué ha ocurrido?». El resultado imaginado debe resultar lo bastante incómodo para provocar reflexión sin implicar que el fracaso sea inevitable.

Da a todos unos minutos de silencio para escribir posibles causas de forma independiente. Esto permite que una preocupación de pruebas o una observación de soporte entre en la conversación antes de que domine la primera explicación convincente. Pide causas que puedan describirse, en lugar de afirmaciones generales como «la calidad era mala».

Después, compartid los escenarios por turnos. En esta primera ronda, recoge la preocupación y aclara su significado. Deja para después las discusiones sobre la mejor solución. Un participante debe poder plantear una posibilidad incómoda sin tener que defender inmediatamente un plan completo de corrección.

• Los clientes existentes ven preferencias que no coinciden con su configuración actual de correo.
• La interfaz sugiere que pueden desactivarse los correos esenciales.
• Las instrucciones de soporte describen controles que cambiaron antes del lanzamiento.
• La actualización de preferencias parece correcta incluso cuando falla el cambio subyacente.

Son escenarios ficticios para nuestro ejemplo. Tu lista debe proceder de quienes entienden el trabajo, las dependencias y la experiencia del cliente. Power Pack registra la conversación; el equipo aporta el criterio sobre lo que podría ocurrir.

Convierte las preocupaciones en riesgos reconocibles

Un riesgo útil describe un posible suceso y su consecuencia. «Migración» es un tema. «Los valores existentes de preferencias se asignan incorrectamente y algunos clientes reciben correos opcionales que esperaban dejar de recibir» es un escenario que se puede investigar.

Combina duplicados sin perder consecuencias distintas. Varias preocupaciones sobre cuentas antiguas pueden compartir una causa. Una etiqueta engañosa y un guardado fallido pueden confundir a los clientes, pero necesitan comprobaciones diferentes y normalmente deben seguir siendo riesgos separados.

Para cada escenario, pregunta qué observaría el equipo con antelación. Una señal de alerta temprana es un indicio observable que merece atención. En nuestro ejemplo, una diferencia entre la configuración existente de una cuenta y los valores migrados propuestos resulta más útil que «los clientes podrían quejarse». Puede comprobarse antes del lanzamiento.

Acuerda qué significan probabilidad e impacto

Power Pack ofrece una matriz de 3×3 o 5×5 y calcula una puntuación de gravedad multiplicando probabilidad por impacto. Utiliza esa puntuación para apoyar la conversación y la ordenación. Es una valoración subjetiva, no una predicción de la frecuencia de un fallo ni un cálculo de pérdidas esperadas.

Para una primera sesión, nuestro equipo elige 3×3 y acuerda significados sencillos para las valoraciones. Una probabilidad de uno significa que actualmente ven pocos indicios; dos significa que el escenario es plausible y necesita investigación; tres significa que hay razones sólidas para esperarlo si no se actúa. Son las definiciones de trabajo del equipo.

Definen el impacto en torno a las consecuencias para clientes y lanzamiento. Uno significa una molestia limitada; dos, una alteración importante que requiere seguimiento; tres, un problema grave para el cliente o un motivo para pausar el lanzamiento. Otro equipo podría necesitar definiciones diferentes para su entorno.

Priya valora la migración incorrecta con probabilidad dos e impacto tres, lo que da una puntuación de seis. El equipo debate los supuestos de esa valoración: la nueva asignación aún no se ha ensayado con cuentas antiguas representativas. Las pruebas que faltan importan más que la aparente precisión del número.

Mantén la misma escala al comparar los riesgos iniciales. Cambiar el tamaño de la matriz reajusta las valoraciones existentes, así que revisa las posiciones resultantes si cambias la resolución. Una nueva posición no debe confundirse con pruebas recién descubiertas sobre el lanzamiento.

Añade los riesgos a Power Pack

Abre Power Pack en la incidencia de Jira elegida y selecciona Risk & Pre-Mortem Grid. Utiliza el mapa de calor para ver la distribución de las valoraciones y el registro de riesgos para revisar las entradas. Puedes añadir un riesgo desde una celda de la matriz si ya conoces su probabilidad e impacto iniciales.

Para cada entrada, registra el título, el escenario de fallo, la señal de alerta temprana y la categoría. Añade las valoraciones acordadas, un plan de mitigación y un responsable. Power Pack también admite puntos de control de mitigación, estado y una referencia opcional a una incidencia de Jira.

El responsable puede ser un usuario de Jira o un registro de persona externa. Elige a alguien que coordine la respuesta y aporte al equipo las pruebas que falten. Nombrar a esa persona en la matriz no crea una tarea de Jira, no asigna una existente ni concede acceso a la incidencia.

Revisa el estado de guardado antes de considerar compartida la matriz actualizada. Los cambios se almacenan en la incidencia y un estado local o de reintento no debe interpretarse como confirmación de que otro compañero ya puede ver la última entrada.

Da a cada riesgo importante una respuesta práctica

«Probar exhaustivamente» es difícil de seguir. Para el riesgo de migración, Priya propone un ensayo con estados representativos de cuentas existentes, seguido de una comparación de las preferencias resultantes y el comportamiento esperado de los correos. Leo investigará cualquier diferencia. Priya sigue siendo responsable del riesgo y lleva el resultado a la revisión del lanzamiento.

Divide la respuesta en puntos de control que hagan visible el avance. El equipo podría seleccionar casos representativos, ejecutar el ensayo, revisar diferencias y registrar la incertidumbre restante. Los puntos de control ayudan a organizar la respuesta, mientras las pruebas reales permanecen en el trabajo pertinente de pruebas o entrega.

Si la mitigación necesita su propio ticket de Jira, créalo y asígnalo mediante el flujo habitual de Jira y después añade su clave como referencia en el riesgo. Una referencia facilita seguir la relación; no crea automáticamente el trabajo ni gestiona su entrega.

Revisa el estado cuando cambien las pruebas

Power Pack proporciona los estados Identified, In Progress, Mitigated y Accepted. Utiliza Identified cuando se haya registrado el escenario e In Progress cuando alguien trabaje activamente en la respuesta. Acuerda qué pruebas espera el equipo antes de describir un riesgo como Mitigated.

Accepted puede describir una decisión consciente de seguir adelante con una exposición restante. Por ejemplo, Maya podría aceptar una pequeña carencia en la documentación de soporte después de que Sam confirme que existe una respuesta temporal. Registra el razonamiento y revísalo si cambian los supuestos. La aceptación debe ser una decisión comprendida, no una forma de ordenar la matriz.

En la revisión del lanzamiento, pregunta a los responsables por las señales de alerta, los resultados de mitigación y la incertidumbre restante. Revisa por separado cualquier cambio importante de alcance, nueva dependencia o resultado inesperado de pruebas. Actualiza las valoraciones cuando las pruebas lo justifiquen y explica por qué cambió la evaluación.

Puedes exportar la matriz como Markdown o CSV para una conversación de planificación. Identifica la incidencia de Jira como el lugar donde consultar el registro actual. Una exportación compartida es una instantánea y puede dejar de reflejar la última evaluación del equipo.

Utiliza la sesión para cambiar lo que ocurre después

Una matriz completa es útil cuando influye en la preparación. Para nuestro equipo del portal, el premortem conduce a un ensayo de migración, una redacción más clara y una comprobación de que la guía de soporte coincide con la versión candidata. Cada acción responde a un escenario de fallo concreto planteado por quienes realizan el trabajo.

Empieza con un lanzamiento, una breve conversación facilitada y un conjunto pequeño de riesgos significativos. Utiliza Power Pack para mantener visibles los escenarios, responsables y respuestas junto a la incidencia de Jira. Después, lleva el registro a la siguiente conversación sobre el lanzamiento, donde el equipo podrá evaluar qué ha cambiado realmente.