Desenvolvimento de aplicativo móvel: as sete fases do projeto

A Casaverde, uma rede de artigos para casa, aprovou o aplicativo em janeiro e contava com ele nas mãos dos clientes antes do Dia das Mães. O time de desenvolvimento entregou no prazo. O app não chegou a ser publicado: o banco de dados do programa de fidelidade nunca tinha sido exposto por uma API, ninguém tinha reservado o prazo de revisão das lojas e a campanha de lançamento estava escrita em cima de uma funcionalidade cortada na nona semana.

Nada dessa lista é problema de programação. Tudo ali é gerenciamento de projetos, e é assim que os projetos de aplicativo costumam fracassar: o software fica pronto e o projeto não termina.

Um projeto de desenvolvimento de aplicativo móvel vai de uma necessidade de usuário identificada até um produto publicado e mantido. Ele tem sete fases, e só em uma delas se escreve código.

Um aplicativo ganha no celular um lugar que a web nunca conquista

Antes de qualquer fase importar, o business case precisa sobreviver a uma pergunta: o que o aplicativo faz que um site móvel já não faça? A resposta é curta, e tem mais a ver com proximidade do que com funcionalidades.

O que o aplicativo traz	O que o site móvel não alcança
Presença na cabeça do cliente	Seu ícone mora na tela inicial, visto dezenas de vezes por dia, aberto ou não
Disponibilidade imediata	Um toque, sem navegador, sem busca, sem URL para lembrar
Um canal direto	Novidades, imagens e ofertas chegam ao cliente sem intermediário
Uma relação mais próxima	Contato nos dois sentidos e na hora, não um formulário respondido semana que vem
Conteúdo que circula	O compartilhamento nativo empurra o seu conteúdo para a roda social do próprio cliente
Visibilidade nas lojas	A App Store e o Google Play colocam você na frente de quem já procura na sua categoria
Notificações push	Ofertas, pesquisas e lembretes caem na tela de bloqueio. Abuse e você é desinstalado
Engajamento de verdade	Comportamento, localização e momento deixam você responder a um perfil em vez de a uma média

Cada uma dessas é um motivo para construir. Nenhuma delas é um plano.

Um aplicativo quase nunca é um projeto só

A Casaverde achava que estava comprando um aplicativo. O que ela contratou foram três projetos dividindo uma data de lançamento: o trabalho de desenvolvimento de negócio que transforma o novo canal em receita, o trabalho de integração que expõe os sistemas de fidelidade e de catálogo, e o desenvolvimento em si. Times diferentes, competências diferentes, patrocinadores diferentes.

Então o trabalho do gerente de projeto aqui não é montar cronograma para desenvolvedor. É mediar entre o patrocinador e o time, sustentar o ritmo de entrega contra uma data fixa e assumir o que acontece depois dela. O PMO ou o gerente de portfólio fica acima dos três, de olho em quais dependências de fora do projeto do app podem atrasá-lo. Um PMO diretivo faz mais do que olhar: ele move orçamento e pessoas do trabalho secundário para destravar a integração que está segurando a publicação.

No ITM Platform esse agrupamento é um programa. Projetos e serviços entram como componentes, um projeto pertence a um único programa por vez, e a seção Cronograma do programa reúne em um lugar só as dependências entre os projetos que o formam. O orçamento sobe do mesmo jeito, um orçamento do programa definido de cima para baixo ao lado dos orçamentos agregados dos seus componentes, de modo que o custo do aplicativo é o custo do programa inteiro e não só o do desenvolvimento. A configuração está em gerenciamento de programas.

O patrocinador costuma ser o líder de inovação ou o CIO, porque o aplicativo precisa responder ao plano estratégico antes de responder a um briefing de design.

As sete fases e o que cada uma deve à seguinte

Essas sete fases são um caso particular do ciclo de vida do projeto em geral. O que distingue o trabalho de aplicativo é que as fases 3 a 6 formam um ciclo, enquanto a 1, a 2 e a 7 acontecem uma vez só.

Fase	O que ela precisa produzir	Está pronta quando
1. Ideia	Um problema com nome que o app resolve, não uma lista de funcionalidades	Você sabe dizer qual tarefa do cliente se muda para o celular
2. Planejamento	Estudo de mercado, definição do MVP, cronograma, orçamento, business case	O business case sobrevive aos próprios números
3. Desenvolvimento	Pesquisa, wireframe, viabilidade técnica, código funcionando	Existe um protótipo que um estranho consegue operar
4. Protótipo	Uma versão tosca, mas navegável, do produto	Ela é realista o bastante para provocar retorno sincero
5. Testes	Sessões observadas com pessoas parecidas com os seus usuários reais	Você viu alguém errar, não só ouviu opiniões
6. Revisão e melhoria	Novas histórias de usuário e uma definição de pronto fixa	O backlog para de crescer mais rápido do que diminui
7. Lançamento e manutenção	Um app publicado mais um plano de atualização e suporte	A loja aprova e alguém assume a fila de bugs

A fase 3 concentra a maior parte do risco, então vale abri-la:

