Desenvolvimento sob encomenda: pagar pelo projeto não responde tudo
Desenvolvimento sob encomenda é a criação de software para necessidade definida do contratante. O pagamento não resolve sozinho a titularidade, o acesso ao repositório ou o uso de componentes preexistentes. Contrato, contexto do trabalho e Lei de Software determinam o alcance dos direitos.
O contratante pode financiar todo o projeto e ainda descobrir que não recebeu documentação, credenciais, histórico ou direito suficiente para manter o produto. O risco não está apenas no código final.
Por Giovanny Maciel, Sócio-fundador
Pagar pelo desenvolvimento de um software não responde, sozinho, quem terá os direitos, quem controlará o repositório ou como o produto continuará depois da entrega. Um projeto sob encomenda precisa separar resultado novo, componentes anteriores do fornecedor, dependências de terceiros, documentação e infraestrutura antes de falar genericamente em “propriedade do sistema”.
Escopo precisa ser testável
Lista de funcionalidades ajuda, mas não basta. Requisitos, integrações, critérios de aceite, ambientes, desempenho, segurança e responsabilidades por dados precisam permitir que as partes reconheçam quando uma entrega está concluída. Sem critério, toda diferença vira discussão sobre “era óbvio que estava incluído”.
Mudança também precisa de processo. Quem solicita, quem estima, quem aprova impacto em prazo e preço e como a alteração entra na documentação? Backlog informal sem controle pode transformar contrato de escopo definido em desenvolvimento indefinido.
Titularidade exige cadeia, não apenas uma frase
A Lei de Software contém regras específicas sobre direitos relativos a programas criados em determinadas relações de emprego e prestação de serviços. O contrato deve ser compatível com essas regras e identificar o que é efetivamente transferido ou licenciado.
Ferramentas preexistentes, bibliotecas open source e componentes de terceiros precisam ser destacados. Veja titularidade do código para reconstruir a cadeia e open source para dependências licenciadas.
Equipe e subcontratação também entram no risco
O cliente precisa saber se o fornecedor pode substituir profissionais-chave, terceirizar módulos críticos ou enviar código e dados a terceiros. Não é necessário congelar equipe para sempre, mas papéis sensíveis, confidencialidade e cadeia de direitos devem sobreviver às trocas. Se houver subcontratação, as obrigações de segurança e propriedade intelectual precisam alcançar quem realmente executa o trabalho. Também vale prever como conhecimento e documentação serão transferidos quando alguém deixa a equipe, para que a continuidade não dependa de uma única pessoa.
Preço e cronograma também precisam conversar com a metodologia. Em contrato por hora, a empresa precisa de visibilidade de consumo e prioridade; em preço fechado, precisa saber quais premissas sustentam o valor. Misturar promessa de escopo fixo com backlog ilimitado costuma produzir conflito previsível.
Documentação deve acompanhar a versão entregue e não ser tratada como tarefa posterior indefinida.
Aceite não pode encerrar a continuidade
Projeto entregue ainda precisa ser implantado, mantido e eventualmente migrado. Repositório, documentação, acesso a ambientes, scripts, credenciais e plano de suporte devem ter destino definido. Se o fornecedor desaparecer no dia seguinte ao aceite, a empresa consegue operar?
A resposta não precisa ser “o cliente recebe tudo”. Pode envolver licença, escrow de código, transição ou suporte contratado. O importante é que a dependência seja conhecida e deliberada, não descoberta quando já virou incidente.
Perguntas frequentes
Quem é dono do software desenvolvido sob encomenda?
A resposta depende da Lei de Software, do vínculo e do contrato. Pagamento não deve ser usado como única prova de titularidade.
Todo projeto precisa de escopo fechado?
Não. Modelos ágeis podem trabalhar com escopo evolutivo, desde que exista governança para prioridade, aceite, capacidade, preço e mudança.
O fornecedor pode reutilizar componentes próprios?
Pode ser previsto, mas componentes preexistentes precisam ser identificados e a licença concedida ao cliente deve ser suficiente para operar o produto contratado.