Módulo 1: From Experiment To Launch

El lanzamiento como decisión de riesgo, no como interruptor

Siguiente →

Descripción

La lección 2 dejó claro que "ganó el experimento" no equivale a "está listo para el 100%". Esta lección contesta la pregunta que queda abierta: si lanzar no es un interruptor que se prende porque el experimento dio bien, ¿qué es? La respuesta que vas a construir hoy es la columna vertebral de toda la guía: lanzar es una decisión de riesgo, y como toda decisión de riesgo, se juzga con dos preguntas — si sale mal, qué tan grave es, y qué tan fácil es volver atrás.

Conexión con el módulo. Esta lección toma el "por qué" de la lección 2 —la brecha de exposición— y le da estructura: un marco de dos ejes que vas a usar el resto de la guía para decidir cómo lanzar cualquier cosa, no solo recommendations. La lección 4 va a poner número exacto al primer eje (qué tan grave, medido en usuarios afectados); las lecciones 5 y 6 van a mostrar qué herramientas reducen el segundo eje (qué tan fácil volver atrás). Hoy instalas el marco completo, antes de que el resto del módulo lo desarrolle pieza por pieza.

Una analogía: la puerta de una sola vía y la puerta de dos vías

Jeff Bezos, en una carta a los accionistas de Amazon, describió dos tipos de decisiones. Algunas son puertas de una sola vía: una vez que cruzas, es difícil o imposible volver a como estaba antes — piensa en firmar un contrato de diez años, o en eliminar una base de datos de producción sin respaldo—. Esas decisiones merecen deliberación lenta, con mucha gente consultada, porque el costo de equivocarse es alto y permanente. Otras son puertas de dos vías: si cruzas y no te gusta lo que ves, simplemente regresas — piensa en probar un nuevo horario de reunión por dos semanas—. Esas decisiones no necesitan el mismo proceso pesado; de hecho, tratarlas como si fueran de una sola vía solo hace que la organización se vuelva lenta y evite experimentar.

Un lanzamiento de producto casi nunca es una puerta pura de un solo tipo — y ese es exactamente el punto—. recommendations no es una puerta de una sola vía completa (con las herramientas correctas, se puede apagar), pero tampoco es una puerta de dos vías sin fricción: mientras está encendida, cada segundo que pasa, gente real está teniendo una experiencia más lenta de la que debería. La pregunta que vas a aprender a hacerte no es "¿es reversible o no?" en blanco y negro, sino "qué tan reversible es, y qué tan grave es mientras no la reviertes" — las dos coordenadas que ubican cualquier lanzamiento en un mapa de riesgo.

Ejemplo trabajado: launchRiskProfile() sobre tres lanzamientos de Mercado

Vamos a construir el clasificador más simple posible con las dos coordenadas de la analogía: qué tan grave es si sale mal (severityIfWrong) y qué tan fácil es volver atrás (reversible). Lo corremos sobre tres lanzamientos reales o hipotéticos de Mercado, incluyendo el que esta guía acompaña:

// launchRiskProfile: clasifica un lanzamiento por severidad si algo sale mal x
// si es facil o dificil volver atras -- el mismo criterio que separa una
// decision "tipo 2" (puerta de dos vias, reversible) de una "tipo 1" (puerta de
// una sola via, dificil de deshacer).
function launchRiskProfile({ name, severityIfWrong, reversible }) {
  let strategy;
  if (reversible && severityIfWrong === 'low') strategy = 'ship directo, sin ceremonia';
  else if (reversible && severityIfWrong !== 'low') strategy = 'exponer gradualmente, con reversa lista';
  else strategy = 'maxima cautela: revision manual antes de exponer a nadie';
  return { name, severityIfWrong, reversible, strategy };
}

const launches = [
  { name: 'corregir un typo en la descripcion de un producto', severityIfWrong: 'low', reversible: true },
  { name: 'recommendations (guardrail de latencia ya roto)', severityIfWrong: 'high', reversible: true },
  { name: 'migrar el esquema de ordenes eliminando una columna vieja', severityIfWrong: 'high', reversible: false },
];

console.log('=== launchRiskProfile sobre tres lanzamientos de Mercado ===\n');
launches.forEach((l) => {
  const r = launchRiskProfile(l);
  console.log(r.name);
  console.log('  severidad=' + r.severityIfWrong + '  reversible=' + r.reversible + '  -> ' + r.strategy + '\n');
});

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== launchRiskProfile sobre tres lanzamientos de Mercado ===

corregir un typo en la descripcion de un producto
  severidad=low  reversible=true  -> ship directo, sin ceremonia

recommendations (guardrail de latencia ya roto)
  severidad=high  reversible=true  -> exponer gradualmente, con reversa lista

