Planteamiento y contexto
Estás a dos semanas de lanzar una funcionalidad importante. El entrevistador te pide que realices un pre-mortem, conviertas las posibles fallas en tareas de validación y responsables directos, y luego decidas si expandir el despliegue tras el lanzamiento. Esto evalúa si puedes conectar el descubrimiento (discovery), las operaciones de lanzamiento y las decisiones medibles en lugar de limitarte a enumerar riesgos genéricos.
Lo que evalúa el entrevistador
La habilidad fundamental es la traducción de riesgos en decisiones. Una respuesta sólida distingue las suposiciones de la evidencia, asigna un responsable específico a cada riesgo material, define barreras de protección (guardrails) antes de la exposición y establece una ruta de lanzamiento reversible. También demuestra que el valor para el usuario y la seguridad operativa se evalúan de manera conjunta.
Preguntas aclaratorias para hacer primero
Pregunta quiénes son los usuarios objetivo, qué problema resuelve la funcionalidad y qué significa "importante" en términos de negocio. Aclara si el lanzamiento es una beta limitada o un lanzamiento general, qué sistemas o compromisos pueden verse afectados y qué equipos son propietarios de producto, ingeniería, soporte, legal y operaciones. Pregunta qué métricas de referencia y capacidades de reversión (rollback) ya existen.
Estructura para una respuesta de 30 segundos
Di: "Comenzaría con un pre-mortem imaginando que el lanzamiento fracasó, agruparía los modos de falla por valor para el usuario, adopción, confiabilidad y cumplimiento normativo, y los clasificaría por impacto y evidencia. Para cada riesgo de alta severidad asignaría un responsable, una validación falsable, una señal temprana (leading signal), una barrera de protección y una acción de rollback. Lanzaría hacia un segmento representativo con una duración explícita, revisaría las barreras de protección absolutas y las métricas centradas en el usuario, y luego tomaría una decisión documentada de Go/No-Go antes de expandir".
Análisis detallado paso a paso
1. Imaginar el fracaso y declarar suposiciones
Escribe una declaración de falla concreta, como: "Después de siete días, la activación está estancada, las solicitudes de soporte se duplicaron y la latencia p95 supera el objetivo del servicio". Separa las suposiciones sobre el comportamiento del usuario, la calidad de los datos, la capacidad y las políticas de los hechos ya medidos. Esto evita que la sesión de trabajo se convierta en una lluvia de ideas sin estructura.
2. Clasificar riesgos y asignar responsables
Utiliza el impacto, la probabilidad, la reversibilidad y la solidez de la evidencia para clasificar los riesgos. Una falla irreversible y de alto impacto pertenece a la primera ola de validación. Asigna un único responsable directo, una fecha límite y la decisión que puede desbloquear; lista a los colaboradores por separado para que la rendición de cuentas sea inequívoca.
3. Definir señales, métricas y barreras de protección
Para cada suposición, define un objetivo centrado en el usuario, una señal observable y una métrica. HEART es una estructura útil: Happiness (felicidad), Engagement (compromiso), Adoption (adopción), Retention (retención) y Task success (éxito en la tarea). Empareja las métricas objetivo con barreras de protección absolutas como la tasa de error, la latencia, la tasa de quejas o la tasa de bajas/opt-out. Un objetivo es una razón para expandir; el incumplimiento de una barrera de protección es una razón para pausar o revertir.
4. Diseñar un plan de exposición reversible
Utiliza un despliegue canario (canary) o escalonado: elige una población representativa, un porcentaje de exposición, una duración, una ventana de tiempo y un responsable de guardia antes de habilitarlo. Comienza con una fracción pequeña que limite el radio de impacto (blast radius). Define la condición de parada y el comando de rollback por adelantado, y registra quién puede invocarlo sin necesidad de convocar a una gran reunión.
5. Decidir Go/No-Go y aprender
En el punto de revisión, compara los umbrales predefinidos con los datos observados. Go significa que las métricas objetivo alcanzan el estándar esperado y no se ha vulnerado ninguna barrera de protección absoluta. No-Go significa pausar, revertir o mantener la funcionalidad en su exposición actual mientras el responsable prueba una hipótesis específica. Registra la decisión, la evidencia y el siguiente punto de control para que el equipo pueda revisarla sin reescribir la historia.
6. Explicitar el trabajo de seguimiento
Convierte cada riesgo no resuelto en una acción con fecha, un único responsable y una condición de salida medible. Mantén juntos el nivel de exposición, la evidencia y el registro de decisiones para que la próxima revisión pueda comparar elementos equivalentes y evitar reabrir suposiciones ya resueltas.
Ejemplo de respuesta de alta calidad
"Invitaría a los responsables de producto, ingeniería, soporte y cumplimiento normativo a un pre-mortem de 45 minutos. Imaginaríamos que el lanzamiento fracasó después de una semana y redactaríamos fallas específicas. Supongamos que nuestros principales riesgos son un bajo éxito en la tarea, un aumento del 20% en los contactos de soporte y una degradación de la latencia. Asignaría un responsable a cada uno, validaría el éxito en la tarea con cinco sesiones moderadas más un embudo instrumentado, y verificaría la capacidad con una prueba de carga. Antes del lanzamiento registraría una métrica objetivo de activación y barreras de protección absolutas para la latencia p95, la tasa de errores y los contactos de soporte. Desplegaría en modalidad canario al 5% de usuarios representativos durante 24 horas con cobertura de guardia y el rollback listo. Si la activación mejora mientras las barreras de protección se mantienen, expandiría al 25% y revisaría de nuevo. Si se vulnera una barrera de protección, pausaría o revertiría, publicaría la evidencia y permitiría que el responsable pruebe la solución correspondiente antes de la siguiente revisión de Go/No-Go".
Errores comunes y cómo mejorarlos
- Lluvia de ideas sin decisiones: Convierte cada riesgo serio en un responsable, una validación, un umbral y una acción.
- Medir únicamente la conversión: Añade señales de éxito en la tarea y satisfacción centradas en el usuario, además de barreras de confiabilidad y soporte.
- Lanzar para todos desde el principio: Utiliza una exposición escalonada y representativa con una duración definida y un límite al radio de impacto.
- Términos de rollback ambiguos: Especifica el comando, el responsable, el detonante y el tiempo máximo de respuesta antes del lanzamiento.
Preguntas de seguimiento y respuestas
¿Qué pasa si las partes interesadas rechazan un pre-mortem argumentando que retrasa la entrega?
Limita su duración (time-box), concéntrate en las tres suposiciones de mayor impacto y demuestra la decisión que habilita cada validación. Un pre-mortem breve puede eliminar retrabajos sin convertirse en un comité burocrático de aprobación de lanzamientos.
¿Cómo eliges la primera población para el despliegue canario?
Elige un segmento que represente la carga de trabajo y la combinación de usuarios esperadas, limitando a la vez el radio de impacto. Excluye incompatibilidades conocidas, documenta la regla de muestreo y evita seleccionar únicamente a usuarios internos afines, a menos que ese sea el objetivo explícito de la prueba.
¿Qué sucede si las métricas objetivo mejoran pero una barrera de protección empeora ligeramente?
No promedies ni ignores un umbral de seguridad absoluto. Haz una pausa en el límite predefinido, investiga la segmentación y la causalidad, y expande únicamente después de que el responsable demuestre una corrección segura o el umbral se apruebe formalmente de nuevo.
¿Cómo comunicas una decisión de No-Go?
Detalla por escrito el umbral, la evidencia observada, el responsable, la acción inmediata y el siguiente punto de control. Presenta el No-Go como una decisión de aprendizaje controlado y regresa con nueva evidencia en lugar de defender la fecha de lanzamiento original.