Como escrever o caderno de encargos de uma aplicação móvel em 2027

O que é o caderno de encargos de uma app e em que difere do briefing

O caderno de encargos é o documento onde fica escrito o que a aplicação tem de saber fazer e como vai perceber que está pronta. Lê-o toda a gente ao mesmo tempo: o próprio, o designer e o programador. Se os três entenderem o texto da mesma maneira, desaparece a maior fonte de discussões nos projetos: «eu pensava que isso estava incluído».

Não confunda três documentos. O briefing responde a «porquê» e «para quem»: objetivo, público, mercado, orçamento. O caderno de encargos responde a «o que, em concreto, tem de funcionar»: ecrãs, ações, regras, dados. O orçamento responde a «quanto e quando» e surge já a partir do caderno de encargos. Para um site, explicámos o briefing no artigo «Briefing e caderno de requisitos de um site»; numa aplicação há mais requisitos: telemóvel, lojas de aplicações, notificações, funcionamento sem internet.

A boa notícia: não precisa de escrever 80 páginas como um engenheiro. Bastam 3–6 páginas em texto simples, seguindo o modelo abaixo. O fornecedor completa os detalhes técnicos, mas não pode adivinhar por si o que o seu negócio precisa.

Há ainda outra vantagem: o documento permite obter propostas comparáveis. Quando cinco estúdios orçamentam o mesmo texto, os preços podem pôr-se lado a lado com justiça. Quando cada um orçamenta a sua versão da ideia, não há nada para comparar.

Modelo de caderno de encargos para app: 10 secções

Copie esta lista para um documento e preencha cada ponto, nem que seja com uma ou duas frases. Uma secção vazia é uma pergunta que vai ter de resolver na mesma, só que mais tarde e mais cara.

1. Objetivo e resultado mensurável. Uma frase: «os clientes marcam sozinhos e 30 % das marcações chegam pela app». Sem número também serve, mas então escreva pelo que vai reconhecer o sucesso.
2. Utilizadores e perfis. Quem usa: cliente, profissional, administrador, estafeta. Cada perfil tem os seus ecrãs e permissões.
3. Plataformas. iOS, Android ou ambas; se é preciso tablet; se chega um site que se instala no telemóvel como app (PWA) ou se são necessárias as lojas de aplicações. Se tem dúvidas, compare primeiro a aplicação, o site e a PWA em custo e em tarefas.
4. Mapa de ecrãs. A lista de todos os ecrãs e as setas entre eles: entrada, ecrã principal, catálogo, ficha, carrinho, perfil. Pode desenhar à mão e fotografar.
5. Cenários. Passo a passo, o que a pessoa faz: «abriu, escolheu o serviço, escolheu a hora, pagou, recebeu o lembrete».
6. Funcionalidades com prioridades. Três colunas: «sem isto não se lança», «era bom ter», «mais tarde». É a secção mais importante para o orçamento.
7. Dados e ligações. Onde ficam guardados os utilizadores e as encomendas, com que sistemas nos ligamos: pagamento, CRM, contabilidade, mapas, e-mail, aplicações de mensagens.
8. Requisitos não funcionais. Rapidez, funcionamento sem internet, idiomas, segurança, acessibilidade (mais abaixo).
9. Publicação e contas. Em nome de quem se abrem as contas de programador, quem escreve a descrição para as lojas, que países.
10. Aceitação e fases. Como verificamos o resultado, quantas rondas de correções, como se divide o pagamento por fases.

A cada ponto vale a pena juntar exemplos de aplicações de que gosta e uma linha sobre o que, em concreto, lhe agrada. «Quero como a Uber» não diz nada; «quero que o mapa com pontos fique como o da Uber e que o registo seja por número de telemóvel» diz tudo.

Requisitos de uma aplicação móvel: funcionais e não funcionais

