Una presentación de preparación para el lanzamiento debe permitir que la persona con autoridad para aprobarlo responda a tres preguntas: qué se pondría en producción, qué pruebas respaldan ese cambio y qué ocurriría si fallara. Empieza por la decisión solicitada, muestra las condiciones pendientes junto a las pruebas y termina con un registro de quién ha autorizado qué. Una fila de indicadores verdes no basta.
Prepara primero las notas de la versión ya revisadas. Después puedes usar Presenti para convertir ese texto en un borrador de presentación editable, conservando las referencias a las pruebas y las condiciones de aprobación. El ejemplo sigue a un servicio ficticio de reserva de citas durante una reunión de decisión sobre su puesta en producción. Sus registros, horarios y umbrales son ejemplos didácticos, no resultados de un despliegue real.
Identifica la versión y la decisión antes de mostrar el progreso
El equipo quiere publicar la versión 2.4, que cambia la forma de reservar y cancelar citas. Los precios, la migración de cuentas y la aplicación móvil quedan fuera de esta versión. El candidato que se revisa es la compilación 2.4-rc3, con la configuración C17 y una nueva migración de base de datos. Se propone empezar con diez cuentas internas de prueba y decidir por separado si se permite el acceso a clientes.
En el momento de la revisión, las pruebas de reserva han pasado. Los retrasos en las notificaciones siguen bajo investigación. El ensayo de reversión cubría el candidato anterior, no rc3 y su migración. Por tanto, la primera diapositiva debería decir:
Recomendación: mantener en espera el piloto de rc3. Las pruebas respaldan el comportamiento de las reservas, pero no se ha demostrado la recuperación de este candidato. Hay que resolver esa condición y caracterizar el retraso de las notificaciones antes de solicitar la autorización del piloto.
Es un comienzo más útil que «La versión 2.4 está lista al 95 %». Un porcentaje reúne elementos cuyas consecuencias no son equivalentes. Varias tareas de documentación terminadas no compensan la falta de un resultado de recuperación.
Incluye la compilación, la configuración, la hora de revisión y el alcance solicitado en esa primera diapositiva. Si la compilación o la configuración cambian durante la reunión, el grupo debe saber qué pruebas siguen siendo aplicables. No traslades de forma implícita la aprobación de un candidato anterior a uno nuevo.
Explica qué respalda realmente cada resultado
Usa un panel breve de pruebas y deja los registros detallados disponibles por separado. Cada fila debe relacionar una afirmación con su alcance y con lo que falta por comprobar. «Pruebas superadas» es demasiado amplio si solo se han probado cuentas internas o una vía de pago.
| Área | Pruebas en esta revisión ficticia | Consecuencia para la decisión |
|---|---|---|
| Reservas | QA-42 recoge pruebas de creación, cancelación y reservas simultáneas en rc3/C17, en preproducción. | Respalda esos recorridos. No demuestra el comportamiento con cualquier carga de clientes. |
| Notificaciones | MAIL-9 recoge mensajes de confirmación retrasados durante una prueba de reintentos; aún no se conocen la demora máxima ni la causa. | Mantener visible la excepción. No dar por listas las notificaciones ni suponer que el retraso es inocuo. |
| Recuperación | RB-14 corresponde al candidato anterior. No hay un registro de ensayo para rc3 con su migración. | No se cumple la condición de recuperación acordada; la recomendación actual es esperar. |
| Cobertura de soporte | OPS-6 identifica un responsable principal, un suplente, la franja del piloto y la vía de escalado. | Existe cobertura para esa franja, no de forma indefinida ni para un lanzamiento ampliado. |
QA-42 y las demás etiquetas son identificadores de ejemplo. En tu presentación, las referencias equivalentes deben llevar a los resultados reales e indicar el entorno, el candidato y el momento de la prueba. Conserva los datos personales y los secretos operativos en registros con el acceso adecuado, en lugar de copiarlos en una presentación de amplia difusión.
La explicación de Google sobre lanzamientos fiables destaca las comprobaciones concretas, prácticas y adaptadas al servicio. Su lista histórica de lanzamiento incluye el comportamiento ante fallos, la monitorización, la recuperación y el despliegue por etapas. Úsalas como preguntas que adaptar, no como una norma universal de aprobación ni como prueba de que tu servicio las ha superado.
Distingue un impedimento de una excepción aceptada
Antes de la reunión, acordad qué condiciones obligan a detener el lanzamiento y cuáles podrían aceptarse en una puesta en producción expresamente limitada. De lo contrario, el estado «ámbar» se convierte en una negociación sobre colores, no sobre el alcance de la exposición.
En este ejemplo, la regla acordada exige demostrar la recuperación del candidato antes de cualquier despliegue piloto. Por eso, la ausencia del ensayo de rc3 es un impedimento. Quien preside la reunión no puede convertirlo en una excepción aceptada simplemente reduciendo el público de clientes a diez empleados.
El retraso del correo plantea otra cuestión. ¿Podría continuar un piloto acotado con esa limitación? Primero habría que conocer la demora observada, si el estado de las reservas sigue siendo correcto, qué verán los participantes y quién puede detener el piloto. «Tenemos una alternativa» no responde a esas preguntas.
Para cada excepción propuesta, prepara un registro breve: limitación; usuarios afectados; pruebas; medida temporal; responsable; vencimiento o momento de revisión. Una excepción sin un público definido ni un punto final cambia indefinidamente la promesa del lanzamiento.
Mantén separados tres resultados. Go autoriza el alcance indicado bajo las condiciones acordadas. Go restringido autoriza una exposición menor y descrita con precisión. No-go deja el cambio propuesto sin autorización hasta que se revisen las pruebas y la decisión pendientes. Ninguna etiqueta otorga a quien presenta una autoridad que no tenga.
Dibuja el recorrido de despliegue y la vía de recuperación
Una cronología que termina en «desplegar» oculta el trabajo del que depende la aprobación. Representa el recorrido propuesto como una secuencia corta, con una decisión o condición de parada entre etapas:
- Antes de exponer la versión: completar el ensayo de recuperación de rc3 y caracterizar MAIL-9; adjuntar los registros a la nueva revisión.
- Autorización: la persona designada decide si ese candidato concreto puede entrar en el piloto de diez cuentas.
- Observación limitada: los responsables asignados vigilan las reservas, las notificaciones y las señales acordadas durante la franja del piloto.
- Siguiente decisión: mantener el alcance, detener y recuperar, o solicitar una exposición mayor. La primera aprobación no autoriza automáticamente esta última opción.
Supongamos, a modo de ejemplo, que una revisión posterior acuerda detener el piloto ante cualquier reserva duplicada confirmada, una confirmación que tarde más de cinco minutos o la pérdida de la monitorización necesaria para observar ambas condiciones. Son límites hipotéticos propios del servicio, no valores recomendados por defecto. Una ventana de observación de treinta minutos podría formar parte de ese piloto limitado; no demostraría fiabilidad a mayor escala.
Sitúa la autoridad para detener el piloto junto a la condición de parada. En este ejemplo, el responsable de guardia puede pararlo, mientras que la persona con autoridad sobre el lanzamiento decide si puede reanudarse. Vincula la recuperación al procedimiento operativo aprobado; no intentes convertir la presentación en instrucciones ejecutables de despliegue.
Para la migración, aclara qué significa «volver atrás». ¿La aplicación anterior puede leer los registros creados por la nueva? ¿La recuperación exige conciliar las citas creadas durante el piloto? Muestra la respuesta conocida o la prueba que falta. Cambiar la versión de la aplicación no demuestra, por sí solo, que los datos hayan vuelto a un estado utilizable.
Organiza seis diapositivas, no seis informes de situación
Una presentación breve puede seguir la decisión sin repetir el informe semanal de cada equipo:
- «Mantener el piloto de rc3 en espera hasta demostrar la recuperación». Identifica el candidato, el alcance, la recomendación y el rol que aprueba.
- «Las pruebas respaldan las reservas evaluadas; quedan dos condiciones abiertas». Muestra el panel de pruebas y sus límites.
- «El resultado de reversión anterior no cubre esta migración». Explica el impedimento y el resultado concreto necesario.
- «La primera aprobación solo cubriría diez cuentas». Presenta las etapas, la ventana de observación y la autoridad de parada.
- «Hay personal de soporte para la franja propuesta». Identifica roles, suplencias y el relevo al terminar esa franja.
- «Registrar la decisión y las condiciones de una nueva revisión». Salid de la reunión con una resolución concreta.
La primera diapositiva contiene la recomendación; la última registra la decisión real. Pueden ser distintas. Si el grupo cambia el alcance solicitado, registra ese cambio en lugar de retocar después la primera diapositiva y perder el historial de lo que se consideró.
Para preparar un borrador, pega los seis títulos y las pruebas revisadas debajo de cada uno. Una instrucción útil sería: «Conserva rc3/C17 sin cambios. Mantén la recomendación de esperar y la condición de recuperación pendiente. Separa pruebas, etapas futuras propuestas y autorización. No inventes resultados, nombres de personas que aprueban, fechas de despliegue ni mejoras de rendimiento». Revisa la redacción generada antes de diseñar la página final: una buena maquetación no debe convertir una etapa propuesta en una etapa aprobada.
Termina con un registro de decisión completo
Este es el registro de la reunión ficticia. Es suficientemente breve para leerlo antes de que los asistentes se marchen:
Decisión: No-go para el piloto propuesto de rc3/C17 con diez cuentas, registrado en la revisión de las 14:00. No se autoriza el acceso de clientes.
Motivo: Las pruebas de recuperación no cubren la migración del candidato. El retraso de las notificaciones aún no está caracterizado.
Pruebas siguientes: El responsable de ingeniería aporta el resultado de recuperación específico del candidato, incluido el tratamiento de las citas recién creadas. El responsable de notificaciones aporta la investigación de la demora y la limitación propuesta para el piloto.
Responsable de la decisión: La persona designada para autorizar el lanzamiento vuelve a convocar la revisión cuando estén disponibles esos registros. La reunión sugerida a las 16:00 sirve para actualizar el estado, no para autorizar un despliegue a esa hora.
Alcance sin cambios: El lanzamiento a clientes, la aplicación móvil, los precios y la migración de cuentas siguen fuera de esta decisión.
Envía el registro junto con la presentación y las referencias a las pruebas. Si la siguiente reunión llega a otra decisión, añade una entrada nueva para el candidato y las condiciones que se hayan considerado. La presentación cumple su función cuando alguien que no asistió puede distinguir qué se autorizó, qué quedó pendiente y qué debe ocurrir después.
