Plano de lançamento de aplicativo móvel

O que o modelo contém

Publicar um aplicativo não é subir software para um servidor. Outra pessoa decide quando a sua build entra no ar, e o plano precisa mostrar isso. O modelo separa o trabalho que você controla da espera que você não controla:

• Estabilização da build, Congelamento de escopo, triagem de travamentos e ANRs, trabalho de desempenho e memória, testes de acessibilidade e de matriz de aparelhos, e a build candidata a versão. Marco: candidata a versão pronta.
• Testes beta, Envio ao TestFlight e à faixa interna do Google Play, beta interno, recrutamento de testadores externos, a rodada externa e a triagem dos retornos. Marco: critérios de saída do beta atendidos.
• Ficha da loja e materiais, Pesquisa de palavras-chave e categoria, nome e descrição do app, capturas de tela e vídeo de prévia, ícone e artes, a declaração de privacidade dos dados e o questionário de classificação indicativa.
• Envio e revisão nas lojas, Checagem de conformidade antes do envio, submissão nas duas lojas, a espera da revisão e uma folga real para uma reprovação e novo envio. Marco: aprovado e pronto para publicar.
• Lançamento gradual, Publicação escalonada em 1%, 10% e 50%, com a taxa de sessões sem travamento verificada em cada degrau antes de ampliar para todos. Marco: disponibilidade total.
• Correção do dia um e monitoramento, Monitoramento de travamentos e ANRs, a janela de correção reservada, resposta às avaliações na loja e a leitura de retenção da primeira semana.

Como adaptar

1. Fixe a data de submissão e trabalhe para frente, não para trás, a duração da revisão não é sua para comprimir.
2. Separe as linhas de envio e revisão por loja se as suas builds de iOS e Android têm cadências diferentes; as durações de revisão são distintas.
3. Estenda a folga de reprovação se esta é a primeira submissão, se o app tem assinatura, ou se ele toca exclusão de conta, dados de saúde ou conteúdo gerado por usuário.
4. Ajuste os percentuais do lançamento gradual à plataforma; o lançamento escalonado do Google Play e o lançamento em fases da App Store não avançam do mesmo jeito.
5. Mantenha a janela de correção do dia um no gráfico com gente nomeada nela, uma janela sem equipe alocada é só uma semana vazia.
6. Marque candidata a versão, saída do beta, aprovação na loja e disponibilidade total como marcos; são as quatro datas que todo mundo pergunta.

Dicas de cronograma

• Prepare os metadados da ficha antes de a build estar final. Capturas de tela, descrições e declaração de privacidade podem ser feitas e revisadas em paralelo, e nunca deveriam ser o que segura o dia do envio.
• Não anuncie data de lançamento presa a uma aprovação que você ainda não tem. Faça o marketing depender do marco de aprovação, para que uma reprovação desloque a campanha automaticamente em vez de constranger você.
• Acompanhe a taxa de sessões sem travamento em cada degrau. O sentido de um lançamento gradual é poder parar entre os degraus; se ninguém está escalado para olhar os números, o escalonamento não serve para nada.
• Reserve a janela de correção antes do lançamento, não depois. As pessoas que construiriam a correção do dia um são as mesmas que você alocaria à próxima sprint no dia do lançamento.
• Recrute testadores externos com semanas de antecedência. Conseguir um número útil de testadores em aparelhos reais leva mais tempo do que os times planejam, e um beta magro não encontra nada.
• Estabeleça a linha de base na candidata a versão. Tudo antes disso é estimativa; depois, o cronograma é basicamente fila dos outros e deve ser acompanhado como variação.

Modelos relacionados

• Modelo de cronograma para lançamento de produto
• Modelo de cronograma para projeto de software
• Plano de desenvolvimento de novo produto
• Ver todos os modelos de gráfico de Gantt

Este modelo está em português. Páginas relacionadas ainda não traduzidas abrem em inglês.

Perguntas frequentes