Pedido de proposta para uma aplicação móvel: caderno de encargos e seleção

Quando três propostas descrevem três produtos diferentes

Uma empresa pede propostas para uma aplicação de marcações. Um fornecedor inclui a aplicação do cliente, o calendário dos profissionais e a área de administração. Outro parte do princípio de que o sistema atual já resolve horários e pagamentos. Um terceiro concentra-se nos ecrãs móveis. Os documentos podem estar bem apresentados e, ainda assim, não permitir qualquer comparação séria.

É para resolver este problema que existe o pedido de proposta, muitas vezes chamado RFP, e o caderno de encargos. Numa consulta privada, o objetivo não é reproduzir a contratação pública. É dar a vários fornecedores a mesma base, perceber como cada um raciocina e impedir que pressupostos importantes fiquem escondidos até ao contrato.

Este processo faz sentido quando há vários decisores, a aplicação depende de sistemas da empresa ou se pretende comparar diferentes equipas. Se a ideia ainda está a ser explorada por uma pessoa e não existe uma primeira versão coerente, um resumo para estimar a aplicação e uma fase paga de definição podem ser mais úteis. Um documento comprido não elimina uma dúvida de produto.

O comprador define a necessidade; o fornecedor propõe a resposta

Há uma diferença importante entre definir o resultado e desenhar a solução. O documento interno de produto organiza o problema, os utilizadores e as prioridades. A especificação funcional e técnica descreve comportamentos, dados e critérios de aceitação com maior detalhe. O pedido de proposta pergunta a vários fornecedores como abordariam o trabalho e que provas sustentam essa abordagem.

Quando o cliente fixa antecipadamente a arquitetura, as ferramentas e cada pormenor dos ecrãs, pode estar a impedir o fornecedor de acrescentar o conhecimento pelo qual será contratado. Naturalmente, as condicionantes reais entram no caderno: integrações existentes, autenticação corporativa, localização dos dados, acessibilidade, dispositivos ou regras de segurança. Uma preferência técnica sem justificação deve permanecer uma preferência.

O modelo de PRD para aplicações móveis ajuda a alinhar a organização. A estrutura de especificação técnica é adequada quando os fluxos já estão mais definidos. O pedido de proposta pode anexar esses documentos, sem os repetir.

Uma consulta em duas fases evita respostas de catálogo

Responder com profundidade exige tempo de produto, design e engenharia. Se enviar um questionário extenso a muitas empresas, é provável que receba textos comerciais reutilizados.

Faça primeiro uma pré-seleção simples. Partilhe duas páginas com a atividade, o problema, os utilizadores, a janela de arranque e as principais condicionantes. Peça trabalhos relevantes, disponibilidade, possível composição da equipa, idioma de trabalho e eventuais incompatibilidades.

Avalie a proximidade do desafio, não apenas do setor. Para uma plataforma com vários prestadores, a experiência com funções, pagamentos, conflitos e moderação pode ser mais importante do que uma aplicação visualmente semelhante.

Depois, envie o caderno completo a uma lista curta. Todos devem receber os mesmos anexos, prazos, contacto e regras. As equipas que avançam sabem que a sua proposta será realmente considerada; o cliente consegue dedicar atenção à comparação.

O conteúdo essencial do caderno de encargos

O documento pode ser conciso, desde que esclareça os pontos onde as interpretações costumam divergir.

1. Enquadramento e motivo. O que faz a organização, como funciona hoje e por que razão a aplicação é necessária agora.
2. Utilizadores e percursos. Quem usa o produto e quais são as ações completas que têm de funcionar na primeira versão.
3. Resultado esperado. A mudança observável que provará a utilidade do lançamento.
4. Fronteira inicial. Capacidades obrigatórias, opções desejáveis e temas explicitamente adiados.
5. Sistemas e materiais existentes. Sítio, API, CRM, pagamentos, dados, conteúdos, marca, design e responsáveis internos.
6. Condições não negociáveis. Plataformas, países, idiomas, privacidade, acessibilidade, segurança, utilização sem rede ou dispositivos, quando forem relevantes.
7. Responsabilidades. O que será fornecido pelo cliente e quem assegura produto, UX, desenvolvimento, testes, publicação e suporte.
8. Continuidade. Repositórios, contas de cloud e lojas, ficheiros editáveis, documentação, componentes externos e transição.
9. Regras da consulta. Estrutura da resposta, perguntas, esclarecimentos, prazos, sessão de apresentação, critérios e decisão.

Uma função solta raramente chega. "Notificações" não esclarece o momento, a autorização, a ação esperada nem a exceção. "Lembrar o utilizador da marcação, permitir a alteração dentro do prazo e avisar a equipa quando a vaga fica livre" já descreve algo que pode ser discutido e testado.

Peça a mesma estrutura de resposta

As soluções podem ser diferentes; a localização da informação básica não deve ser. Solicite estes capítulos: compreensão do problema, primeira versão proposta, exclusões, pressupostos numerados, fases, equipa indicada, dependências do cliente, abordagem técnica, garantia de qualidade, publicação, riscos, propriedade, suporte e proposta comercial.

Numerar pressupostos poupa muitas discussões. Se mais tarde se confirmar que o CRM não aceita escrita, todos podem rever o pressuposto P-07. Sem essa referência, a alteração perde-se entre chamadas, mensagens e versões do documento.

Também vale a pena pedir a classificação de cada capacidade: incluída, opcional, dependente de esclarecimento ou desaconselhada. Uma equipa que explica por que não construiria uma função pode demonstrar mais maturidade do que outra que aceita tudo.

Defina a avaliação antes de conhecer o favorito

