Contrato de desenvolvimento: cláusulas que não podem faltar

Um contrato de desenvolvimento de software só cumpre a função se responder a seis perguntas: de quem é o que foi feito, o que exatamente será feito, quando o dinheiro sai, o que acontece se algo quebrar, o que acontece se algo mudar e como cada lado sai da relação. Contratos que ficam nas cláusulas genéricas de prestação de serviço deixam todas as seis em aberto, e é justamente nelas que os conflitos acontecem.

1. Propriedade intelectual e cessão de direitos

A cláusula mais importante e a mais frequentemente ausente. No Brasil, software é protegido por direito autoral, e os direitos patrimoniais ficam com quem desenvolveu, a menos que o contrato ceda expressamente.

O que precisa constar:

• Cessão total, definitiva e irrevogável dos direitos patrimoniais sobre o que for desenvolvido para o contratante, sem limite de prazo ou território.
• Entrega do código-fonte durante e ao final do projeto, com repositório em conta do contratante.
• Relação de componentes de terceiros utilizados e suas licenças, com declaração de que são compatíveis com o uso pretendido.
• Componentes reutilizáveis do fornecedor, se houver: nomeados, com licença de uso perpétua, irrevogável e sem custo adicional para o contratante.
• Titularidade dos dados e obrigação de devolvê-los em formato aberto quando solicitado.

2. Escopo anexado, não descrito no corpo

O contrato não deve tentar descrever o sistema em parágrafos. Deve anexar o documento de escopo aprovado e referenciá-lo.

O anexo precisa conter: módulos e funcionalidades nominais, perfis de acesso, integrações previstas, migração de dados (se houver) e, o item que evita mais discussão, a lista do que está fora do escopo.

Sem baseline anexado, a expressão "fora do escopo" não tem significado jurídico nem prático.

3. Cronograma e pagamento atrelados a entregas

O padrão que protege os dois lados:

Três detalhes que precisam estar escritos:

• Homologação definida: prazo em dias úteis para o contratante testar, formato do registro de problemas e o que constitui aceite. Silêncio após o prazo pode ser tratado como aceite tácito, o que é justo com o fornecedor, desde que o prazo seja razoável.
• Dependências do contratante: se o projeto depende de dados, acessos ou decisões suas, o contrato deve prever que atraso nesses itens desloca o cronograma.
• Multa e reajuste: em que condições há penalidade por atraso, e de qual lado.

4. Gestão de mudanças

Cláusula curta e decisiva. Ela deve estabelecer:

• Que qualquer requisito não previsto no anexo de escopo é mudança.
• Que mudanças são registradas por escrito, estimadas em horas e valor, e só executadas após aprovação da pessoa nomeada no contrato.
• Que toda mudança aprovada recalcula o prazo do marco afetado.
• Opcionalmente, uma bolsa de horas para ajustes pequenos, evitando burocratizar cada detalhe.

Sem esse rito, o projeto absorve pedidos em silêncio até estourar, e a discussão sobre responsabilidade acontece sem provas.

5. Garantia e suporte

Separe claramente três coisas que costumam ser confundidas:

• Garantia: correção de defeito, ou seja, o que foi especificado e não funciona como especificado. Prazo comum: 60 a 90 dias após o aceite. Sem custo.
• Suporte: atendimento a dúvidas e incidentes de operação. Contratado à parte, com tempo de resposta definido.
• Evolução: funcionalidade nova. Sempre à parte.

O contrato deve dizer o que é cada uma, o prazo de resposta em cada caso e por qual canal. Também vale definir o que não é defeito: mudança de regra do negócio, alteração em API de terceiros e requisito não previsto no anexo.

6. Confidencialidade e proteção de dados

Duas obrigações distintas:

Confidencialidade, o fornecedor não divulga informações do negócio, com prazo que sobrevive ao término do contrato. Defina se o fornecedor pode citar o cliente como referência comercial; muitos contratos permitem menção do nome e vedam detalhes técnicos.

LGPD, se o sistema trata dados pessoais, o contrato precisa definir papéis (quem é controlador e quem é operador), finalidade do tratamento, obrigações de segurança, prazo e forma de eliminação dos dados ao final, e o dever de comunicar incidentes de segurança em prazo determinado.

7. Rescisão e transição

A cláusula que ninguém quer usar e que salva quando precisa. Deve prever:

• Rescisão por qualquer das partes com aviso prévio (30 dias é comum).
• Rescisão por justa causa, com hipóteses nomeadas: atraso além de X dias, descumprimento reiterado, inadimplência.
• O que é devido no momento da rescisão: pagamento pelo que foi entregue e homologado.
• Obrigação de transição: entrega em prazo definido de código, dump do banco, documentação de publicação e transferência de todos os acessos, sem custo adicional.

Essa última parte é o que transforma uma separação em processo administrativo em vez de crise.

Checklist antes de assinar

• Cessão de direitos patrimoniais expressa e definitiva
• Repositório, servidor, banco, domínio e chaves em contas da empresa
• Escopo anexado, incluindo a lista do que está fora
• Marcos com pagamento atrelado a homologação, e homologação definida
• Rito de mudança com estimativa, aprovação e recálculo de prazo
• Garantia com prazo, cobertura e tempo de resposta
• Suporte e evolução tratados separadamente da garantia
• Confidencialidade e cláusulas de LGPD, se houver dado pessoal
• Rescisão com aviso, hipóteses de justa causa e obrigação de transição
• Pessoa nomeada de cada lado, com poderes definidos

Nenhum desses pontos exige linguagem jurídica complicada para ser decidido. Decida-os primeiro, em português claro, e leve as decisões prontas para a revisão jurídica. Sai mais rápido, mais barato e, o que mais importa, o contrato passa a refletir o que os dois lados realmente combinaram.