O que exigir num contrato de desenvolvimento de software (e de quem fica o código)

Vai mandar fazer software à medida. Comparou propostas, escolheu quem lhe pareceu melhor, e agora vai assinar. A pergunta que quase ninguém faz nesta fase (e que é a que dói três anos depois) é simples: afinal, o que é que fica seu?

Não encontrámos, em português, um único artigo que respondesse a isto do lado de quem compra. Há teses académicas e há páginas de advogados. Não há ninguém a explicar ao gerente de uma PME o que deve exigir antes de assinar. Este artigo é essa lista.

Uma nota antes de começar: isto não é aconselhamento jurídico. É a lista das cláusulas que, pela nossa experiência, separam um projeto que corre bem de um que se transforma numa dependência. O contrato em si deve ser visto por um advogado.

1. De quem é o código-fonte

É a cláusula mais importante e a mais frequentemente omitida. Em Portugal, salvo estipulação em contrário, quem escreve o programa é o titular dos direitos, e não quem o encomendou. Ou seja: se o contrato for omisso, o código não é seu, mesmo que o tenha pago na totalidade.

O que deve constar, por escrito: se a titularidade é transmitida para si, se lhe é concedida uma licença, e nesse caso com que âmbito e por quanto tempo. Ambas as soluções podem ser aceitáveis; o que não é aceitável é não estar escrito.

Pergunta a fazer na reunião: «no fim do projeto, se eu quiser entregar isto a outra empresa para continuar, posso?» A resposta merece ficar no contrato, não na ata da reunião.

2. Se recebe o código, e onde

Ser titular do código sem nunca o ter recebido é uma titularidade teórica. O contrato deve dizer quando lhe é entregue (na entrega final, em cada fase, ou continuamente num repositório a que tem acesso) e em que estado.

Peça também as credenciais e os acessos aos serviços que o projeto usar. Já vimos empresas donas do código e sem acesso ao sítio onde ele corre.

3. Documentação: o que é, ao certo

«Entregamos documentação» pode significar tudo ou nada. O mínimo utilizável é: como está construído, como se instala de raiz noutro sítio, onde ficam os dados, que serviços externos usa e com que credenciais, e como se faz uma cópia de segurança e um restauro.

Um sinal de que a coisa vai correr bem: se a documentação for sendo escrita durante o projeto, e não prometida para o fim. Documentação feita à pressa na última semana é quase sempre inútil.

4. Os dados são seus, e exportáveis

Distinto do código, e igualmente importante. O contrato deve garantir que pode exportar os seus dados a qualquer momento, em formato aberto e legível, sem custo adicional e sem depender de autorização.

Repare na expressão «sem custo adicional». É aí que aparecem, com alguma frequência, faturas inesperadas no momento exato em que a relação está a terminar.

5. O que acontece se a relação terminar

Nenhuma das partes gosta de falar disto antes de começar. É precisamente por isso que se deve falar.

Deve ficar escrito o que acontece em caso de saída: o que é entregue, em que prazo, e se há apoio à transição para outro fornecedor. E deve ficar escrito, de forma inequívoca, que o software não é desligado por questões administrativas. Um diferendo de faturação resolve-se a falar, não com a sua operação parada.

6. E se o fornecedor desaparecer?

O medo mais comum, e o mais legítimo. Há três níveis de proteção, do mais simples ao mais formal.

O básico é ter o código e a documentação consigo, atualizados: se os tiver, a empresa pode fechar que o seu software continua a poder ser mantido por outra pessoa.

O intermédio é ter tudo depositado num sítio que controla, não apenas nos servidores do fornecedor.

O mais formal chama-se depósito de código junto de terceiro, e consiste em confiar uma cópia a uma entidade independente que a liberta se determinadas condições se verificarem. Faz sentido em projetos grandes; na maior parte das PME, os dois primeiros níveis chegam.

7. Manutenção: quanto custa depois

Software entregue hoje precisa de trabalho amanhã. O contrato deve dizer o que acontece a seguir à entrega: durante quanto tempo os defeitos são corrigidos sem custo, quanto custa a manutenção depois disso, e com que tempo de resposta.

Se ninguém lhe falar disto antes de assinar, é sinal de que a conversa vai acontecer no pior momento possível: quando alguma coisa parar.

8. Âmbito, aceitação e alterações

A causa número um de projetos que derrapam não é técnica: é o âmbito que cresce sem que ninguém o tenha decidido. Deve ficar escrito o que está incluído, como se dá o trabalho por aceite, e qual é o processo para pedir uma alteração: quem a orça, em quanto tempo, e como é aprovada.

Não é burocracia. É o que permite dizer «isso é um extra» sem que a relação azede.

A lista curta, para levar para a reunião

Se só tiver cinco minutos com o fornecedor, faça estas seis perguntas e repare menos nas respostas do que na naturalidade com que são dadas:

De quem fica o código? Quando é que o recebo? O que inclui a documentação? Como exporto os meus dados? O que acontece se eu sair? E quanto custa manter isto no segundo ano?

Quem faz este trabalho a sério responde a estas seis perguntas sem hesitar, porque já as ouviu muitas vezes. Quem hesita, ou desvia, está a dizer-lhe alguma coisa.

Como fazemos na RTC

Escrevemos as nossas respostas a estas perguntas numa página própria, para poder lê-las antes de nos contratar e não depois. Em resumo: o código é seu, a documentação vai junto, os dados são exportáveis a qualquer momento sem custo, e não desligamos nada por questões administrativas.

Os valores de partida de cada tipo de projeto e o custo da manutenção estão publicados na página de preços. Achamos que estas coisas devem estar à vista antes da primeira reunião, não depois da terceira.