Escopo fechado ou ágil: qual contrato de software escolher

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, 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, 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.
• 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.

Comparação lado a lado

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.

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.

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: 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 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, e outros textos sobre o tema estão em contratação de software.

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.