Proceso de decisión go/no-go: árbol de decisión de lanzamiento

Cómo funciona

1. Renombra las calles según vuestros derechos de decisión reales

   Sustituye Responsable de release, Ingeniería y QA, Operaciones y soporte y Patrocinador ejecutivo por los roles que de verdad tienen la respuesta en tu organización. Mantén las calles en clave de quién responde, no de quién participa: si tres equipos aportan evidencia a una pregunta pero una sola persona la decide, esa pregunta va en la calle de quien decide. Fusiona cualquier calle a la que no puedas ponerle una persona o un rol concreto.

2. Escribe los umbrales antes de necesitarlos

   El árbol vale lo que valen sus pruebas. En «¿Defectos dentro de los umbrales de severidad?», anota el límite por severidad para el alcance liberado, quién puede saltárselo y si el recuento incluye incidencias conocidas arrastradas de versiones anteriores. Haz lo mismo con «¿Se cumplen todos los criterios de aceptación?» marcando cada criterio como obligatorio o deseable en la congelación del alcance, para que la puerta no se renegocie el mismo día.

3. Define qué significa un rollback probado

   «¿Rollback probado con éxito?» debería significar ensayado contra un entorno equivalente a producción, cronometrado, con una persona designada capaz de ejecutarlo y un disparador escrito para activarlo. Deja explícita la cuestión de los datos, porque un cambio de esquema o una migración suele ser lo que convierte «¿El cambio es reversible?» en un No, y esa rama es la única ruta hacia la cancelación.

4. Haz reales los resultados condicional y piloto

   Un go condicional solo se diferencia de un go normal si cada condición lleva un responsable con nombre, una fecha límite y una consecuencia declarada si se incumple. Un go piloto necesita su cohorte definida, el porcentaje de exposición o la lista de clientes por escrito, y el criterio para ampliarlo. Añade ambos al campo de comentarios de «¿Qué alcance se autoriza?» para que la revisión no pueda cerrarse con un gesto de asentimiento.

5. Separa el no-go de la cancelación

   No-go significa que el mismo release sale más tarde, así que necesita una fecha reprogramada y un bloqueante con nombre antes de que termine la reunión. Cancelar significa que el release se retira y el alcance vuelve a rehacerse o a replantearse. Mantenerlos como puntos finales distintos evita que una cancelación real se registre como un retraso de dos semanas que se repite en silencio.

6. Publícalo y revísalo después de cada puerta

   Comparte el árbol donde ocurre la revisión de verdad, junto al dosier de evidencias, y recoge la firma de las personas nombradas en las calles. Después de cada release, comprueba si alguna pregunta se respondió sin evidencia y si faltaba un resultado que habrías necesitado. Conserva las versiones anteriores para poder mostrar cuándo cambiaron los criterios y por qué.

Preguntas frecuentes

¿Qué diferencia hay entre un árbol de decisión go/no-go y un mapa del proceso de release?

Un mapa del proceso de release responde a «qué pasa después y quién lo hace». Muestra tareas en secuencia a través de calles —congelación del alcance, construcción, pruebas, despliegue, monitorización— y trata la decisión go/no-go como un único nodo. Un árbol de decisión responde a «qué opción elegimos y quién decide». Su espina es una cadena de preguntas y no de tareas, sus ramas se etiquetan con respuestas como Cumplidos, Por encima, Con exención o Denegada en lugar de con la siguiente actividad, y termina en varios resultados distintos en vez de embudar todo hacia un único camino feliz. Usa los dos: el mapa de procesos para el flujo de extremo a extremo, en /es/templates/proceso-de-release-de-software, y este árbol para la puerta que hay dentro.

¿Qué preguntas deben formar parte de una decisión go/no-go?

Con siete se cubre la mayoría de lanzamientos. ¿Se cumplen todos los criterios de aceptación obligatorios? ¿Los defectos abiertos están dentro de los umbrales de severidad acordados? ¿Están listos las dependencias y los terceros? ¿Se ha probado el rollback, y no solo redactado? ¿Está soporte y operaciones formado y con personal suficiente para el volumen previsto? ¿Está libre la ventana de cambio en el calendario de negocio además del técnico? ¿Está la aprobación ejecutiva concedida? Cada una debería poder responderse con evidencia recogida antes de la reunión, y por eso el árbol arranca con un dosier de evidencias de preparación y no con la primera pregunta.

¿Quién toma la decisión go/no-go?

Debería presidirla una persona con nombre, normalmente el responsable de release o quien sea dueño de producción, pero la disciplina útil consiste en asignar cada pregunta en lugar de la decisión entera. Ingeniería y QA responden a las preguntas de aceptación y defectos, operaciones y soporte responden a rollback y dotación de personal, el responsable de release responde a dependencias y ventana de cambio, y el patrocinador ejecutivo responde a la aprobación. Planteado así, el trabajo de quien preside es recorrer el árbol y registrar el resultado, no arbitrar personalmente cada pregunta. Registrar quién respondió qué también importa como evidencia: marcos de control como SOC 2 esperan que los cambios se autoricen, se prueben, se aprueben y se documenten, y un árbol de decisión con derechos de decisión nombrados es una forma directa de demostrarlo.

¿Cuándo debe terminar un go/no-go en un go condicional en lugar de en un no-go?

Cuando el punto pendiente no pone en riesgo el lanzamiento y alguien se va a hacer cargo de él después. Un go condicional solo es un resultado real si cada condición tiene un responsable con nombre, una fecha límite y una consecuencia declarada por incumplirla; si no, es un go normal con papeleo extra. Reserva el no-go para todo lo que dejaría a los usuarios expuestos o sin soporte. En este árbol, las brechas de aceptación bloqueantes, un defecto por encima del umbral sin acuerdo, una dependencia dura sin la que no se puede lanzar, un soporte no preparado y un conflicto de ventana de cambio llevan todos a no-go con fecha reprogramada.

¿Qué diferencia hay entre no-go y cancelación?

No-go significa que el release se aplaza: el mismo alcance sale en una fecha reprogramada en cuanto se despeje el bloqueante. Cancelar significa que se retira y el alcance vuelve para rehacerse o replantearse, sin fecha asociada. Distinguirlos importa porque un release que no se puede revertir en absoluto, o uno en el que el patrocinador ejecutivo deniega la aprobación por motivos de negocio, no está esperando a una corrección: registrarlo como un retraso lleva a repetir la misma revisión quince días después con la misma evidencia.

¿Cómo limito un lanzamiento a un grupo piloto o canary?

Trátalo como un resultado de la decisión, no como un apaño alcanzado en la sala. En este árbol la pregunta final, «¿Qué alcance se autoriza?», se ramifica en Completo, Condicional y Solo piloto, de modo que un lanzamiento limitado se elige deliberadamente después de haber respondido a todas las preguntas de preparación y no como forma de esquivar un no-go. Antes de la revisión, define qué significa un piloto en tu producto: qué cohorte o nivel de exposición, cuánto dura, qué se monitoriza y qué criterio autoriza ampliarlo.