Práctica 01.04 · Calidad del producto
Publica actualizaciones sin sorpresas
Un release seguro responde tres preguntas por adelantado: qué se revisará antes de publicar, quién vigilará las primeras señales y qué condición detendrá la distribución.
45 minutos antes del release
En lenguaje sencillo
Un release es una revisión controlada, no solo un botón de publicar
Qué vas a necesitar
01
Cuándo aplicarla
Antes de cada actualización, sobre todo cuando cambian el registro, el almacenamiento de datos, las notificaciones, los deep links o una ruta clave del usuario.
En lenguaje sencillo
Qué abrir antes del release
Reúne los enlaces por adelantado. Cuando aparezca un problema, el equipo no debería estar buscando el dashboard correcto ni a la persona correcta en el historial del chat.
Lista de cambios
Toma las tareas del release y tradúcelas a rutas de usuario: inicio de sesión, registro, contenido, una operación, notificaciones, perfil.
Si no hay lista de cambios, pide a cada desarrollador que diga en una frase su cambio y la pantalla que podría afectar.Estabilidad y eventos
Prepara dashboards del crash-free rate, ANR, errores de API y eventos clave de la versión nueva de la app.
Sin dashboard, asigna a alguien para revisar logs, cuentas de prueba y solicitudes de soporte a los 30, 60 y 120 minutos.Canal de reacción
Define por adelantado el chat, la persona que decide y la forma de detener la distribución o publicar rápido un arreglo.
Si revertir técnicamente no es posible, anota un plan seguro: pausar campañas, desactivar la función o avisar a los usuarios.02
Prepara el release en cinco pasos
Traduce las tareas a rutas de usuario
No te quedes en una lista de cambios técnicos. Di qué verá el usuario y qué ruta vecina podría romperse.
- Dónde hacerlo
- En la parte superior de la ficha de release, junto a la versión.
- Cómo se ve el resultado
- Cambió la autorización → revisar el inicio de sesión, la restauración de sesión, la actualización desde la versión antigua y el deep link para un usuario sin sesión.
Revisa la instalación limpia y la actualización
Una instalación nueva y una actualización desde una versión antigua son escenarios distintos. Prueba los dos en iOS y Android con cuentas de prueba reales.
- Dónde hacerlo
- En la build de prueba y en la versión de la tienda.
- Cómo se ve el resultado
- Después de actualizar desde 4.2 el usuario sigue con la sesión abierta; el historial y los ajustes se conservan.
Recorre las acciones críticas
Revisa el inicio de sesión, la primera acción útil, la operación clave, una notificación y el regreso desde segundo plano. Anota el hecho, no un «debería funcionar».
- Dónde hacerlo
- En una lista de verificación con la fecha, el dispositivo y el nombre de quien revisa.
- Cómo se ve el resultado
- Android 13: el registro pasó 10 de 10 veces; el evento de finalización se ve en el reporte.
Anota las condiciones de parada
Antes de publicar, define la señal concreta que detiene la distribución. «Si se ve mal» no ayuda a nadie a decidir.
- Dónde hacerlo
- En la última columna de la ficha de release.
- Cómo se ve el resultado
- Nos detenemos si la conversión de inicio de sesión en la versión nueva está más de 10% por debajo de lo normal o si empiezan a perderse sesiones.
Asigna el monitoreo posterior al release
Nombra al responsable, los intervalos de revisión y el canal de reacción. Soporte debe saber qué cambió y qué datos adjuntar a las solicitudes.
- Dónde hacerlo
- En el chat y en la ficha de release.
- Cómo se ve el resultado
- Revisiones a los 30, 60 y 120 minutos; responsable: María; soporte adjunta la versión de la app y el ID del usuario.
03
Ejemplos prácticos
Antes de publicar: la actualización desde 4.2
QA actualiza la versión de la tienda y revisa que la sesión y el historial se conserven. Perder la sesión o los datos es una condición de parada escrita de antemano, no algo para discutir después del lanzamiento.
Después de publicar: puntos de control
El responsable del release observa el crash-free rate, los errores de inicio de sesión y la conversión de la acción clave a los 30, 60 y 120 minutos; soporte adjunta la versión de la app a cada solicitud nueva.
Ficha de control del release 4.3
Una fila por revisión. El responsable, el hecho observado y la condición de parada van justo al lado.
| Revisión | Responsable | Resultado esperado | Condición de parada |
|---|---|---|---|
| Actualización desde 4.2 | QA | Sesión y datos conservados | Pérdida de sesión o de datos |
| Registro limpio | iOS/Android | El código y el perfil funcionan | Éxito por debajo del 95% en las pruebas |
| Acción clave | Product manager | El evento y el resultado se ven | Caída de conversión >10% |
| Deep link desde un push | Especialista de CRM | Se abre la pantalla correcta | El enlace lleva a un error |
| Primeras 2 horas | Responsable del release | Crash-free en el rango normal | Subida fuerte de cierres inesperados o ANR |
La decisión la toma el responsable del release. Ante una señal de parada, el equipo detiene la distribución, anota la hora y la versión, avisa a soporte y elige entre revertir o hacer un arreglo urgente.
04
Lista de verificación del release
No marques puntos por adelantado. Cada revisión necesita un hecho: dispositivo, hora, resultado o enlace al dashboard.
05
Qué observar después del release
Estabilidad
El crash-free rate, el ANR y los errores de API de la versión nueva se mantienen en el rango normal.
Ruta clave
El inicio de sesión, el registro y la acción principal no rinden peor que en la versión anterior.
Señales en vivo
Soporte y las reseñas no muestran ningún problema nuevo recurrente en las primeras 72 horas.
Si el equipo no sabe quién detiene la distribución ni ante qué señal, el release no está listo para publicarse.