• Pesquisa. Descubra o que a concorrência já faz bem e o que o seu back end vai precisar suportar. É o último momento em que cortar escopo sai barato.
• Wireframe e documentação. Desenhe as telas e depois desenhe o caminho que o usuário faz entre elas. Um wireframe é um argumento de navegação, não um desenho.
• Viabilidade técnica. Confirme que o back end consegue servir a funcionalidade, identifique as APIs públicas das quais você depende e verifique o que cada plataforma e cada tamanho de tela exigem. Escolher iOS, Android ou os dois se decide aqui, não na fase da ideia.
• Desenvolvimento. Quebre o produto em histórias de usuário e distribua-as em ciclos de mais ou menos duas semanas, para que exista cedo um protótipo que dá para testar, e não só no final.

O desenvolvimento é onde uma data de lançamento fixa e uma construção iterativa precisam conviver, a mesma tensão que analisamos em vantagens e desvantagens das metodologias ágil e preditiva. No ITM Platform os sprints são habilitados projeto a projeto, na aba Geral, dentro de Linha do tempo, e não são exclusividade dos projetos ágeis: um projeto preditivo consegue ordenar e filtrar o cronograma por sprint, então o plano de lançamento e o ritmo de desenvolvimento são lidos em uma mesma lista de tarefas. As histórias que não estão prontas vão para o backlog, o que as desaloca do sprint em vez de deixá-las contadas dentro dele. Como ligar isso, por projeto ou por tipo de projeto, está em sprints.

A estimativa se esconde na taxa, não na lista de funcionalidades

O primeiro número que todo mundo pede é o total, e é o menos informativo de todos. O custo de desenvolvimento é produto do escopo pela taxa, e os dois se mexem.

Custo de desenvolvimento = Σ (esforço por funcionalidade em horas × taxa média por hora) + design + custo extra de plataforma e conformidade

A taxa média é onde as estimativas se perdem: a mesma funcionalidade é orçada de jeitos muito diferentes dependendo de quem escreve o código.

Quem desenvolve	Taxa por hora ilustrativa	O que você está comprando de verdade
Freelancer júnior	R$ 90,00	Horas baratas e uma supervisão que ninguém orçou
Agência especializada	R$ 240,00	Capacidade de entrega e um contrato que dá para cobrar
Desenvolvedor sênior CLT	R$ 360,00	Conhecimento que fica na casa depois do lançamento

O mesmo conjunto de funcionalidades, e de uma ponta à outra a nota fiscal se multiplica por quatro. A taxa do sênior contratado é a mais fácil de subestimar das três, porque a hora dele carrega encargos trabalhistas, férias e 13º salário, e não é o salário da folha dividido pelas horas do ano. Por isso “quanto custa um aplicativo” não tem resposta e “quantas horas, a que taxa e em quantas plataformas” tem. Publicar em iOS e em Android é quase dois desenvolvimentos, a menos que você se comprometa cedo com um framework multiplataforma, e essa decisão pertence ao passo de viabilidade, não a uma solicitação de mudança lá na frente.

Nos testes e no lançamento é onde os números costumam sumir

Testar não é fazer demo. Coloque o protótipo na frente de pessoas parecidas com os seus usuários reais, dê uma tarefa a elas e observe onde elas hesitam. As opiniões coletadas depois valem bem menos do que os três segundos que alguém passou caçando um botão que não estava lá.

O que volta dali vira novas histórias de usuário, e o ciclo de desenvolvimento, protótipo e teste roda de novo. O que impede esse ciclo de girar para sempre não é disciplina, é uma regra escrita:

Definição de pronto: uma história está terminada quando está codificada, revisada, testada em todas as plataformas alvo e aceita pelo product owner. Qualquer coisa abaixo disso volta para o backlog.

Depois vem o lançamento. A submissão à loja leva horas ou dias, dependendo de quão limpo o build atende às políticas de cada uma, então ela entra no cronograma como uma tarefa com risco associado, e não como um apêndice depois do último marco. E aí vem a parte que os planos omitem com toda a naturalidade: atualizações, novas funcionalidades e suporte para os defeitos que os testes não pegaram.

É aqui também que um projeto de aplicativo perde os números sem fazer barulho. O retorno de quem testa, as recusas da loja e os bugs reportados depois da publicação chegam como mensagens, são corrigidos e não deixam registro do que custaram. No ITM Platform isso é gestão de incidentes, e não um segundo backlog: um incidente é tipificado como Bug, Solicitação de mudança ou Problema, de modo que um defeito encontrado no teste e uma mudança de escopo pedida depois da demo não são arquivados como a mesma coisa, e fechá-lo registra uma variação no custo do projeto e uma variação de cronograma em dias. O painel soma o custo das mudanças vindas de incidentes fechados e o custo dos incidentes por tipo, que é o que transforma “tivemos muitos bugs” em um número com que estimar a próxima versão. Os tipos de incidente e os campos de resolução estão em gestão de riscos e incidentes.

Os projetos de aplicativo fracassam sempre nos mesmos três lugares: um business case que nunca virou plano, um desenvolvimento que era acompanhado enquanto as dependências dele não eram, e um lançamento sem dono na manhã seguinte. As sete fases não são a parte difícil. Difícil é mantê-las presas a tudo o mais de que o aplicativo depende.

Próximos passos

• Comece um teste gratuito do ITM Platform e monte o desenvolvimento do app e o trabalho de integração como componentes de um mesmo programa.
• Veja como o gerenciamento de programas e portfólio mantém visíveis as dependências entre projetos relacionados.
• Acerte primeiro o ritmo de entrega: os sprints funcionam tanto em cronogramas preditivos quanto em quadros ágeis.