Qué incluye
Publicar una app móvil no es desplegar software en un servidor: decide otro cuándo entra en producción tu build, y el plan tiene que reflejarlo. La plantilla separa el trabajo que controlas de la espera que no:
- Estabilización de la build — Congelación de funcionalidades, triaje de fallos y bloqueos, trabajo de rendimiento y memoria, accesibilidad y pruebas sobre la matriz de dispositivos, y la build candidata. Hito: candidata lista.
- Pruebas beta — Subidas a TestFlight y al canal interno de Play, beta interna, captación de personas probadoras externas, la ronda externa y el triaje de comentarios. Hito: criterios de salida de la beta cumplidos.
- Ficha de tienda y recursos gráficos — Investigación de palabras clave y categoría, nombre y descripción, capturas y vídeo de presentación, icono y gráficos, declaración de privacidad de datos y cuestionario de clasificación por edad.
- Envío y revisión — Comprobación previa de cumplimiento, envío a ambas tiendas, la espera de revisión y una reserva real para un rechazo y su reenvío. Hito: aprobada y lista para publicar.
- Despliegue por fases — Publicación escalonada al 1%, 10% y 50%, comprobando la tasa de sesiones sin fallos en cada paso antes de ampliar a disponibilidad total. Hito: disponibilidad total.
- Parche del día uno y seguimiento — Vigilancia de fallos y bloqueos, la ventana de parche reservada, respuesta a las valoraciones de la tienda y la lectura de retención de la primera semana.
Cómo personalizarla
- Fija la fecha de envío a revisión y avanza hacia delante, no hacia atrás: la duración de la revisión no es tuya para comprimirla.
- Separa las filas de envío y revisión por tienda si tus builds de iOS y Android van a ritmos distintos; los plazos de revisión son diferentes.
- Amplía la reserva de rechazo si es un primer envío, una app de suscripción o cualquier cosa que toque borrado de cuenta, datos de salud o contenido generado por personas usuarias.
- Ajusta los porcentajes de despliegue a tu plataforma: el despliegue escalonado de Play y la publicación por fases de App Store no avanzan igual.
- Mantén la ventana de parche en el gráfico con personas asignadas: una ventana de parche sin gente es simplemente una semana vacía.
- Marca como hitos la candidata, la salida de la beta, la aprobación de la tienda y la disponibilidad total: son las cuatro fechas por las que preguntará todo el mundo.
Consejos de programación
- Prepara los metadatos de la ficha antes de cerrar el binario. Capturas, descripciones y declaración de privacidad se pueden preparar y revisar por separado, así que nunca deberían ser lo que bloquea el día del envío.
- No anuncies una fecha de lanzamiento atada a una aprobación que aún no tienes. Haz que el marketing dependa del hito de aprobación, para que un rechazo mueva la campaña de forma automática.
- Mira la tasa de sesiones sin fallos en cada escalón. El sentido de un despliegue por fases es poder parar entre pasos; si nadie tiene asignado mirar los números, el escalonamiento no sirve de nada.
- Reserva la ventana de parche antes del lanzamiento, no después. Quien construiría el arreglo del día uno es exactamente la misma gente que, si no, acabarás asignando al siguiente sprint el mismo día del lanzamiento.
- Capta a las personas probadoras externas con semanas de antelación. Reunir un número útil de dispositivos reales lleva más de lo que se planifica, y una beta escasa no encuentra nada.
- Fija la línea base en la candidata a publicación. Todo lo anterior es estimación; después, el calendario es sobre todo la cola de otras personas y conviene seguirlo como desviación.
Plantillas relacionadas
- Plantilla de diagrama de Gantt para lanzamiento de producto
- Plantilla de diagrama de Gantt para desarrollo de software
- Plantilla de plan de desarrollo de producto
- Ver todas las plantillas de diagramas de Gantt
Esta plantilla está en español. Las páginas relacionadas que aún no se han traducido se abren en inglés.
Preguntas frecuentes
¿Cuánto tarda la revisión de las tiendas de aplicaciones?
La mayoría de revisiones de App Store se resuelven en uno o dos días, y las de Google Play suelen ser más rápidas, pero ambas pueden alargarse bastante en un primer envío o en una categoría sensible. La plantilla reserva diez días más una reserva de rechazo para que una revisión con mala suerte no rompa el plan.
¿Qué debe incluir un plan de lanzamiento de app móvil?
Estabilización de la build, pruebas beta, ficha de tienda y recursos, envío y revisión, despliegue por fases y una ventana de parche del día uno. Las seis vienen ya cargadas, con la espera de revisión modelada como dependencia y no como suposición.
¿En qué se diferencia de un plan de lanzamiento de producto?
Este tiene forma de tienda de aplicaciones: gira sobre envío, revisión y despliegue escalonado. Para el trabajo comercial más amplio de precio, posicionamiento y campañas, usa en paralelo la plantilla de lanzamiento de producto.
¿Despliegue por fases o publicación para todo el mundo?
Hazlo por fases salvo que tengas una razón para no hacerlo. Una publicación escalonada te deja parar en el 1% cuando cae la tasa de sesiones sin fallos, que sale mucho más barato que una reversión de urgencia con toda la audiencia dentro.
¿Es gratuita?
Sí, con descarga en Excel, PowerPoint y CSV y edición online sin cuenta ni marca de agua.