A maioria das disputas em desenvolvimento de software remonta a algo que nunca foi escrito, não a algo que foi violado. O contrato não dizia de quem é o código após uma separação a meio do projeto, portanto tecnicamente ninguém está errado - e todos ficam presos.
Eis as sete cláusulas que evitam isso.
A resposta curta
| Cláusula | O que previne |
|---|---|
| Propriedade do código e da PI, com data de ativação | Disputa de propriedade se a relação terminar cedo |
| Exclusões de âmbito explícitas | Discussões do tipo «pensei que estava incluído» |
| Pagamento por marcos | Perder margem se o projeto estagnar |
| Processo de pedido de alteração | Expansão silenciosa do âmbito dentro do preço original |
| Janela de suporte definida | Trabalho gratuito disfarçado de boa vontade |
| Condições de rescisão e saída | Ficar preso a meio do projeto sem saída limpa |
| Confidencialidade e não reutilização | A sua ideia ou dados serem reutilizados noutro lado |
Sete cláusulas, e a redação concreta de cada uma importa mais do que ter uma cláusula com esse título.
Propriedade do código e da PI, com data de ativação
A cláusula que mais importa, e a que é mais frequentemente redigida de forma vaga, por intenção ou por acidente.
«O cliente detém todo o produto do trabalho» soa protetor. Sem um gatilho, não é: detém a partir de quando? Alguns contratos transferem a propriedade apenas «após a conclusão do trabalho» - o que se torna um problema real se a relação terminar no segundo mês de um desenvolvimento de quatro meses, porque tecnicamente nada foi concluído.
O que procurar em vez disso: propriedade transferida a cada pagamento de marco, ou imediatamente na criação com uma licença de retorno ao programador para portefólio. Ambas funcionam. Prazos vagos não.
Exclusões de âmbito explícitas
Já escrevemos sobre porque é que um documento de âmbito precisa de uma secção de exclusões, e o contrato tem de levar essa mesma especificidade, não apenas remeter vagamente para ela.
«Desenvolvimento do MVP conforme o âmbito anexo» é mais fraco do que parece se o próprio âmbito anexo não listar o que está excluído - custos de APIs de terceiros, conteúdo, migração de dados, suporte além de uma janela indicada. Sem essa lista, ambas as partes recorrem às suas próprias suposições, e as suposições raramente coincidem.
Pagamento por marcos, não por calendário
Um calendário de pagamentos ligado a datas - a 30 dias, depois 30 dias depois, depois mais 30 - paga independentemente de algo ter sido entregue. Isso retira-lhe a única margem real se o projeto atrasar.
Um calendário ligado a marcos - fluxo de autenticação a funcionar, transação principal de ponta a ponta, painel de administração operacional - só liberta pagamento contra algo que consegue efetivamente verificar. Só esta mudança protege um cliente mais do que quase qualquer outra cláusula do contrato.
Um processo definido de pedidos de alteração
O âmbito vai mudar. Um contrato que não diz como está implicitamente a dizer «resolvemos isso quando acontecer», o que favorece quem tiver mais margem nesse momento - normalmente não você, a meio do projeto, quando mudar de parceiro sai caro.
A cláusula deve declarar claramente: um pedido de alteração fora do âmbito definido é estimado e orçamentado em separado, por escrito, antes de se começar a trabalhar nele. Isto protege ambas as partes - o programador não absorve expansão gratuita, e você não descobre uma fatura surpresa por algo que julgava incluído.
Uma janela de suporte definida e explicitamente limitada
«Suporte pós-lançamento incluído» não é uma cláusula, é uma frase. Limitado como - durante quantos dias, cobrindo que tipo de problema, com que tempo de resposta?
Trinta dias de correção de erros em funcionalidade já existente é uma base razoável e comum. Tudo além disso - novas funcionalidades, manutenção contínua, tempos de resposta prioritários - deve ser um contrato de manutenção separado e orçamentado, indicado no contrato ou num acordo ligado, não uma suposição que cada parte faz em silêncio.
Condições de rescisão e saída
Todo o contrato deve responder por escrito, antes de ser necessário: o que acontece se uma das partes quiser sair antes de o projeto terminar?
No mínimo: prazo de aviso, o que é devido pelo trabalho concluído até esse ponto, e confirmação de que as condições de propriedade (ver cláusula um) se aplicam de forma limpa também numa rescisão antecipada, não apenas num final bem-sucedido. Um contrato que só descreve o que acontece numa conclusão limpa não planeou o cenário com mais probabilidade de gerar disputa.
Confidencialidade e não reutilização
Padrão na maioria dos contratos profissionais, mas vale a pena verificar a coisa concreta que os fundadores assumem estar coberta e muitas vezes não está: uma cláusula que impeça o programador de reutilizar a sua lógica de negócio específica, os seus dados ou a sua abordagem proprietária no projeto de outro cliente, não apenas confidencialidade genérica sobre não falar publicamente do seu negócio.
Os NDA genéricos cobrem o sigilo. Esta cláusula cobre a reutilização, que é a versão que realmente importa se o valor do seu produto está em como algo funciona, não apenas em que existe.
O que fazer se faltarem estas cláusulas
A maioria são acréscimos, não reescritas. Um parceiro que resiste fortemente a acrescentar datas claras de propriedade, pagamentos por marcos ou uma lista de exclusões está a dar-lhe informação que convém ter antes de assinar, não depois - as perguntas que vale a pena fazer antes de assinar cobrem a versão conversacional da mesma verificação.
Nenhuma destas sete cláusulas é invulgar ou agressiva de pedir. São a diferença entre um contrato que descreve uma relação e um que realmente o protege se a relação correr mal.
Está a rever um contrato para o desenvolvimento de um MVP e quer uma segunda opinião sobre as condições? Envie-nos os detalhes - dir-lhe-emos o que falta. A nossa própria estrutura contratual, incluindo condições de PI e marcos de pagamento, está explicada nos nossos preços.
Perguntas frequentes
Escrito por
Shakhbozbek Usmonov
Founder & CEO, Steppe Venture Builders