migrar el esquema de ordenes eliminando una columna vieja
  severidad=high  reversible=false  -> maxima cautela: revision manual antes de exponer a nadie

Fíjate en dónde cae recommendations: no en el extremo fácil (el typo, que se lanza sin ceremonia porque aunque algo salga mal, es trivial y reversible), ni en el extremo más cauteloso (la migración irreversible, que exige revisión manual antes de tocar producción). Cae en la zona intermedia — grave si sale mal, pero reversible con las herramientas correctas — y esa zona intermedia es, precisamente, donde vive casi todo lanzamiento de producto real. No es "lanza sin cuidado" ni "no lances nunca": es "expón gradualmente, y mantén la reversa lista mientras lo haces". Esa frase, tomada en serio, es el argumento completo de los módulos 2 a 5 de esta guía.

Por qué "reversible" no es lo mismo que "sin costo"

Vale la pena una aclaración antes de seguir, porque es un malentendido común: que recommendations sea "reversible" no significa que lanzarla mal sea gratis. Cada minuto que 250,000 usuarios están expuestos a una latencia de checkout por encima del guardrail es un minuto de una peor experiencia real, con un costo real —abandono, frustración, quizás quejas de soporte—, incluso si al final apagas la feature y todo "vuelve a la normalidad". La reversibilidad no borra el daño que ya ocurrió mientras la feature estuvo encendida; solo evita que ese daño siga acumulándose después de que lo detectas. Por eso el segundo eje del marco —qué tan grave es si sale mal— importa tanto como el primero: cuanta más gente esté expuesta antes de que decidas revertir, más daño ya ocurrido vas a tener que explicar, aunque la reversa en sí misma sea instantánea. La lección 4 pone número exacto a esa relación entre "cuánta gente expones" y "cuánto daño ya ocurrió antes de que reviertas".

Errores comunes

Tratar todo lanzamiento con el mismo nivel de ceremonia, sin importar su perfil de riesgo. Qué pasa: un equipo exige el mismo proceso pesado de aprobaciones, revisiones y reuniones para lanzar un cambio trivial de texto que para lanzar recommendations con su guardrail roto. Por qué pasa: es más simple tener una sola política para "todos los lanzamientos" que evaluar caso por caso, y nadie quiere ser el que decide qué merece menos cuidado. Cómo detectarlo: preguntas "¿esto es una puerta de una sola vía o de dos vías, y qué tan grave es mientras no la revertimos?" y la respuesta es "no sé, aplicamos el mismo checklist a todo". Cómo corregirlo: usa el criterio de dos ejes de launchRiskProfile() para calibrar el nivel de cuidado — un typo no necesita el mismo proceso que una migración irreversible, y tratarlos igual solo hace más lento lo trivial sin hacer más seguro lo grave.

Confundir "reversible" con "sin consecuencias mientras está activo". Qué pasa: alguien argumenta "no importa si el guardrail se rompe, podemos apagarlo cuando queramos", como si la posibilidad de revertir eliminara el costo de cada minuto que la regresión estuvo afectando usuarios reales. Por qué pasa: "reversible" suena tranquilizador, y es fácil saltar de ahí a "entonces no hay urgencia real". Cómo detectarlo: la conversación sobre reversibilidad nunca menciona cuánta gente estaría expuesta, ni por cuánto tiempo, antes de que la reversa se active. Cómo corregirlo: como en la sección anterior, recuerda que la reversibilidad detiene el daño futuro, no borra el daño ya ocurrido — cuanto menor sea la exposición antes de revertir, menor el daño acumulado que vas a tener que explicar.

Usar el marco de riesgo para justificar no lanzar nunca. Qué pasa: alguien usa la existencia de cualquier severidad —por baja que sea— como excusa para posponer indefinidamente un lanzamiento, sin distinguir entre "grave e irreversible" y "grave pero contenible". Por qué pasa: es más cómodo evitar el riesgo por completo que aprender a manejarlo con cuidado, especialmente si "manejar el riesgo" todavía no tiene nombre concreto (eso llega en los módulos 2 a 5). Cómo detectarlo: la conclusión de cualquier análisis de riesgo es siempre "mejor no lanzar todavía", sin importar el perfil real del cambio. Cómo corregirlo: el marco de launchRiskProfile() tiene tres salidas, no dos — "ship directo", "exponer gradualmente con reversa lista", y "máxima cautela"—. La mayoría de los lanzamientos de producto, incluido recommendations, caen en la segunda categoría: ni ceremonia excesiva, ni luz verde sin cuidado.

Ejercicios

