Plantilla de Comunicación de Despliegues

Visión General

Lanzar una feature es solo la mitad del trabajo. La otra mitad es contarle a las personas correctas, de la manera correcta, en el momento correcto. Ingeniería sabe qué cambió; soporte necesita responder preguntas de clientes; ventas necesita demostrarlo; ejecutivos necesitan saber que está en vivo. Un plan de comunicación de despliegue asegura que nadie se sorprenda, que soporte esté preparado y que la feature realmente se use.

Cuándo Usar

Usa este recurso cuando:

• Estás lanzando una feature que afecta a usuarios, flujos de trabajo de soporte o procesos internos
• Múltiples equipos (ventas, soporte, marketing) necesitan saber sobre un despliegue
• Releases anteriores causaron confusión porque los stakeholders no fueron informados a tiempo

Solución

# Plan de Comunicación de Despliegue: `<Nombre del Release>`

## 1. Metadatos del Release

| Campo | Valor |
|-------|-------|
| Nombre / Versión | `nombre` |
| Fecha de Release | `AAAA-MM-DD` |
| Ventana de Despliegue | `HH:MM UTC` |
| Estrategia | `Todos / Gradual (X%) / Feature flag / Beta` |
| Responsable de Ingeniería | `@nombre` |
| Responsable de Producto | `@nombre` |
| Responsable de Comms | `@nombre` |

## 2. Matriz de Audiencias

| Audiencia | Canal | Momento | Responsable | Contenido |
|-----------|-------|---------|-------------|-----------|
| Ingeniería | Slack #releases | Día anterior + día del release | `@eng-owner` | Changelog técnico |
| Producto / Diseño | Slack #product | Día anterior | `@product-owner` | Resumen de feature |
| Soporte | Slack #support-alerts + KB | Día anterior | `@comms-owner` | FAQ + issues conocidos |
| Ventas | Email + Slack #sales | Día del release (después del deploy) | `@comms-owner` | Talking points + demo |
| Customer Success | Email + Slack #cs | Día del release | `@comms-owner` | Impacto para cuentas clave |
| Marketing | Slack #marketing | Según campaña | `@comms-owner` | Brief de campaña |
| Ejecutivos | Email resumen | Día después | `@product-owner` | Métricas + impacto |
| Clientes | Banner in-app / email / blog | Según estrategia | `@marketing` | Notas de release + guías |

## 3. Plantillas de Anuncio

### 3.1. Pre-Release (24h antes)

> **Próximo Release: `<Nombre>`**
>
> **Cuándo:** `Fecha / Hora UTC`
> **Qué:** `Resumen de una oración`
> **Quién se ve afectado:** `Usuarios / equipos / integraciones`
> **Riesgo:** `Bajo / Medio / Alto`
> **Rollback:** `Comando / kill switch`
> **Guardia:** `@ingeniero`

### 3.2. Día del Release

> **Lanzado: `<Nombre>`**
>
> **Estado:** `En producción`
> **Cambios:** `Resumen con viñetas`
> **Feature flag:** `Habilitado para X%` (si aplica)
> **Issues conocidos:** `Ninguno / lista`
> **Recursos:** `Link de FAQ / demo`
> **Próximos pasos:** `Monitoreo / rampa / campaña`

### 3.3. Día del Release + 1

> **Check-In: `<Nombre>`**
>
> **Métricas (24h):**
> - Error rate: `X%` (baseline: `Y%`)
> - Latencia P95: `X ms` (baseline: `Y ms`)
> - Adopción: `X%`
> **Issues:** `Ninguno / lista`
> **Action items:** `Lista`

## 4. Notas de Release Externas

Novedades

Feature

Descripción en lenguaje de cliente. Sin jerga técnica.

Cómo usarlo: Guía o link. Para quién: Segmento. Disponibilidad: Todos / Beta / Enterprise.

---

Correcciones

• Fix: descripción

Issues Conocidos

• Issue: descripción — workaround

Deprecaciones

• Feature X eliminado el AAAA-MM-DD. Migración: link

## 5. Lista de Verificación de Briefing de Soporte

- [ ] Acceso a la feature en entorno de demo
- [ ] FAQ con top 5 preguntas esperadas
- [ ] Issues conocidos y workarounds documentados
- [ ] Ruta de escalamiento para bugs post-release
- [ ] Macros / respuestas predefinidas actualizadas
- [ ] Override de feature flag documentado

## 6. Criterios de Rollback

| Criterio | Umbral | Acción |
|----------|--------|--------|
| Error rate | > 2x baseline > 10 min | Rollback o feature flag off |
| Latencia P95 | > 50% > 15 min | Rollback o feature flag off |
| Quejas | > 5 tickets en 1h sobre mismo issue | Evaluar; deshabilitar si correlacionado |
| Ingresos | Error en flujo de pagos | Rollback inmediato |
| Datos | Pérdida o corrupción | Rollback + incidente |

Explicación

La plantilla separa comunicación interna (técnica, accionable) de externa (amigable, enfocada en beneficios). La matriz de audiencias previene el fallo donde ingeniería anuncia en Slack, soporte se entera por un ticket, y ventas descubre una semana después. Los criterios de rollback dan permiso explícito para actuar rápido sin comité a medianoche.

Variantes

Contexto	Adición Clave	Tono
SaaS B2B	Briefings de AM, emails a clientes	Profesional, habilitación
App móvil	App store release notes, changelog in-app	Amigable, conciso
Plataforma API	Changelog dev, avisos breaking changes	Técnico, transparente
Herramienta interna	Solo Slack, sin comms externa	Casual, equipo
Rediseño mayor	Webinars, renovación docs	Educativo, de apoyo
Parche de seguridad	Mínimo detalle externo	Tranquilo, tranquilizador

Mejores Prácticas

1. Escribe notas de release antes del release; la presión genera mala documentación
2. Usa la misma terminología en todos los canales
3. Incluye “qué no cambió” para features retrasadas
4. Notifica a soporte como segunda audiencia, no la última
5. Mide engagement de notas; notas no leídas = feature no adoptada

Errores Comunes

1. Anunciar una feature antes de estar al 100% en vivo
2. Usar jerga técnica en notas orientadas a clientes
3. Olvidar notificar a customer success sobre cuentas de alto valor
4. No documentar issues conocidos
5. Tratar todo release igual; un parche de seguridad no es una nueva feature

Preguntas Frecuentes

¿Comunico todos los releases o solo los mayores?

Comunica todos internamente, pero varía el canal y detalle. Externamente, agrupa fixes menores en posts semanales o mensuales. Nunca dejes que un cliente note un cambio antes de que tú se lo digas.

¿Cómo manejo un release detrás de feature flag?

Dos fases: “Desplegado” (código en producción) y “Habilitado” (flag activo para usuarios). Anuncia el despliegue a ingeniería y soporte para preparación. Anuncia la habilitación a clientes y ventas cuando el flag se active. Incluye el nombre del flag y override en el briefing de soporte.

¿Qué pasa si necesito rollback?

Usa el anuncio pre-escrito: “Hemos revertido temporalmente <release> por <issue>. El equipo investiga y re-desplegará una vez resuelto. Impacto: <alcance>”. Notifica en orden inverso: clientes primero, luego soporte, luego internos. La velocidad y honestidad importan más que la prosa pulida.