Plan de Implementación Gradual
Genera un plan de liberación estructurado siguiendo el Marco de Liberación Gradual Idira: inferir señales del PRD, clasificar la ruta de liberación, mapear anillos, construir el plan de cohortes R3 y proporcionar pasos de configuración de LaunchDarkly.
Paso 1 — Leer e Inferir del PRD
Lee el PRD completo. Infiere cada señal del contenido. No le preguntes al PM nada que puedas determinar por ti mismo.
| Señal | Qué buscar |
|---|---|
| NFI | Etiqueta "NFI", "nueva funcionalidad", "no disponible anteriormente", capacidad completamente nueva sin versión previa |
| Impacto | Alcance de usuarios/tenants afectados, lenguaje de "ruta crítica" / "flujo de trabajo central", sensibilidad de datos, riesgo de pérdida de datos o interrupción del servicio |
| Complejidad del rollback | Migraciones de esquema, escrituras de datos, dependencias de terceros, comunicaciones requeridas al cliente, estado irreversible → Coordinado o Irreversible. Solo cambio de flag → Fácil. Si no se menciona → debe preguntar |
| Restricciones de región | GDPR, FedRAMP, residencia de datos, requisitos geográficos específicos, "empezando con [región]", "solo [región]", "[región] primero", "limitado a [región]" |
| Restricciones de servicio | Servicios, integraciones o componentes específicos de los que la funcionalidad depende o modifica |
| Disponibilidad para pruebas tempranas | "listo para QA", fechas de finalización de sprint, fechas alfa/beta — cuándo la funcionalidad es lo suficientemente estable para la primera exposición externa |
| GA objetivo | Fecha de lanzamiento comprometida, plazo de OKR, hito de liberación |
Después de leer, presenta tus inferencias — no hagas preguntas abiertas. Para cualquier señal no encontrada en el PRD, márcala como ❓ y haz una pregunta específica al final:
Basado en el PRD, así es como he leído esta liberación:
- NFI: [Sí / No — razón] o ❓ No está claro en el PRD
- Impacto: [Alto / Medio / Bajo — razón] o ❓ No está claro en el PRD
- Rollback: [Fácil / Coordinado / Irreversible — razón] o ❓ No se menciona
- Restricciones de región: [Ninguna / lista — razón] o ❓ No se menciona
- Restricciones de servicio: [Ninguna / lista — razón] o ❓ No se menciona
- Disponible para pruebas tempranas: [fecha — razón] o ❓ No encontrado en el PRD
- GA objetivo: [fecha — razón] o ❓ No encontrado en el PRD
Luego pregunta solo las preguntas ❓, usando estas formas exactas:
- Rollback no mencionado → "¿Existe un plan de rollback? Opciones: (1) Fácil — cambio de flag simple, revierte al instante. (2) Coordinado — requiere migración de datos, script o comunicaciones al cliente. (3) Aún no definido — la estrategia de rollback está por diseñarse."
- Impacto no claro → "¿Cómo describirías el impacto para el cliente si algo sale mal? Alto (afecta flujos de trabajo centrales o muchos tenants), Medio (limitado a un servicio específico o subconjunto), o Bajo (cosmético / fácilmente reversible)?"
- Disponible para pruebas tempranas no encontrado → "¿Cuándo estará la funcionalidad lista para que los probadores tempranos comiencen a validar?"
- GA objetivo no encontrado → "¿Cuál es la fecha o el plazo objetivo para GA?"
- Región no mencionada → "¿Hay restricciones de región? Por ejemplo, ¿empezar con una región específica (EMEA, EE. UU., APAC) antes de expandirse globalmente?"
No asumas ningún valor. No preguntes sobre señales que ya hayas resuelto del PRD.
Paso 2 — Clasificar la Ruta de Liberación
NFI = Sí → ALTA INTERACCIÓN
O Impacto = Alto
O Rollback = Irreversible
Impacto = Medio → ESTÁNDAR
O Rollback = Coordinado
Todos los demás → LIGERO
Paso 3 — Mapear Anillos Requeridos
| Ruta | Anillos obligatorios | I+D es propietario | PM es propietario |
|---|---|---|---|
| LIGERO | R0 → R4 | R0 | R4 |
| ESTÁNDAR | R0 → R3 → R4 | R0 | R3, R4 |
| ALTA INTERACCIÓN | R0 → R1 → R2 → R3 → R4 | R0, R1 | R2, R3, R4 |
- R0 QA interno — entornos de ingeniería/QA
- R1 Cliente Cero / Dogfooding — equipos internos
- R2 Cliente Uno — clientes seleccionados de Acceso Anticipado (a través del proceso NFI)
- R3 Canary de Producción — Tenants de Prueba → cohortes en vivo mediante flags de LaunchDarkly
- R4 Disponibilidad General — todos los tenants de producción elegibles
Paso 4 — Construir el Plan de Cohortes R3 (solo Estándar y Alta Interacción)
R3 siempre comienza primero con Tenants de Prueba. Luego secuencia los tenants en vivo por ARR:
| Ola | % Acumulado | Segmentación |
|---|---|---|
| 0 | — | Tenants de Prueba (sandboxes comprados por clientes) |
| 1 | 5% | ARR más bajo, recuento pequeño de tenants |
| 2 | 15% | ARR bajo a medio |
| 3 | 35% | ARR medio |
| 4 | 65% | ARR medio a alto |
| 5 | 100% | Todos los tenants elegibles restantes |
Ajustes:
- Restricciones de servicio → agregar segmentación por filtro de servicio por ola
- Restricciones de región → agregar filtro de región a las primeras olas, eliminar para las olas 4–5
- Plazo corto → fusionar olas (por ejemplo, 5% → 35% → 100%)
- Alta sensibilidad ARR → mantener tenants de alto ARR hasta la ola 4 con tiempo de cocción extendido
Para cada ola incluye: %, descripción de la cohorte, puerta de aprobación/rechazo (métrica + tiempo de cocción), propietario. Las puertas de aprobación/rechazo son obligatorias — nunca las omitas. Si el PRD define métricas de éxito, úsalas. Si no, aplica valores predeterminados: tasa de éxito de firma/funcionalidad ≥99,5%, delta de tasa de error <0,1%, regresión de latencia p99 <5%, pico de tickets de soporte <3 por cada 1.000 tenants, tiempo de cocción mínimo de 48 h para las primeras olas y 1 semana para olas de alto ARR.
Paso 5 — Generar el Plan de Liberación Completo
Produce el plan usando esta plantilla:
# Plan de Implementación Gradual — [Nombre de la funcionalidad]
**Ruta de liberación:** [LIGERO / ESTÁNDAR / ALTA INTERACCIÓN]
**Inicio más temprano:** [fecha] | **GA objetivo:** [fecha]
---
## Cómo he leído esta liberación
| Señal | Valor | Razonamiento |
|--------|-------|-----------|
| NFI | Sí/No | [una línea] |
| Impacto | Alto/Medio/Bajo | [una línea] |
| Rollback | Fácil/Coordinado/Irreversible | [una línea] |
| Restricciones de región | Ninguna / [lista] | [una línea] |
| Restricciones de servicio | Ninguna / [lista] | [una línea] |
---
## Anillos Requeridos
| Anillo | Etapa | Propietario | Puerta de entrada | Puerta de salida |
|------|-------|-------|------------|-----------|
| R0 | QA interno | I+D | Fusión a rama principal | Aprobación de QA |
| R1 | Dogfooding | I+D | R0 completado | Aprobación interna *(solo Alta Interacción)* |
| R2 | Cliente Uno | PM | Proceso NFI completado | Comentarios del cliente revisados *(solo Alta Interacción)* |
| R3 | Canary de Producción | PM | R2 completado | 100% de ola estable |
| R4 | Disponibilidad General | PM | Ola R3 al 100% completada | Aprobación/rechazo del PM |
*(Incluye solo los anillos requeridos para la ruta elegida)*
---
## Plan de Cohortes R3
**Primero:** Tenants de Prueba — confirmar activación segura antes de cualquier tenant en vivo.
| Ola | % | Quién | Segmentación | Puerta de Aprobación/Rechazo |
|------|---|-----|-----------|---------------|
| 0 | — | Tenants de Prueba | Tenants de prueba externos | Sin incidentes durante 48 h |
| 1 | 5% | ARR bajo | [criterios] | [métrica] estable durante [tiempo de cocción] |
| 2 | 15% | ARR bajo–medio | [criterios] | [métrica] estable durante [tiempo de cocción] |
| 3 | 35% | ARR medio | [criterios] | [métrica] estable durante [tiempo de cocción] |
| 4 | 65% | ARR medio–alto | [criterios] | [métrica] estable durante [tiempo de cocción] — extendido |
| 5 | 100% | Todos los elegibles | Eliminar filtros | [métrica] estable durante [tiempo de cocción] |
---
## Configuración de LaunchDarkly
**1. Crear el flag de funcionalidad**
- Clave del flag: `[nombre-funcionalidad]-rollout` (minúsculas, guiones)
- Tipo: Booleano
- Valor predeterminado (desactivado): falso para todos los entornos
**2. Configurar entornos**
- `internal-qa` → R0: habilitar para el equipo de QA de I+D
- `dogfooding` → R1: habilitar para tenants de empleados internos *(solo Alta Interacción)*
- `early-access` → R2: habilitar para tenants de Cliente Uno específicos *(solo Alta Interacción)*
- `production` → R3: reglas de segmentación a continuación
**3. Reglas de segmentación de producción (olas R3)**
Ola 0 — Tenants de Prueba:
- Regla: `tenant_type = "test"` → servir verdadero
Ola 1 — 5%:
- Regla: `tenant_type = "live" AND arr_tier = "low"` → servir verdadero al 5% de asignación
Ola 2 → 5: Incrementa el porcentaje de asignación y expande el filtro `arr_tier` por ola.
Elimina el filtro `arr_tier` por completo en la ola 5 (100%).
Si se aplican restricciones de servicio:
- Agrega `AND deployed_services CONTAINS "[nombre-del-servicio]"` a cada regla.
Si se aplican restricciones de región:
- Agrega `AND region IN ["[región]"]` a las primeras olas; elimínalo para las olas 4–5.
**4. Puertas entre olas**
- Monitorea la tasa de error, latencia (p99) y tickets de soporte durante el período de cocción.
- Solo expande a la siguiente ola después de que se cumplan los criterios de aprobación/rechazo.
- Para pausar o revertir: establece el flag de producción en falso — todos los tenants revierten inmediatamente.
**5. Interruptor único**
- I+D debe implementar una clave de flag en todos los componentes afectados.
- Confirma con I+D que todos los componentes lean el mismo flag antes de que comience R3.
---
## Propietarios y Responsabilidades
- **I+D** — Implementa el flag, es propietario de R0–R1, valida la cobertura de interruptor único
- **PM** — Es propietario de la exposición al cliente (R2–R4), firma cada puerta de ola, actualiza el plan de cohortes
- **Product Ops** — Revisa el plan según las pautas obligatorias antes de que comience R3
## Preguntas Abiertas / Suposiciones
- [Lista de hechos asumidos o aún por confirmar con I+D / BI]
Ejemplo
Consulta reference.md para un ejemplo práctico (NFI, Alto Impacto, objetivo GA de 3 meses) que muestra un plan completo con tabla de cohortes y reglas de LaunchDarkly rellenadas.