# Escopo fechado ou ágil: qual contrato de software escolher > Contrato de software com escopo fechado ou ágil? Veja o risco de cada modelo para cliente e fornecedor e quando cada um protege ou prejudica sua empresa. Fonte: https://pervian.tech/blog/escopo-fechado-ou-contrato-agil · Pervian Tech · publicado em 2026-10-01 A diretoria aprova o projeto com um valor fechado e uma data de entrega. Três meses depois, o time de vendas descobre que o fluxo de aprovação de desconto não foi previsto, o fornecedor responde que aquilo "está fora do escopo" e abre um aditivo. A discussão deixa de ser sobre o sistema e passa a ser sobre o que estava escrito no anexo do contrato. O caminho inverso também dá errado. A empresa contrata "por hora, no ágil", sem meta clara e sem acompanhamento. Os meses passam, as entregas são parciais, e ninguém sabe dizer quanto falta para o sistema entrar em produção. Nos dois casos, o problema raramente é a competência técnica. É a escolha de um modelo de contrato que não combina com o grau de incerteza do projeto. Este texto compara os três modelos mais comuns, escopo fechado, tempo e material e equipe dedicada, pelo risco que cada um coloca de cada lado da mesa. ## A resposta curta Escolha pelo quanto você já sabe sobre o que precisa ser construído: - **Escopo fechado** funciona quando o problema está bem definido, as regras de negócio estão escritas e a chance de mudança durante o projeto é baixa. Exemplo: uma integração entre dois sistemas com formatos de dados conhecidos e documentados. - **Tempo e material** funciona quando há incerteza relevante, mas existe um objetivo claro e alguém da empresa com tempo para priorizar. Exemplo: um sistema interno novo cujo fluxo ainda vai ser refinado com os usuários. - **Equipe dedicada** funciona quando o software é um produto que vai evoluir continuamente, sem data de fim. Exemplo: um portal de clientes ou um app que recebe melhorias todo mês. Quando um fornecedor fala em "contrato ágil", ele quase sempre se refere a um dos dois últimos formatos: paga-se pelo tempo da equipe e o escopo é priorizado ao longo do caminho, em vez de fixado no início. Ágil, aqui, é a forma de trabalhar; o que muda no contrato é quem paga pela incerteza. Na prática, os projetos que dão certo costumam combinar os modelos por fase. Mas antes de chegar lá, vale entender onde cada um protege e onde prejudica. ## Por que o modelo de contrato muda o projeto O contrato não é só um documento jurídico. Ele define **quem absorve o risco quando algo não sai como o previsto**, e isso muda o comportamento das duas partes. Todo projeto de software tem incerteza: regras que ninguém documentou, integrações que se comportam diferente do manual, usuários que só entendem o que precisam quando veem a primeira tela. A pergunta é quem paga por essa incerteza. - No **escopo fechado**, o fornecedor assume o risco de estimativa. Para se proteger, ele embute margem no preço e defende o escopo com rigor. - No **tempo e material**, o cliente assume o risco de estimativa. Em troca, ganha liberdade para mudar de rumo sem renegociar. - Na **equipe dedicada**, o cliente compra capacidade, não entregas. O risco passa a ser de gestão: se a capacidade não for bem direcionada, ela é desperdiçada. Nenhum modelo elimina a incerteza. Eles apenas decidem onde ela vai aparecer: no preço, no prazo ou no escopo. ## Escopo fechado: previsibilidade e rigidez No escopo fechado, as partes definem antes do início o que será entregue, em quanto tempo e por qual valor. É o modelo mais confortável para quem precisa aprovar orçamento: o número está na mesa desde o primeiro dia. ### Quando protege o cliente - O orçamento é fixo e não pode ser estourado, como em projetos com verba aprovada por conselho ou vinculada a um ciclo anual. - O escopo é pequeno, conhecido e estável: uma migração de dados, uma integração com regras claras, um módulo que replica um processo já documentado. - A empresa não tem ninguém disponível para acompanhar o projeto semana a semana e precisa de um resultado definido. ### Quando prejudica o cliente - **O escopo foi escrito antes de o problema ser entendido.** Tudo que não estava previsto vira aditivo, e a negociação de cada aditivo consome tempo e confiança. - **A margem de risco é paga mesmo que o risco não aconteça.** Um fornecedor sério precifica a incerteza; se o projeto correr bem, essa margem não volta. - **O incentivo é entregar o que está escrito, não o que resolve.** Se o requisito estava ambíguo, a interpretação mais barata de implementar tende a vencer. - **Mudanças de mercado ficam para depois.** Se no meio do projeto surgir uma exigência nova, ela entra numa fila de renegociação. Por isso, escopo fechado depende de um escopo bem feito. Se a empresa ainda não sabe exatamente o que precisa, o mais seguro é fazer antes uma etapa de [discovery de software](https://pervian.tech/blog/discovery-de-software), que levanta regras, integrações e riscos e transforma a dúvida em requisito escrito. ## Tempo e material: flexibilidade com controle No tempo e material, a empresa paga pelas horas efetivamente trabalhadas, com base num valor combinado por perfil profissional. O escopo existe, mas como direção, não como cláusula fechada. ### Quando protege o cliente - O produto vai ser descoberto em parte durante a construção, com usuários testando e pedindo ajustes. - Há integrações com sistemas pouco documentados, em que só a investigação revela o esforço real. - A empresa quer pagar apenas pelo que foi feito, sem margem de risco embutida. - As prioridades podem mudar: um concorrente lança algo, uma exigência fiscal muda, e o time precisa redirecionar o trabalho rapidamente. ### Quando prejudica o cliente - **Não há teto natural.** Sem um orçamento de referência e acompanhamento, o projeto pode crescer indefinidamente. - **Exige alguém do lado da empresa com poder de decisão.** Se ninguém prioriza, o fornecedor decide sozinho o que é importante, e nem sempre acerta. - **Dá margem a baixa eficiência sem que ninguém perceba.** Se as entregas não são visíveis, horas viram o único indicador, e hora trabalhada não é resultado. O controle vem de três instrumentos: um teto de horas por ciclo, que só é ultrapassado com aprovação; um backlog (a lista de tarefas pendentes, em ordem de prioridade) revisado com frequência; e entregas funcionando em intervalos curtos, que a empresa consegue testar. ## Equipe dedicada para produtos em evolução Na [equipe dedicada, também chamada de squad](https://pervian.tech/blog/alocacao-de-desenvolvedores-ou-squad), a empresa contrata um time fixo por um período, normalmente com desenvolvedores, alguém de qualidade e alguém de gestão técnica. Em vez de comprar um projeto, compra capacidade contínua. ### Quando protege o cliente - O software é parte do negócio e vai evoluir sem data de fim: um portal de clientes, uma plataforma de pedidos, um [app próprio](https://pervian.tech/blog/app-proprio-para-clientes). - O time acumula conhecimento sobre as regras da empresa, e esse conhecimento deixa de se perder a cada novo projeto. - A previsibilidade é mensal: o custo do time é conhecido, e o que varia é o que ele entrega. ### Quando prejudica o cliente - **O produto ainda não tem demanda contínua.** Pagar um time inteiro para um sistema que precisa de ajustes esporádicos é capacidade ociosa. - **Não existe um dono do produto na empresa.** Sem alguém que defina prioridades, o time trabalha no que parece útil, não no que traz resultado. - **O contrato não prevê como sair.** Se o modelo for encerrado, a empresa precisa garantir o código, a documentação e o ambiente. Esse ponto, que vale para qualquer modelo, está detalhado em [o que o contrato deve dizer sobre o código-fonte](https://pervian.tech/blog/propriedade-do-codigo-fonte-no-contrato). ## Comparação lado a lado | Critério | Escopo fechado | Tempo e material | Equipe dedicada | |---|---|---|---| | Quem assume o risco de estimativa | Fornecedor | Cliente | Cliente | | Previsibilidade de orçamento | Alta, se o escopo não mudar | Média, depende do teto por ciclo | Alta no custo mensal | | Flexibilidade para mudar | Baixa, via aditivo | Alta | Alta | | Esforço de acompanhamento da empresa | Baixo a médio | Alto | Alto | | Melhor para | Escopo pequeno e estável | Projeto novo com incerteza | Produto em evolução contínua | | Principal armadilha | Escopo mal definido | Falta de teto e de prioridade | Capacidade sem direção | ## Mudanças de escopo em cada modelo Mudança de escopo não é falha do projeto. É sinal de que a empresa está aprendendo sobre o próprio problema. O que importa é como o contrato trata essa mudança. **No escopo fechado**, toda mudança precisa de um processo formal: pedido por escrito, análise de impacto em prazo e valor, aprovação antes de iniciar. Sem isso, o fornecedor faz por boa vontade até um ponto, e depois a conta aparece de uma vez. Um bom contrato prevê esse fluxo e permite trocar um item por outro de tamanho parecido sem aditivo. **No tempo e material**, a mudança entra no backlog e disputa prioridade com o resto. O risco não é o aditivo, é a soma de pequenas mudanças que empurra a entrega principal para depois. A pergunta a fazer em cada mudança é: isso precisa estar na primeira versão? **Na equipe dedicada**, mudança é rotina. O cuidado é não deixar que urgências diárias consumam toda a capacidade e o produto pare de avançar nas entregas estruturais. Em qualquer modelo, um escopo inicial enxuto reduz o atrito. O raciocínio de separar o essencial do desejável está em [como definir o escopo de um MVP](https://pervian.tech/blog/como-definir-o-escopo-de-um-mvp). ## Como acompanhar entregas em qualquer modelo O modelo de contrato muda quem assume o risco, mas a forma de acompanhar é parecida. Estes são os pontos que um gestor deve exigir, independentemente do formato: 1. **Entregas funcionando em ciclos curtos.** A cada duas ou três semanas, algo que pode ser testado num ambiente de homologação, não apenas um relatório de progresso. 2. **Backlog visível.** Uma lista priorizada do que já foi feito, do que está em andamento e do que falta, acessível para a empresa. 3. **Critério de aceite escrito.** Cada funcionalidade tem uma descrição do que precisa acontecer para ser considerada pronta. 4. **Relatório de horas ou de capacidade ligado a entregas.** No tempo e material e na equipe dedicada, horas sem entrega correspondente são um sinal de alerta. 5. **Repositório e ambiente acessíveis desde o início.** A empresa deve conseguir ver o código e o histórico de mudanças, não só receber o resultado no fim. 6. **Registro de riscos.** O fornecedor deve informar cedo o que pode atrasar, em vez de [anunciar o atraso na véspera da entrega](https://pervian.tech/blog/projeto-de-software-atrasado). Se o fornecedor não aceita nenhum desses pontos, o problema não é o modelo de contrato. ## Modelos híbridos por fase Os projetos mais saudáveis raramente usam um único modelo do início ao fim. Uma combinação comum: - **Fase de discovery em escopo fechado.** Prazo curto, entregáveis claros: mapeamento de processos, protótipos, arquitetura, estimativa por fase. O risco é baixo dos dois lados. - **Construção da primeira versão em tempo e material com teto, ou em escopo fechado por fase.** Com o discovery feito, a incerteza cai, e as fases seguintes podem ser fechadas com muito mais segurança. - **Evolução em equipe dedicada ou em pacote de horas mensal.** Depois que o sistema está em produção, o trabalho vira melhoria contínua, e a capacidade fixa faz mais sentido do que projetos isolados. Esse desenho reduz o risco que mais pesa em cada momento. No começo, o maior risco é construir a coisa errada. No meio, é estourar prazo e orçamento. No fim, é deixar o sistema parado enquanto o negócio muda. ### Critérios para decidir o modelo de cada fase - O problema está documentado a ponto de outra empresa conseguir estimar sem fazer perguntas? Se sim, escopo fechado é viável. - Existe alguém na empresa com tempo e autoridade para priorizar toda semana? Se não, evite tempo e material sem teto. - O sistema vai receber melhorias contínuas depois de lançado? Se sim, planeje desde já a transição para uma equipe dedicada ou um pacote recorrente. - O orçamento é rígido ou pode ser liberado por etapas? Orçamento por etapa combina com contratos por fase. - A data de entrega é imposta por algo externo, como uma exigência legal ou o fim de um contrato com outro fornecedor? Nesse caso, o escopo precisa caber na data, não o contrário. ## Cláusulas que valem em qualquer modelo Algumas proteções independem do formato e devem estar no contrato desde o início: - Titularidade do código, do repositório e das contas de infraestrutura. - [Entregáveis de transição se o contrato terminar](https://pervian.tech/blog/trocar-de-fornecedor-de-software): documentação, acessos, instruções de implantação. - Processo de mudança de escopo, com prazo para análise e aprovação. - [Critério de aceite e prazo para homologação](https://pervian.tech/blog/teste-de-aceite-de-software) de cada entrega. - Garantia de correção de defeitos por um período após a entrega. - Confidencialidade e tratamento de dados pessoais conforme a LGPD, com o papel de cada parte definido. Este texto é escrito do ponto de vista técnico e não substitui a revisão do contrato pelo seu jurídico. ## Perguntas frequentes ### O que é contrato de tempo e material? Contrato de tempo e material é o modelo em que a empresa paga pelas horas efetivamente trabalhadas, com valor combinado por perfil profissional, e o escopo funciona como direção, não como cláusula fechada. Ele oferece flexibilidade para mudar de rumo, mas exige teto de horas por ciclo, backlog priorizado e entregas frequentes para manter o controle. ### Escopo fechado garante que o projeto não vai atrasar nem custar mais? Não. O escopo fechado transfere o risco de estimativa para o fornecedor, que embute margem no preço, mas tudo o que não estava previsto vira aditivo, com novo prazo e novo valor. Se o escopo foi escrito antes de o problema ser entendido, os aditivos tendem a se acumular e a consumir tempo e confiança. ### Dá para combinar escopo fechado e ágil no mesmo projeto? Sim, e costuma ser o arranjo mais saudável. Uma combinação comum é fazer o discovery em escopo fechado, construir a primeira versão em tempo e material com teto ou em escopo fechado por fase, e conduzir a evolução com equipe dedicada ou pacote de horas mensal, reduzindo o risco principal de cada momento. ### Como lidar com mudança de escopo no contrato de software? O contrato de software deve prever um processo de mudança de escopo, com pedido por escrito, análise de impacto em prazo e valor e aprovação antes de iniciar. Um bom contrato também permite trocar um item por outro de tamanho parecido sem aditivo. Em qualquer modelo, começar com um escopo enxuto reduz o atrito. ## Como a Pervian Tech trabalha contratos Na Pervian Tech, começamos por entender o grau de incerteza do projeto antes de propor qualquer modelo. Quando o problema ainda não está claro, sugerimos uma etapa de diagnóstico com entregáveis definidos; com ela feita, propomos o formato de cada fase, seja escopo fechado, tempo e material com teto ou equipe dedicada para a evolução. Esse desenho faz parte do nosso trabalho em [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software), e outros textos sobre o tema estão em [contratação de software](https://pervian.tech/blog/categoria/contratacao). Em qualquer modelo, a empresa acompanha entregas em ambiente de homologação, tem acesso ao repositório desde o primeiro dia e fica com o código. O diagnóstico inicial é gratuito, o plano é sob medida e o investimento é definido sob consulta. Se você está entre propostas com modelos diferentes e não sabe qual protege mais a sua empresa, [conte o seu cenário](https://pervian.tech/#contato).