Agência de software · Entrega
Publicação de app mobile nas lojas
Faça a atualização do app de um cliente passar pela revisão das lojas sem surpresas de última hora. O cliente fornece os dados da listagem e o acesso às contas por um link público, e nada é enviado antes de o líder de engenharia aprovar a versão e o cliente aprovar as notas.
- Duração: 1 a 2 semanas
- Frequência: Para cada publicação nas lojas
- Etapas: 10 etapas
- Agentes de IA: 1 agente de IA
- Aprovações: 1 aprovação
Plano gratuito, sem cartão de crédito.
O que muda com este modelo
Sem o modelo
O app fica na conta de desenvolvedor da software house, e transferir depois dá trabalho.
Capturas de tela, respostas de privacidade e textos chegam na véspera do envio.
Uma rejeição só aparece quando o cliente pergunta por que a atualização não saiu.
As notas da versão são escritas às pressas por quem faz o envio.
Com o modelo
As contas do próprio cliente são usadas desde a primeira publicação, com a sua equipe convidada.
O cliente compartilha os dados da listagem e as respostas de privacidade no início, por um único link.
Uma rejeição bloqueia a execução, com o motivo, até a versão corrigida ser reenviada.
Um agente de IA escreve as notas, o líder de engenharia corrige e o cliente aprova.
O modelo, etapa por etapa
Cada etapa diz quem a faz: alguém da sua equipe, um agente de IA ou o cliente por um link público. Uma aprovação mantém todas as etapas seguintes travadas até ser dada.
- Feito pela sua equipe
- Feito por um agente de IA
- Feito pelo cliente, por um link público
Começa quando
Uma versão do app mobile de um cliente está pronta para publicação. O gerente de projeto inicia uma execução com o nome do app, a versão e a data prevista de publicação.
- 1
Planejar a publicação e compartilhar o link
Dia 1Gerente de projeto · Equipe
Combine o que entra na versão, preencha os dados da publicação e envie ao cliente o link público com o que as lojas precisam dele.
Checklist
- Conteúdo da versão combinado
- Link público enviado ao cliente
Campos a preencher
- Nome do app (obrigatório)
- Versão (obrigatório)
- Data prevista de publicação (obrigatório)
- 2
O cliente fornece os dados das lojas e o acesso às contas
Dias 1 a 3Product owner do cliente · Link público
Pelo link público, o cliente confirma que o app é publicado nas próprias contas de desenvolvedor, convida a equipe e compartilha o que as listagens das lojas precisam.
Checklist
- Equipe convidada na conta de desenvolvedor da Apple
- Equipe convidada no Google Play Console
- Perguntas de privacidade e segurança dos dados respondidas
Campos a preencher
- Funcionalidades a destacar (obrigatório)
- Link para a política de privacidade (obrigatório)
- E-mail de suporte (obrigatório)
- Link para as novas capturas de tela
- 3
Gerar a versão candidata
Dias 2 a 5Desenvolvedor mobile · Equipe
Gere a versão candidata assinada com os números de versão e de build corretos, e distribua para os aparelhos de teste.
Checklist
- Números de versão e de build definidos
- Assinada com os certificados do cliente
- Distribuída para os aparelhos de teste
Campos a preencher
- Número do build (obrigatório)
- Link para a versão de teste (obrigatório)
- 4
Testar em aparelhos reais
Oculto no link públicoDias 4 a 7Engenheiro de QA · Equipe
Teste a versão candidata nos aparelhos e versões de sistema suportados, incluindo a atualização a partir da versão que está no ar.
Checklist
- Testada no sistema mais antigo suportado
- Atualização a partir da versão no ar testada
- Regras das lojas conferidas
- Nenhum travamento ao abrir
Campos a preencher
- Link para o relatório de testes (obrigatório)
- Problemas conhecidos
- 5
Escrever as notas da versão para as lojas
Dia 7Redator de notas para as lojas · Agente de IA
O redator de notas para as lojas escreve as notas da versão para as duas lojas a partir das funcionalidades que o cliente quer destacar e dos problemas conhecidos, dentro dos limites de tamanho das suas instruções.
Campos a preencher
- Rascunho das notas da versão (obrigatório)
Revisão humana: O líder de engenharia corrige as notas e aprova a versão na etapa 6.
- 6
Aprovar a versão para envio
Dia 8Líder de engenharia · Equipe
Leia o relatório de testes e os problemas conhecidos, corrija as notas da versão, aprove a versão e mande as notas finais ao cliente por e-mail.
Checklist
- Relatório de testes lido
- Notas da versão corrigidas
- O número do build bate com a versão testada
Aprovação: A aprovação do cliente e o envio às lojas ficam travados até o líder de engenharia aprovar a versão.
- 7
O cliente aprova as notas e a data
Dias 8 a 9Product owner do cliente · Link público
O cliente lê as notas da versão que o líder de engenharia enviou e registra pelo link público a decisão e a data em que a versão pode ir ao ar.
Campos a preencher
- Decisão (obrigatório)
- Publicar em (obrigatório)
- Mudanças no texto
- 8
Enviar para a revisão das lojas
Dia 9Desenvolvedor mobile · Equipe
Envie a versão aprovada e as notas para as duas lojas, configure a publicação como manual ou gradual e registre a data de envio.
Checklist
- Enviada à App Store
- Enviada ao Google Play
- Publicação configurada como manual ou gradual
Campos a preencher
- Enviada em (obrigatório)
- 9
Tratar o resultado da revisão
Dias 9 a 12Desenvolvedor mobile · Equipe
Registre o resultado de cada revisão. Se uma loja rejeitar a versão, marque a execução como bloqueada, anote o motivo e envie de novo depois da correção.
Campos a preencher
- Resultado da revisão na App Store (obrigatório)
- Resultado da revisão no Google Play (obrigatório)
- Motivo da rejeição
- 10
Publicar e conferir se a versão está no ar
Semana 2Gerente de projeto · Equipe
Publique a versão na data combinada, confira se ela instala pelas duas lojas e avise o cliente.
Checklist
- No ar nas duas lojas
- Instala e abre pela loja
- Relatórios de travamento conferidos após a publicação
- Cliente avisado
Campos a preencher
- No ar desde (obrigatório)
Termina quando
A versão está no ar nas duas lojas, nas contas de desenvolvedor do próprio cliente, e a publicação fica registrada na execução.
Deixe do seu jeito. Renomeie etapas, troque responsáveis e adicione itens de checklist, campos ou aprovações. O modelo é um ponto de partida para o jeito de trabalhar da sua equipe.
Os agentes de IA deste modelo
Um agente só trabalha nas próprias etapas, e alguém da sua equipe confere o que ele fez. Tudo o que um agente grava em um app conectado aguarda aprovação, a menos que você permita.
Redator de notas para as lojas
Escreve as notas da versão para as duas lojas a partir do que mudou nesta versão.
O que ele faz
- Lê as funcionalidades que o cliente quer destacar e os problemas conhecidos
- Escreve notas da versão curtas para os usuários
- Respeita os limites de tamanho das suas instruções
- Conclui a sua etapa para o líder de engenharia revisar
Revisão humana: O líder de engenharia corrige as notas e aprova a versão na etapa 6.
Perguntas que este modelo responde
Publique nas contas de desenvolvedor do próprio cliente, com a sua equipe convidada, e envie só uma versão testada e aprovada. Na etapa 2 o cliente convida a equipe e responde às perguntas de privacidade pelo link público, e na etapa 8 o desenvolvedor mobile envia a versão aprovada.
Na do cliente, para ele manter o app, as avaliações e os usuários se um dia vocês encerrarem a parceria. A etapa 2 pede ao cliente para confirmar as próprias contas e convidar a sua equipe antes de a primeira versão para publicação ser gerada.
Teste no sistema operacional mais antigo que você suporta, teste a atualização a partir da versão no ar e confira as regras das lojas que causam rejeição. A etapa 4 traz essa checklist para o engenheiro de QA, com um link para o relatório de testes.
Anote o motivo, corrija e envie de novo, e avise o cliente em vez de deixar a data escorregar em silêncio. Na etapa 9 o desenvolvedor mobile marca a execução como bloqueada com o motivo da rejeição até a versão corrigida ser reenviada.
Deixe a IA escrever as notas da versão para as duas lojas a partir do que mudou, e mantenha a aprovação da versão com a sua equipe. O redator de notas para as lojas escreve o texto na etapa 5, e a etapa 6 é um controle de aprovação em que o líder de engenharia o corrige e aprova a versão.
Envie com antecedência, configure a publicação como manual ou gradual, e publique na data combinada com o cliente. Na etapa 7 o cliente define a data, na etapa 8 o desenvolvedor mobile envia com publicação manual ou gradual, e na etapa 10 a versão vai ao ar.
Execute este fluxo no OKiDO
Configure as etapas, os responsáveis e as aprovações uma vez e depois inicie uma execução para cada caso novo.