Num documento de requisitos (em inglês, app requirements document) há normalmente dois tipos de registos. Os funcionais descrevem o que a aplicação faz: «o utilizador pode alterar a marcação até 2 horas antes». Os não funcionais descrevem com que qualidade o faz: depressa, em segurança, de forma clara, nos idiomas certos. São estes últimos que mais vezes se esquecem, e depois discute-se.

Exemplo para uma app de marcações num salão

Perfil «cliente». Registo por número de telemóvel com código por SMS. Catálogo de serviços com preço e duração. Escolha do profissional e de uma hora livre. Pré-pagamento com cartão. Lembrete com um dia e com 2 horas de antecedência. Cancelamento gratuito até 24 horas antes. Perfil «administrador»: agenda dos profissionais, lista de marcações, reembolsos, envio de promoções.

Esta é a parte funcional. Juntamos-lhe a parte não funcional:

• Rapidez. O ecrã principal abre sem atraso percetível num telemóvel médio com cinco anos.
• Ligação. O que vê o cliente sem internet: a última marcação ou uma mensagem de erro? Um modo offline completo custa dinheiro à parte.
• Idiomas e moedas. Quantos idiomas na interface, em que moeda os preços, como aparecem as datas.
• Segurança e dados. Que dados pessoais se guardam, quem os vê, como a pessoa elimina a sua conta. Se trabalha no seu país, confirme os requisitos de proteção de dados pessoais com um advogado: na UE aplica-se o RGPD.
• Acessibilidade. Letra grande, contraste, descrições para leitores de ecrã. É conforto e é também exigência de alguns mercados.
• Dispositivos. A partir de que versão de iOS e Android damos suporte e em que ecrãs testamos.

Não se esqueça da parte «invisível»: a maioria das aplicações tem um painel de administração onde a equipa gere conteúdos e encomendas. No caderno de encargos escreve-se numa secção própria; senão, acontece que a app está pronta e não há como geri-la.

O que registar sobre App Store e Google Play no caderno de encargos

A publicação é uma fase à parte, com regras próprias, e não depende só de nós. Por isso convém registar alguns pontos logo no início.

• Contas de programador. A Apple cobra $99 por ano, a Google Play $25 uma só vez. Publicamos a aplicação na sua conta, por isso registe quem a abre e quem guarda os acessos.
• Versão pronta para revisão. Segundo as regras da Apple (secção 2.1, «integridade da aplicação»), para revisão envia-se uma versão acabada: sem espaços reservados nem páginas provisórias, com ligações a funcionar e, se existir início de sessão, com um acesso de demonstração para o revisor; a parte de servidor tem de estar a funcionar nesse momento. No caderno de encargos isto passa a ser um ponto de aceitação: «conta de teste e descrição para o revisor prontas».
• Testes para a Google Play. Para contas pessoais novas de programador, a Google exige um teste fechado: pelo menos 12 testadores ligados durante 14 dias seguidos, e só depois abre a publicação para todos. Reserve estas duas semanas no prazo ou abra uma conta de empresa; consulte as condições atuais na ajuda da Google Play.
• Textos e imagens para as lojas. Descrição, capturas de ecrã, política de privacidade, classificação etária. Quem os escreve e em que idiomas.
• Pagamentos. Se a aplicação vende bens digitais ou subscrições, as lojas têm regras e comissões próprias. Para bens físicos e serviços as regras são outras. Registe o que vende e o fornecedor indica o esquema adequado.

Os prazos de revisão das lojas não dependem de nós, por isso nunca prometemos uma data exata de aparecimento na loja. Mais sobre os passos da publicação no artigo como criar uma app móvel: da ideia à App Store.

Cinco erros no caderno de encargos que aumentam prazos e preço