Ejercicio 1 — Clasifica un lanzamiento nuevo. El equipo de Mercado quiere lanzar un cambio de color en el botón "Agregar al carrito" (de azul a verde), basado en un experimento previo que mostró un lift pequeño en clics. Si algo sale mal, es trivial de notar y de revertir con un simple cambio de configuración. ¿Qué severityIfWrong y reversible le asignarías, y qué estrategia devolvería launchRiskProfile()?

Ver solución

severityIfWrong: 'low' (un color de botón, en el peor caso, afecta clics marginalmente — no hay riesgo de datos, dinero, o experiencia rota) y reversible: true (revertir un color es instantáneo). Con esos dos valores, launchRiskProfile() devuelve 'ship directo, sin ceremonia' — el mismo resultado que el typo del ejemplo trabajado. Este es exactamente el tipo de lanzamiento donde exigir el mismo proceso pesado que recommendations sería el primer error común de esta lección: ceremonia innecesaria para un cambio de bajo riesgo.

Ejercicio 2 — El caso intermedio, con matices. Supón que Mercado tiene, hoy, cero infraestructura de feature flags — no existe ninguna forma de apagar recommendations sin hacer un nuevo deploy completo (que toma 40 minutos). ¿Sigue siendo reversible: true en el sentido que usa launchRiskProfile()? Explica tu respuesta.

Ver solución

Es una zona gris intencionalmente incómoda, y esa incomodidad es el punto. Técnicamente, revertir un deploy completo es posible —no es una puerta de una sola vía absoluta, como sí lo sería una migración que borra datos sin respaldo—, pero 40 minutos de reversión es una eternidad si 250,000 usuarios están expuestos a una regresión de latencia mientras tanto. La respuesta honesta: es "reversible, pero lentamente" — una tercera zona entre los dos extremos del ejemplo trabajado, y precisamente la razón por la que el módulo 2 de esta guía enseña feature flags como mecanismo específico para hacer la reversa casi instantánea, en vez de depender de un nuevo deploy. Sin esa herramienta, incluso un lanzamiento "reversible en teoría" se comporta, en la práctica, mucho más parecido a uno de alta severidad sostenida.

Ejercicio 3 — Aplica el marco a tu propio contexto. Piensa en un cambio real que hayas lanzado (o visto lanzar) en tu trabajo — puede ser código, una política, un proceso—. Usando las dos preguntas de esta lección (¿qué tan grave si sale mal?, ¿qué tan fácil volver atrás?), ¿en qué zona del marco cayó? ¿El nivel de cuidado con el que se lanzó coincidió con esa zona, o hubo un desajuste (demasiada ceremonia para algo trivial, o muy poco cuidado para algo grave)?

Ver solución

No hay una respuesta única —depende de tu experiencia—, pero la prueba de calidad es esta: si tu cambio fue grave y difícil de revertir, y se lanzó con el mismo nivel de cuidado que un cambio trivial, ahí hay un desajuste real que vale la pena nombrar en retrospectiva. Y si fue trivial y reversible, pero pasó por semanas de aprobaciones, ese es el desajuste inverso —de los que hacen que un equipo pierda velocidad sin ganar seguridad real—. El objetivo de este ejercicio no es juzgar la decisión pasada, sino practicar el hábito de nombrar explícitamente las dos coordenadas antes de decidir cuánto cuidado amerita un lanzamiento, en vez de decidirlo por costumbre o por instinto.

Resumen y siguiente paso

En esta lección reformulaste el lanzamiento como una decisión de riesgo con dos coordenadas —qué tan grave si sale mal, qué tan fácil volver atrás— en vez de un interruptor binario. Con launchRiskProfile() ubicaste tres lanzamientos distintos en ese mapa, y viste dónde cae recommendations: grave si sale mal (el guardrail de latencia ya roto), pero reversible con las herramientas correctas — la zona donde la estrategia correcta no es "ship sin cuidado" ni "no lances nunca", sino "expón gradualmente, con la reversa lista".

Antes de avanzar deberías poder: explicar las dos coordenadas del marco de riesgo con tus propias palabras; ubicar un lanzamiento nuevo en las tres zonas del marco; y distinguir entre "reversible" y "sin consecuencias mientras está activo".

La lección 4 toma la coordenada de severidad y la convierte en un número exacto: cuántos usuarios reales quedan expuestos a una regresión conocida, según qué fracción de la base recibe el lanzamiento primero. Es el concepto que va a acompañarte el resto de esta guía — el radio de impacto, ejecutado en Node sobre el caso completo de recommendations.

Recursos

← AnteriorGanar el experimento no es lo mismo que lanzar el productoSiguiente →El radio de impacto: cuánta gente real toca un error conocido