--- title: "Caderno de encargos de software para orçamentos comparáveis" description: "O que pôr num caderno de encargos de software para ter orçamentos precisos: problema, utilizadores, sistemas, dados, orçamento, o que deixar em aberto, erros." canonical: https://sdk.enterprises/pt/insights/writing-a-software-project-brief language: pt --- # Caderno de encargos de software para orçamentos comparáveis Atualizado a: 2026-09-26 > Um bom caderno de encargos de software descreve o problema, os utilizadores, os sistemas envolvidos e como é o sucesso, e deixa a solução em aberto para os parceiros a proporem. Envie a todos os parceiros o mesmo documento, com um intervalo de orçamento e uma lista clara do que é fixo, e as propostas recebidas serão suficientemente precisas para se poderem comparar. ## Um caderno de encargos serve para tornar as respostas comparáveis Um caderno de encargos tem uma única função: permitir que vários parceiros compreendam o problema o suficiente para propor uma forma de o resolver, com uma estimativa fiável. Se cada parceiro preencher as lacunas com os seus próprios pressupostos, as propostas diferem no âmbito e não na qualidade, e a mais barata é muitas vezes a que pressupôs menos. Por isso, o documento deve ser preciso quanto ao problema e modesto quanto à solução. Descreva o que tem de ser verdade quando o projeto estiver concluído e deixe os parceiros explicar como lá chegariam. As respostas a essa parte em aberto são o que de mais útil vai ler. ## Começar pelo problema de negócio e por como se vai avaliar o sucesso Comece pela razão de ser do projeto: o que não funciona hoje, quem é afetado e quanto custa deixar tudo como está. Dizer que a equipa de operações volta a escrever no ERP cada encomenda recebida por e-mail diz muito mais a um parceiro do que pedir um portal de gestão de encomendas. Depois, diga como vai avaliar o sucesso. Escolha alguns resultados observáveis, como o tempo poupado por encomenda, os erros que deixam de chegar aos clientes ou uma data a partir da qual um sistema antigo pode ser desligado. Estes critérios tornam-se mais tarde os critérios de aceitação das etapas, por isso escreva-os em termos que alguém possa verificar. ## Descrever utilizadores, sistemas e dados antes das funcionalidades O trabalho de integração e de dados é fácil de subestimar quando um parceiro não o consegue ver. Antes de enumerar funcionalidades, descreva quem vai usar o software, com que sistemas tem de funcionar e que dados trata. As lacunas nesta parte regressam mais tarde sob a forma de pedidos de alteração. - Utilizadores: quem são, quantos são aproximadamente, e onde e em que dispositivos trabalham. - Sistemas existentes: quais são, a quem pertencem, e se oferecem uma API documentada ou apenas uma base de dados e exportações de ficheiros. - Dados: o que é pessoal, confidencial ou regulado, onde está hoje e quanto tem de ser migrado. - Operação: quem vai operar o software depois do lançamento, e que regras de alojamento ou de cloud a empresa já tem. - Restrições: idiomas, requisitos de acessibilidade, normas de segurança e qualquer prazo que não possa mudar, com a respetiva razão. ## Partilhar um intervalo de orçamento e o prazo que realmente importa Muitos compradores guardam o orçamento para ver o que os parceiros propõem. O resultado são propostas para projetos diferentes: um parceiro desenha para o mínimo, outro para tudo o que foi mencionado. Um intervalo, mesmo largo, permite a cada parceiro propor o melhor projeto que nele cabe e dizer com franqueza se não cabe. Faça o mesmo com o tempo. Diga que data é fixa e porquê, como um contrato que termina ou um prazo regulamentar, e que datas são apenas preferências. Um parceiro só consegue planear em função de uma data inegociável se souber qual é. ## Assinalar o que é fixo e deixar o resto em aberto Classifique cada requisito como fixo, preferido ou em aberto. Fixo significa que uma proposta não é válida sem ele, como o alojamento na UE ou o início de sessão através do fornecedor de identidade que a empresa já usa. Preferido significa que há uma razão, mas que uma alternativa seria considerada. Em aberto significa que se pretende a recomendação do parceiro. Deixe a tecnologia em aberto, a menos que haja uma razão real para a fixar, como uma equipa interna que vai manter o código ou uma plataforma que a empresa adotou como padrão. Quando fixar uma escolha, explique porquê, para que os parceiros não gastem a proposta a argumentar contra ela. Por fim, peça a todos os parceiros que respondam com a mesma estrutura: a sua compreensão do problema, a abordagem, as fases e etapas, os pressupostos, os riscos, a equipa e o modelo comercial. Uma estrutura comum é o que torna as propostas comparáveis na prática. ## Erros que tornam as propostas impossíveis de comparar Muitas propostas inutilizáveis são respostas a um caderno de encargos que as convidou. Elimine estes padrões antes de enviar o seu. - Uma lista de funcionalidades sem definição do problema, pelo que cada parceiro adivinha as prioridades. - Uma especificação longa que fixa a solução antes de alguém ter analisado o problema. - Nenhuma referência aos sistemas existentes nem à migração de dados, que depois voltam como pedidos de alteração. - Detalhes adicionais dados a alguns parceiros em chamadas, pelo que as suas propostas respondem a perguntas diferentes. - Palavras como «simples», «padrão» ou «como uma app conhecida», que significam coisas diferentes para cada leitor. - Nenhum prazo para perguntas, ou respostas partilhadas apenas com o parceiro que perguntou. ## Abrir espaço a perguntas e lê-las como parte da avaliação Dê aos parceiros um período definido para colocarem perguntas, responda por escrito e envie cada resposta a todos eles. As perguntas, por si só, dizem alguma coisa: um parceiro que pergunta pelos dados, pelos utilizadores e pelos critérios de aceitação já está a pensar na entrega. Se o problema ainda for demasiado incerto para ser bem descrito, diga-o e peça uma fase de descoberta curta e paga em vez de uma proposta completa. Um orçamento fechado construído sobre suposições esconde as incógnitas na sua margem de risco; uma fase de descoberta substitui as suposições por factos. Se quiser que engenheiros leiam o seu caderno de encargos, ou lhe respondam, pode enviá-lo através do nosso formulário Iniciar um projeto. ## Pontos essenciais - Descrever o problema, os utilizadores e como é o sucesso, e deixar a solução em aberto. - O trabalho de integração e de dados é fácil de subestimar, por isso enumere todos os sistemas e conjuntos de dados envolvidos. - Partilhar um intervalo de orçamento e dizer que prazo é fixo e porquê. - Classificar cada requisito como fixo, preferido ou em aberto, e pedir propostas numa estrutura comum. - Responder às perguntas por escrito e partilhar cada resposta com todos os parceiros. ## Perguntas frequentes ### Que extensão deve ter um caderno de encargos de software? A suficiente para cobrir o problema, os utilizadores, os sistemas, os dados, as restrições, o intervalo de orçamento e o calendário, o que na maioria dos projetos cabe em poucas páginas. Se ficar muito mais longo, provavelmente está a descrever a solução e não o problema. ### Devo partilhar o orçamento com os parceiros de software? Sim, sob a forma de intervalo. Sem ele, os parceiros propõem projetos de dimensões muito diferentes e não é possível compará-los. Um intervalo permite a cada parceiro mostrar o que faria dentro dele e dizer com honestidade se não chega. ### Devo pedir um preço fixo em resposta a um caderno de encargos? Só se o documento descrever o trabalho com detalhe suficiente para o estimar. Se houver questões essenciais ainda em aberto, peça uma fase de descoberta a preço fixo ou uma estimativa em intervalo com os pressupostos explícitos, e fixe o preço da construção quando as incógnitas estiverem resolvidas. ## Comece pela sua necessidade - [Criação de websites](https://sdk.enterprises/pt/website-development) ## Serviços relacionados - [Software à medida](https://sdk.enterprises/pt/services/product-engineering) - [Auditoria técnica e consultoria](https://sdk.enterprises/pt/services/consulting) ## Para saber mais - [Fase de descoberta paga: o que deve entregar num projeto](https://sdk.enterprises/pt/insights/what-a-paid-discovery-phase-should-deliver) - [Preço fixo ou tempo e materiais: que contrato escolher?](https://sdk.enterprises/pt/insights/fixed-price-or-time-and-materials)