Uma proposta de desenvolvimento de software deve explicitar, no mínimo: escopo e exclusões, entregáveis, composição e dedicação da equipe, marcos e prazos, critérios de aceite, responsabilidades das partes, titularidade do código e dos acessos, suporte pós-entrega e tratamento de mudanças. A ausência de qualquer um desses itens não é detalhe de redação — é risco transferido para quem assina.
Os dez itens mínimos
- Escopo — funcionalidades e limites, enumeráveis e verificáveis.
- Exclusões — o que NÃO está incluído, por escrito. É a cláusula que mais evita conflito.
- Entregáveis — o que muda de mãos: código, ambientes, documentação, manuais, artefatos de design.
- Equipe e dedicação — papéis, senioridade e horas semanais alocadas ao projeto.
- Marcos e prazos — entregas intermediárias datadas, não só a data final.
- Critérios de aceite — a régua objetiva que declara uma entrega pronta.
- Responsabilidades das partes — o que o contratante deve fornecer e decidir, e em que prazo.
- Titularidade — código, repositório, nuvem, domínios e credenciais em nome do contratante.
- Suporte pós-entrega — o que é garantia (correção sem custo) e o que é evolução (cobrada), e por quanto tempo.
- Tratamento de mudanças — como um pedido novo entra no escopo, quem aprova e como o preço se ajusta.
O que a ausência de cada item custa
Sem exclusões, todo desacordo de expectativa vira negociação com o projeto andando. Sem critérios de aceite, “pronto” é opinião. Sem dedicação declarada, a equipe do kick-off pode não ser a equipe do terceiro mês. Sem titularidade explícita, a relação comercial vira dependência técnica. Sem tratamento de mudanças, cada pedido novo é um conflito em potencial — ou um custo invisível já embutido no preço.
Uma proposta com os dez itens não garante um bom projeto. Garante algo anterior: que as duas partes concordaram sobre a mesma coisa antes de o dinheiro mudar de mãos.
Recebeu uma proposta e quer avaliar os riscos antes de contratar? Solicite uma análise gratuita por um CTO.