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

¿Qué es proceso de decisión go/no-go: árbol de decisión de lanzamiento?

Una decisión go/no-go no es una fase de un flujo de trabajo: es un juicio. Cuando una versión llega a la puerta de revisión, el trabajo ya está hecho; lo que queda es contrastar la evidencia con los criterios acordados de antemano y decir, en voz alta y por escrito, cuál de los resultados con nombre se aplica. Casi todos los equipos tienen las preguntas en alguna parte (en una checklist, en un runbook, en una convocatoria de reunión recurrente), pero rara vez están escritas como un árbol, así que nadie ve qué respuesta lleva a dónde, qué pregunta es una parada en firme y cuál solo añade una condición, ni quién tiene realmente derecho a responder cada una.

Esta página es deliberadamente un árbol de decisión y no un mapa de procesos. Un mapa de procesos responde a «qué pasa después y quién lo hace»: tareas en secuencia, traspasos entre equipos, un camino principal con excepciones colgando de él. Un árbol de decisión responde a «qué opción elegimos y quién decide»: una espina de preguntas, cada una respondible con evidencia, con ramas etiquetadas por la respuesta en lugar de por la siguiente tarea, que terminan en resultados distintos y con nombre. Si buscas el flujo completo alrededor de esta puerta (congelación del alcance, construcción y pruebas, staging y UAT, despliegue, pruebas de humo y monitorización), usa el diagrama de flujo del proceso de release de software en /es/templates/proceso-de-release-de-software. Esta página es la vista ampliada de la única decisión que vive dentro de él.

El árbol de abajo recorre doce preguntas repartidas en cuatro etapas de evaluación, y las calles nombran a quien responde en lugar de mapear departamentos: Responsable de release, Ingeniería y QA, Operaciones y soporte, y Patrocinador ejecutivo. Termina en seis resultados distintos (go, go con condiciones asignadas, un go limitado a un grupo piloto, no-go por criterios de aceptación no cumplidos, no-go con fecha reprogramada y cancelación), porque una revisión que solo puede decir sí o no obliga a meter cualquier preparación parcial en una de dos respuestas equivocadas. Las dos salidas de no-go están separadas a propósito: no superar la primera puerta por criterios incumplidos es un hallazgo distinto de aprobar la calidad y perder la ventana de cambio.

Qué cubre este diagrama de flujo

En esta plantilla

• Cuatro calles de derechos de decisión en lugar de un mapa de departamentos (Responsable de release, Ingeniería y QA, Operaciones y soporte y Patrocinador ejecutivo), dispuestas sobre cuatro etapas: Revisión de evidencias, Puerta de calidad, Puerta operativa, y Decisión y resultado.
• La rama de criterios de aceptación: «¿Se cumplen todos los criterios de aceptación?» responde Cumplidos o Con brechas, y Con brechas lleva a «¿Las brechas admiten exención?», donde Con exención registra la exención y su responsable antes de volver a la puerta de calidad, y Bloqueante termina la revisión en su propia salida, «No-go: criterios de aceptación no cumplidos».
• La rama de umbrales de defectos: «¿Defectos dentro de los umbrales de severidad?» responde Dentro o Por encima, y Por encima pasa a «¿Corrección o exención acordada?», de modo que un lanzamiento por encima del umbral solo avanza con un acuerdo registrado, no con optimismo.
• Dos preguntas de preparación que sobreviven a una respuesta parcial: «¿Dependencias y proveedores listos?» cae en «¿Podemos lanzar sin ellos?», y «¿Rollback probado con éxito?» cae en «¿El cambio es reversible?», donde un No es la única ruta hacia la cancelación en lugar de hacia una fecha reprogramada.
• Soporte y calendario como puertas duras e independientes: «¿Soporte formado y con personal?» y «¿Ventana de cambio y calendario libres?» responden directamente a no-go con No listo o Conflicto, y mantienen la preparación operativa fuera de la conversación de ingeniería.
• Un par de decisiones de cierre que nombra el resultado: «¿Aprobación ejecutiva concedida?» (Concedida o Denegada) y después «¿Qué alcance se autoriza?», cuyas ramas Completo, Condicional y Solo piloto llevan a tres puntos finales separados, junto a los terminadores de no-go y cancelación.

Cuándo usar esta plantilla

• Celebráis una revisión de preparación o de lanzamiento y los criterios viven en la cabeza de la gente, así que el resultado depende de quién esté en la sala y de cómo haya ido la semana.
• Vuestras revisiones solo producen «go» o «retraso», y la preparación parcial (un proveedor que llega tarde, un turno de soporte demasiado justo) no tiene dónde aterrizar salvo en una parada en seco o en una apuesta no registrada.
• Necesitáis cerrar los derechos de decisión antes de que el próximo release fuerce la discusión: quién puede eximir un criterio de aceptación, quién puede aceptar un defecto por encima del umbral y de quién es la firma obligatoria.
• Estáis documentando cómo se autorizan, prueban y aprueban los cambios para una auditoría o un cuestionario de seguridad de un cliente, y necesitáis mostrar los criterios además de la aprobación.
• Estáis haciendo la revisión posterior a un incidente de un release que no debería haber salido, y queréis que la conversación gire sobre qué pregunta se saltó y no sobre una reconstrucción de memoria.

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.