A cláusula mais esquecida num projeto de software: os critérios de aceitação

Como empresa de software, é um dos primeiros temas de que falamos em cada projeto. Um projeto que começa sem critérios de aceitação escritos é um projeto em que, até ao dia da entrega, cada um espera uma coisa diferente.

Quando se abre um processo de litígio de software, as partes costumam discutir isto. Se o software funciona ou não.

A razão pela qual esta discussão não se resolve não é técnica. No contrato não consta o que significa "funciona". Se não há critério de aceitação, o programador diz que entregou, o cliente diz que não recebeu, e ambos têm razão segundo o seu próprio critério.

Esta única lacuna é o denominador comum dos litígios de software que já vi.

Como deve redigir-se o critério de aceitação

A aceitação é o momento que produz a consequência jurídica da entrega. É também a partir daí que começa a correr o prazo de responsabilidade por defeitos. Ou seja, essa data ser incerta significa que também é incerto quando termina a responsabilidade.

Uma cláusula de aceitação que funciona inclui o seguinte. A lista de testes de aceitação, o ambiente em que o teste será executado, quem o executa, o prazo de objeção e a regra segundo a qual, se não chegar objeção dentro do prazo, a aceitação se considera produzida.

O elemento mais frequentemente esquecido é o ambiente de teste. Um software que funciona na máquina do programador pode não funcionar no ambiente do cliente, e nesse ponto discute-se quem é responsável. Se o ambiente estiver definido no contrato, essa discussão não surge.

Vincular o critério de aceitação à satisfação subjetiva é, por sua vez, a pior opção. Uma aceitação dependente "da satisfação do cliente" cria uma obrigação sem limite de tempo, e o trabalho do programador nunca termina.

Os direitos de propriedade intelectual não passam automaticamente

O segundo erro frequente é a presunção de propriedade. O cliente pensa que, em troca do preço pago, é proprietário do código. Juridicamente, a situação não é essa.

Os programas de computador estão protegidos como obra ao abrigo da Lei n.º 5846, e, salvo estipulação em contrário, os direitos patrimoniais permanecem no titular da obra. A cessão deve ser expressamente regulada, feita por escrito, e os direitos cedidos devem ser enumerados um a um. Uma fórmula geral como "todos os direitos são cedidos" fica em aberto para discussão.

Além disso, há que distinguir três categorias. O código escrito especificamente para o cliente é geralmente cedido. Os componentes preexistentes do programador não são cedidos, são licenciados, e o alcance e a duração da licença são redigidos à parte. Os componentes de código aberto estão sujeitos às suas próprias licenças, e a lista dos utilizados deve constar em anexo ao contrato.

Quando estas três categorias não são distinguidas, acontece o seguinte. O cliente pensa que é proprietário de todo o código, o programador continua a usar a sua própria biblioteca noutro projeto, e o problema só é notado quando surge um litígio.

Um contrato sem gestão de alterações não funciona

Por bem redigido que esteja o texto do âmbito, durante o projeto chegam pedidos de alteração. Se o contrato não disser como esse pedido será tratado, cada pedido transforma-se numa negociação.

Uma regulação que funciona responde a estas perguntas. A quem e de que forma o pedido é comunicado. Por quem e em quantos dias é feita a análise de impacto. Como se calcula o efeito no preço e no calendário. Com a assinatura de quem é dada a aprovação. O que acontece ao pedido não aprovado.

Quando estas cinco perguntas têm resposta, a alteração deixa de ser uma crise e passa a ser um processo.

A qualidade de subcontratante de tratamento surge sem se notar

Se o programador acede a dados pessoais do cliente, passa a ter a qualidade de subcontratante de tratamento nos termos da Lei 6698. Esta qualidade é muitas vezes adquirida sem que ninguém se aperceba.

O caso mais frequente é o uso de dados reais no ambiente de testes. Uma cópia da base de dados de produção é levada para o ambiente de testes, os programadores trabalham com ela, e a partir desse momento nasce uma relação de tratamento de dados. Se o contrato não contiver disposição a esse respeito, a relação decorre sem fundamento jurídico.

A solução mais limpa é não deixar esta situação chegar a existir. Testar com dados mascarados ou sintéticos não é tecnicamente difícil e elimina em grande medida o risco. Se o acesso a dados reais for realmente indispensável, devem regular-se por escrito o objeto, a duração e a finalidade do tratamento, a sujeição do programador a instruções, o recurso a subsubcontratantes, as medidas de segurança e a devolução ou destruição dos dados no final do contrato.

A manutenção é um contrato à parte

Por fim, a manutenção e o suporte. Esta é uma prestação distinta do desenvolvimento e deve ser regulada em separado.

O que é preciso escrever não é o tempo de intervenção, mas a classificação de avarias. Se não se definir qual avaria entra em qual classe, cada avaria é pedida com prioridade máxima. Depois de definidas as classes, o tempo de intervenção e de resolução é escrito separadamente para cada uma.

Há ainda a questão da medição. Um compromisso de nível de serviço que não seja mensurável fica sem sanção quando é violado. Como será feita essa medição e segundo o registo de quem deve constar do contrato.

Quem deve redigir o contrato

Todas estas cláusulas exigem que o direito e a engenharia decidam em conjunto. O advogado não pode redigir sozinho o critério de aceitação, porque não sabe o que é testável. O engenheiro não pode redigir sozinho a cessão de direitos de propriedade intelectual.

A parte que vai para a negociação do contrato sem equipa técnica acaba por aceitar cláusulas que depois não podem ser aplicadas. A cláusula inaplicável, quando surge o litígio, comporta-se como se nunca tivesse existido.