Agencia de software · Entrega
Publicación de una app móvil en las tiendas
Haz que la actualización de la app de un cliente pase la revisión de las tiendas sin sorpresas de última hora. El cliente aporta los datos de la ficha y el acceso a sus cuentas desde un enlace público, y no se envía nada hasta que el líder de ingeniería aprueba la versión y el cliente aprueba las notas.
- Duración: 1 a 2 semanas
- Frecuencia: Para cada publicación en las tiendas
- Pasos: 10 pasos
- Agentes de IA: 1 agente de IA
- Aprobaciones: 1 aprobación
Plan gratuito, sin tarjeta de crédito.
Qué cambia con esta plantilla
Sin la plantilla
La app está en la cuenta de desarrollador de la agencia, y moverla después es un problema.
Las capturas, las respuestas de privacidad y los textos llegan el día antes del envío.
Un rechazo solo se descubre cuando el cliente pregunta por qué no ha salido la actualización.
Las notas de la versión las escribe con prisas quien hace el envío.
Con la plantilla
Desde la primera publicación se usan las cuentas del cliente, con tu equipo invitado.
El cliente comparte los datos de la ficha y las respuestas de privacidad al inicio, en un solo enlace.
Un rechazo bloquea la ejecución, con el motivo, hasta que la versión corregida se vuelve a enviar.
Un agente de IA las redacta, el líder de ingeniería las corrige y el cliente las aprueba.
La plantilla, paso a paso
Cada paso indica quién lo hace: alguien de tu equipo, un agente de IA o el cliente mediante un enlace público. Una aprobación mantiene bloqueados todos los pasos siguientes hasta que se da.
- Lo hace tu equipo
- Lo hace un agente de IA
- Lo hace el cliente, mediante un enlace público
Empieza cuando
Una versión de la app móvil de un cliente está lista para publicarse. El jefe de proyecto inicia una ejecución con el nombre de la app, la versión y la fecha prevista de publicación.
- 1
Planificar la publicación y compartir el enlace
Día 1Jefe de proyecto · Equipo
Acuerda qué entra en la versión, rellena los datos de la publicación y envía al cliente el enlace público con lo que las tiendas necesitan de él.
Lista de verificación
- Contenido de la versión acordado
- Enlace público enviado al cliente
Campos que rellenar
- Nombre de la app (obligatorio)
- Versión (obligatorio)
- Fecha prevista de publicación (obligatorio)
- 2
El cliente aporta los datos de la tienda y el acceso a sus cuentas
Días 1 a 3Product owner del cliente · Enlace público
En el enlace público, el cliente confirma que la app se publica con sus propias cuentas de desarrollador, invita al equipo y comparte lo que necesitan las fichas de las tiendas.
Lista de verificación
- Equipo invitado a la cuenta de desarrollador de Apple
- Equipo invitado a Google Play Console
- Preguntas de privacidad y seguridad de datos respondidas
Campos que rellenar
- Funciones que destacar (obligatorio)
- Enlace a la política de privacidad (obligatorio)
- Correo de soporte (obligatorio)
- Enlace a las capturas nuevas
- 3
Generar la versión candidata
Días 2 a 5Desarrollador móvil · Equipo
Genera la versión candidata firmada con los números de versión y de compilación correctos, y distribúyela a los dispositivos de prueba.
Lista de verificación
- Número de versión y de compilación fijados
- Firmada con los certificados del cliente
- Distribuida a los dispositivos de prueba
Campos que rellenar
- Número de compilación (obligatorio)
- Enlace a la versión de prueba (obligatorio)
- 4
Probar en dispositivos reales
Oculto en el enlace públicoDías 4 a 7Ingeniero de QA · Equipo
Prueba la versión candidata en los dispositivos y versiones de sistema operativo soportados, incluida la actualización desde la versión publicada ahora.
Lista de verificación
- Probada en el sistema operativo más antiguo soportado
- Actualización desde la versión publicada probada
- Normas de las tiendas revisadas
- Ningún cierre al arrancar
Campos que rellenar
- Enlace al informe de pruebas (obligatorio)
- Problemas conocidos
- 5
Redactar las notas de la versión para las tiendas
Día 7Redactor de notas para tiendas · Agente de IA
El redactor de notas para tiendas redacta las notas de la versión para las dos tiendas a partir de las funciones que el cliente quiere destacar y los problemas conocidos, dentro de los límites de longitud de sus instrucciones.
Campos que rellenar
- Borrador de las notas de la versión (obligatorio)
Revisión humana: El líder de ingeniería corrige las notas y aprueba la versión en el paso 6.
- 6
Aprobar la versión para enviarla
Día 8Líder de ingeniería · Equipo
Lee el informe de pruebas y los problemas conocidos, corrige las notas de la versión, aprueba la versión y envía por correo las notas definitivas al cliente.
Lista de verificación
- Informe de pruebas leído
- Notas de la versión corregidas
- El número de compilación coincide con la versión probada
Aprobación: La aprobación del cliente y el envío a las tiendas siguen bloqueados hasta que el líder de ingeniería aprueba la versión.
- 7
El cliente aprueba las notas y la fecha
Días 8 a 9Product owner del cliente · Enlace público
El cliente lee las notas de la versión que le envió el líder de ingeniería y registra en el enlace público su decisión y la fecha en que la versión puede salir.
Campos que rellenar
- Decisión (obligatorio)
- Publicar el (obligatorio)
- Cambios en el texto
- 8
Enviar a revisión de las tiendas
Día 9Desarrollador móvil · Equipo
Envía la versión aprobada y sus notas a las dos tiendas, configura la publicación como manual o gradual y registra la fecha de envío.
Lista de verificación
- Enviada a la App Store
- Enviada a Google Play
- Publicación configurada como manual o gradual
Campos que rellenar
- Enviada el (obligatorio)
- 9
Gestionar el resultado de la revisión
Días 9 a 12Desarrollador móvil · Equipo
Registra el resultado de cada revisión. Si una tienda rechaza la versión, marca la ejecución como bloqueada, anota el motivo y vuelve a enviarla tras la corrección.
Campos que rellenar
- Resultado de la revisión en la App Store (obligatorio)
- Resultado de la revisión en Google Play (obligatorio)
- Motivo del rechazo
- 10
Publicar y comprobar que la versión está disponible
Semana 2Jefe de proyecto · Equipo
Publica la versión en la fecha acordada, comprueba que se instala desde las dos tiendas y avisa al cliente.
Lista de verificación
- Disponible en las dos tiendas
- Se instala y se abre desde la tienda
- Informes de cierres revisados tras la publicación
- Cliente avisado
Campos que rellenar
- Disponible desde (obligatorio)
Termina cuando
La versión está publicada en las dos tiendas con las cuentas de desarrollador del propio cliente, y la publicación queda registrada en la ejecución.
Hazla tuya. Cambia el nombre de los pasos y los responsables, y añade elementos a la lista, campos o aprobaciones. La plantilla es un punto de partida para la forma de trabajar de tu equipo.
Los agentes de IA de esta plantilla
Un agente solo trabaja en sus propios pasos, y una persona de tu equipo revisa lo que hizo. Todo lo que un agente escribe en una app conectada espera aprobación, salvo que lo permitas.
Redactor de notas para tiendas
Redacta las notas de la versión para las dos tiendas a partir de lo que cambió en esta versión.
Qué hace
- Lee las funciones que el cliente quiere destacar y los problemas conocidos
- Escribe notas de la versión breves para los usuarios
- Respeta los límites de longitud de sus instrucciones
- Completa su paso para que el líder de ingeniería pueda revisarlo
Revisión humana: El líder de ingeniería corrige las notas y aprueba la versión en el paso 6.
Preguntas que responde esta plantilla
Publica con las cuentas de desarrollador del propio cliente, con tu equipo invitado, y envía solo una versión probada y aprobada. En el paso 2 el cliente invita al equipo y responde las preguntas de privacidad en el enlace público, y en el paso 8 el desarrollador móvil envía la versión aprobada.
En la del cliente, para que conserve la app, sus valoraciones y sus usuarios si algún día dejáis de trabajar juntos. El paso 2 pide al cliente que confirme sus propias cuentas e invite a tu equipo antes de preparar la primera versión para publicar.
Prueba en el sistema operativo más antiguo que soportas, prueba la actualización desde la versión publicada y revisa las normas de las tiendas que provocan rechazos. El paso 4 recoge esa lista de verificación para el ingeniero de QA, con un enlace al informe de pruebas.
Anota el motivo, corrígelo y vuelve a enviarla, y avisa al cliente en lugar de dejar que la fecha se retrase en silencio. En el paso 9 el desarrollador móvil marca la ejecución como bloqueada con el motivo del rechazo hasta que la versión corregida se vuelve a enviar.
Deja que la IA redacte las notas de la versión para las dos tiendas a partir de lo que cambió, y que la aprobación de la versión quede en tu equipo. El redactor de notas para tiendas redacta el texto en el paso 5, y el paso 6 es un control de aprobación en el que el líder de ingeniería lo corrige y aprueba la versión.
Envía con antelación, configura la publicación como manual o gradual, y publica en la fecha que acordó el cliente. En el paso 7 el cliente fija la fecha, en el paso 8 el desarrollador móvil envía con publicación manual o gradual, y en el paso 10 la versión sale.
Ejecuta este flujo en OKiDO
Configura los pasos, los responsables y las aprobaciones una vez, y luego inicia una ejecución para cada caso nuevo.