Os pesos são aprovados internamente antes da chegada das propostas. Caso contrário, torna-se demasiado fácil valorizar precisamente os pontos fortes da apresentação mais convincente.

Estes valores não são uma regra universal. Uma aplicação clínica pode aumentar o peso da segurança e das provas. Um piloto curto pode valorizar a disponibilidade e a capacidade de testar uma hipótese. A matriz deve refletir o risco do negócio, não criar uma aparência de exatidão.

Peça a duas pessoas que avaliem primeiro de forma independente. As diferenças de pontuação são mais úteis do que a média automática. Uma pessoa pode ter valorizado uma marca conhecida; outra pode ter reparado que a equipa de execução nunca foi identificada.

Os esclarecimentos devem manter a igualdade da consulta

As perguntas dos fornecedores mostram onde o caderno é ambíguo. Mantenha um registo comum e partilhe as respostas que alteram o âmbito, as dependências ou as condições. Se apenas uma empresa souber que a compra sem registo é obrigatória, as propostas deixam de ter a mesma base.

Não é necessário expor a ideia confidencial de um concorrente. Partilham-se factos do projeto. Quando um esclarecimento muda uma parte importante, dê tempo para corrigir o pressuposto e atualizar a resposta.

Uma sessão conjunta de apresentação pode reduzir dúvidas, mas as conclusões devem ficar escritas. Meses depois, ninguém se lembrará com segurança de qual detalhe surgiu no fim de uma videoconferência.

Troque a segunda apresentação por um exercício de trabalho

Com os finalistas, use um caso incómodo e próximo da realidade: o pagamento é aceite mas a reserva não aparece; dois operadores atribuem a última vaga; a ligação falha a meio; ou uma alteração administrativa tem de ser desfeita sem apagar o histórico.

Devem participar as pessoas previstas para o projeto. Uma apresentação comercial bem ensaiada não mostra como produto, design, engenharia e gestão pensam em conjunto. Observe a qualidade das perguntas, a atenção ao utilizador e à operação, e a forma como distinguem factos de suposições.

Nas referências, evite perguntar apenas se o cliente ficou satisfeito. Pergunte o que mudou depois da assinatura, como foram comunicados os problemas, se a equipa prometida se manteve e o que o cliente conseguia operar quando a relação terminou.

Antes de comparar a proposta comercial, normalize o âmbito

Transfira cada resposta para uma grelha comum: funções, plataformas, backend, área de administração, integrações, design, migração, analytics, testes, publicação nas lojas, documentação e suporte. Registe ao lado exclusões, opções e trabalho a cargo do cliente.

Uma incerteza bem formulada não é uma fraqueza. "Precisamos de analisar a API antes de confirmar a sincronização sem rede" é melhor do que uma garantia sobre um sistema desconhecido. Compare como cada fornecedor propõe reduzir a dúvida: prova técnica, oficina de percursos, amostra de dados ou decisão por etapas.

O guia sobre preço fechado e Time and Materials explica por que a forma do acordo depende da incerteza. O pedido de proposta deve revelá-la cedo, não escondê-la numa frase confiante.

Propriedade e transição não ficam para o fim

Pergunte quem controla os repositórios, contas Apple e Google, backend, base de dados, domínios, analytics, certificados e serviços externos. Defina ainda os elementos esperados em cada fase aceite: código, design editável, instruções de compilação, inventário de dependências, provas de teste e limitações conhecidas.

O manual da OMPI sobre contratos de aplicações distingue código novo, materiais anteriores do fornecedor, código aberto e componentes de terceiros. Podem existir direitos diferentes. O caderno não substitui aconselhamento jurídico, mas impede que esta questão surja apenas na última revisão do contrato.

A lista de documentação para a transição ajuda na aceitação técnica. A lista para o contrato de desenvolvimento reúne os assuntos a rever com apoio jurídico.

Modelo curto para começar

Use este índice: organização e motivo; utilizadores e percursos; resultado pretendido; primeira versão e exclusões; sistemas e dados atuais; responsabilidades; condicionantes; perguntas ao fornecedor; provas pedidas; esclarecimentos; formato da resposta; critérios e calendário.

Anexe apenas materiais com uma função clara: percurso principal, diagrama do sistema atual, amostra de dados, elementos de marca ou informação de utilização. Uma pasta cheia de ficheiros sem contexto não melhora o caderno; obriga cada fornecedor a ordenar novamente o problema.

Sinais de alerta numa resposta

Desconfie quando a proposta repete o pedido sem o esclarecer, aceita todas as funcionalidades sem discutir prioridades ou recomenda uma tecnologia sem a ligar às condições do projeto. Outros sinais são perfis experientes apenas na fase comercial, "testes incluídos" sem método, propriedade descrita sem contas e repositórios, e suporte deixado para um acordo indefinido.

Peça uma prova anonimizada: critério de aceitação, entrada de risco, lista de publicação ou índice de transição. Não interessa acumular documentos. Interessa perceber se o processo anunciado deixa informação que outra pessoa consegue usar.

Como a Appfyl responde a um bom pedido

Começamos por verificar se a primeira versão corresponde a um produto coerente. Relacionamos os percursos dos utilizadores com a operação na área de administração, integrações, situações difíceis e dependências do cliente. Só depois separamos o que entra, o que precisa de prova e o que deve ficar para uma fase posterior.

Quando ainda não existe documentação, o questionário da Appfyl recolhe funções e contexto livre. Para as conversas com fornecedores, combine este modelo com as perguntas para uma agência de aplicações.

Veja como a Appfyl transforma escopo em produtos lançados. Ver cases da Appfyl.

Perguntas frequentes