1. Sem prioridades. Quando tudo é «muito necessário», o orçamento inclui tudo e a primeira versão lança-se daqui a meio ano em vez de dois meses. Divida as funcionalidades em «obrigatório», «era bom ter» e «mais tarde».
2. Sem critérios de aceitação. «Bonito e prático» não se verifica. «A marcação cria-se em no máximo quatro toques» verifica-se.
3. Painel de administração e perfis esquecidos. A aplicação para o cliente é metade do produto. A outra metade é a ferramenta da sua equipa.
4. Integrações vagas. «Ligar ao CRM» são volumes de trabalho diferentes para sistemas diferentes. Indique o sistema e descreva que dados vão para onde.
5. Sem responsável. Se as decisões do seu lado são tomadas por três pessoas, o projeto trava nas aprovações. Nomeie uma pessoa que diz «sim» ou «não».

Outra armadilha frequente é escrever o caderno para o «produto ideal» já acabado. É melhor descrever a primeira versão, que testa a ideia com pessoas reais, e numa lista à parte tudo o que acrescentará se funcionar. Como é essa primeira versão e quanto custa explica o artigo MVP: o que é e quanto custa lançá-lo.

Verifique se o caderno de encargos está pronto para orçamento

Responda à lista de verificação abaixo. Mostra se pode enviar o documento aos fornecedores ou se convém fechar primeiro as lacunas. Se responder «não» à maioria dos pontos, não tem mal: parte das perguntas pode resolver-se com o fornecedor, e estamos disponíveis para isso. E se ainda não tem a certeza da própria ideia, comece pelo quiz de preparação.

Quem deve escrever o caderno de encargos: o próprio, o fornecedor ou em conjunto

Há três cenários que funcionam, e a escolha depende da clareza da sua ideia.

• Escreve o próprio, pelo modelo. Serve quando a ideia é simples e conhece o seu público. Recebe várias estimativas e compara-as.
• O fornecedor escreve a partir do seu briefing. É cómodo, mas lembre-se: quanto mais detalhado o documento, mais exato o orçamento. Um caderno gratuito muitas vezes acaba por ser um «caderno à medida do nosso preço», por isso pergunte a quem pertence se escolher outra equipa.
• Trabalho prévio pago. Para produtos complexos (perfis, pagamentos, vários sistemas) fazemo-lo como fase separada: a sessão de arquitetura por €3 500. À saída ficam o mapa do produto, o orçamento e o plano da primeira versão. O valor abate-se ao projeto, e o mapa fica consigo em qualquer caso, mesmo que depois escolha outra equipa.

Se precisa de ecrãs e não só de texto, junte design e protótipo, desde €1 990: um protótipo clicável no telemóvel explica a ideia melhor do que dez páginas de descrição. Nos pacotes prontos de aplicação o design já está incluído.

Como escolher a quem confiar o documento e o próprio projeto explica o artigo como escolher uma agência web sem se enganar: as mesmas perguntas servem para quem desenvolve aplicações. E quanto custa a aplicação em si pode ver em quanto custa criar uma app.

O que escolher na sua situação

• A ideia é simples: um cenário, um perfil. Preencha o modelo sozinho, envie a duas ou três equipas e compare as respostas. Uma aplicação para iOS e Android custa desde €10 900; o valor exato calcula-se no orçamento depois do caderno de encargos.
• Há vários perfis, pagamento, integrações. Não escreva tudo às cegas: comece pela sessão de arquitetura e receba o caderno sob a forma de mapa do produto e orçamento.
• Não tem a certeza de que precisa mesmo de uma app. Talvez chegue um site no telemóvel ou uma aplicação no Telegram. Compare as opções e o custo antes de escrever o documento.
• Já tem um caderno de outro estúdio. Mostre-o a nós e a outros fornecedores: um documento, várias propostas. Como comparar as respostas com justiça explica o artigo como comparar orçamentos e propostas de fornecedores.
• Precisa de arrancar o mais depressa possível. Descreva só as funcionalidades obrigatórias e deixe o resto para a segunda versão.

Não sabe por onde começar? Faça o quiz «Está pronto para desenvolver o seu produto?»: 17 perguntas, uma análise personalizada e um desconto no desenvolvimento, com um código promocional que lhe chega por e-mail (exceto no «Site em 24 horas»). Mostra as lacunas da ideia e ajuda a escolher o formato de arranque na sua cidade ou à distância.