Checklist antes de lanzar una feature
Una lista de verificación para los días previos al lanzamiento de una funcionalidad, cubriendo desde la comunicación interna hasta el plan de monitorización post-lanzamiento.
La semana antes del lanzamiento
Verificación de la funcionalidad
- Los criterios de aceptación están verificados en el entorno de staging.
- Los casos extremos han sido probados (estado vacío, error, carga lenta, falta de permisos).
- La funcionalidad ha sido probada en los dispositivos y navegadores relevantes para la base de usuarios.
- El comportamiento con datos reales (no de demo) ha sido validado.
- Si hay una migración de datos, ha sido probada en staging con datos representativos.
Comunicación interna
- El equipo de soporte conoce la funcionalidad y tiene respuestas a las preguntas más frecuentes anticipadas.
- El equipo de ventas (si aplica) sabe qué puede contar y qué no.
- Los stakeholders que pidieron la funcionalidad han sido informados del lanzamiento y de la fecha.
- Se ha preparado documentación interna mínima para el equipo de soporte.
Plan de rollout
- Se ha decidido la estrategia de lanzamiento: lanzamiento completo, rollout gradual, feature flag por segmento.
- Si hay rollout gradual, está definido el porcentaje inicial y los criterios para ampliar o revertir.
- Está identificado quién tiene la capacidad técnica de revertir el lanzamiento si hay un problema crítico.
El día del lanzamiento
- El equipo técnico está disponible o en guardia durante las primeras horas.
- El dashboard de monitorización está abierto con las métricas clave visibles.
- El canal de comunicación de incidencias está activo.
Los primeros 7 días post-lanzamiento
Monitorización
- Las métricas de uso de la nueva funcionalidad están siendo revisadas diariamente.
- Las métricas de negocio impactadas están siendo monitorizadas (conversión, retención, soporte).
- Los tickets de soporte relacionados con la nueva funcionalidad están siendo revisados.
- No hay degradación de rendimiento (tiempo de carga, errores, caídas).
Análisis inicial
- ¿El uso de la funcionalidad es el esperado? Si es significativamente menor, ¿se sabe por qué?
- ¿Han aparecido casos de uso no anticipados que revelan algo sobre cómo los usuarios interpretan la funcionalidad?
- ¿Hay feedback de soporte que indique problemas de comprensión o usabilidad?
A los 30 días
- Se ha hecho una revisión formal de si la funcionalidad está generando el impacto esperado.
- Si hay aprendizajes relevantes, se han documentado y compartido con el equipo.
- Si el impacto no es el esperado, se ha iniciado un proceso de diagnóstico.
- Se ha decidido si hay iteraciones inmediatas necesarias o si la siguiente versión va al backlog.
Notas de uso
Este checklist no es una lista de burocracia. Es una lista de cosas que, si no se hacen, generan problemas después.
Adapta los ítems al tamaño y complejidad de la funcionalidad. No todos los ítems son relevantes para todas las funcionalidades. Pero si vas a saltarte uno, hazlo conscientemente.