O que é a conclusão do trabalho no contrato de empreitada no desenvolvimento de sistemas

O desenvolvimento de sistemas é normalmente um processo que se prolonga por um longo período de tempo, e muitas vezes são solicitadas alterações de especificações ou a implementação de funcionalidades adicionais. Para os fornecedores que aceitam este tipo de trabalho, pode haver momentos em que se encontram numa situação difícil, sem ver uma saída. Para esses fornecedores, a questão de “o que precisamos fazer e até que ponto para considerar o nosso trabalho concluído” pode por vezes tornar-se uma preocupação séria.

Além disso, pode-se dizer que o desenvolvimento de sistemas é muitas vezes realizado sob contratos de empreitada, que são contratos com o objetivo de “concluir o trabalho”.

Neste artigo, vamos explicar do ponto de vista legal, “em que momento e até que ponto o desenvolvimento de sistemas é considerado concluído”.

O que significa a conclusão do desenvolvimento de um sistema

A conclusão do desenvolvimento de um sistema do ponto de vista de um engenheiro

No campo do desenvolvimento de sistemas, se perguntarmos “quando é que o desenvolvimento do sistema está concluído”, a resposta geralmente seria algo como “quando o processo de teste é concluído e os produtos finais são entregues”. De facto, o fluxo geral do desenvolvimento de sistemas começa com a definição de requisitos, onde são identificadas as funções a serem implementadas, seguido pela criação de vários documentos de design, a implementação do programa, e finalmente, a conclusão do processo de teste para verificar se o sistema está a funcionar corretamente. O processo termina com a aceitação do usuário.

Portanto, do ponto de vista de um engenheiro envolvido no trabalho concreto, a compreensão geral seria que “a conclusão do desenvolvimento do sistema = aprovação na aceitação”.

A conclusão do desenvolvimento de um sistema do ponto de vista legal

Por outro lado, do ponto de vista legal, se perguntarmos quando é que o desenvolvimento do sistema está concluído, a discussão central seria quando é que as obrigações legais que o fornecedor tinha sob o contrato foram cumpridas. Em primeiro lugar, os contratos de desenvolvimento de sistemas são geralmente classificados como contratos de empreitada ou contratos de mandato.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

A explicação sobre a diferença entre estes dois tipos de contratos é deixada para o artigo acima, mas em relação à conclusão do desenvolvimento do sistema, ou seja, o cumprimento das obrigações do fornecedor, os critérios de julgamento são dados como se segue.

Contrato de empreitada: Artigo 632 do Código Civil Japonês
Artigo 632
O contrato de empreitada produz efeitos quando uma das partes se compromete a completar um trabalho e a outra parte se compromete a pagar uma remuneração pelo resultado desse trabalho.
Contrato de mandato: Artigo 648 do Código Civil Japonês
Artigo 648
1. O mandatário não pode exigir uma remuneração ao mandante, a menos que haja um acordo especial.
2. O mandatário só pode exigir a remuneração depois de ter cumprido o mandato, a menos que a remuneração tenha sido fixada por um período de tempo, caso em que se aplica o parágrafo 2 do artigo 624.
3. Se o cumprimento do mandato terminar a meio do caminho devido a uma causa que não pode ser atribuída ao mandatário, este pode exigir uma remuneração proporcional ao cumprimento já realizado.

A conclusão do desenvolvimento do sistema é um problema no contrato de empreitada

No entanto, o problema de “quando é que o trabalho está concluído” é basicamente um problema no contrato de empreitada, não apenas no contexto do desenvolvimento de sistemas. No caso do contrato de mandato, em vez de considerar o cumprimento da obrigação como trazer um resultado ou produto específico, é um tipo de contrato que enfatiza o sentido de fazer o que deve ser feito de forma adequada (independentemente do resultado) com uma certa discrição como um profissional. Mesmo na lei, no contrato de mandato, mesmo que o produto final esperado não tenha sido produzido, se o processamento do negócio estiver a ser adequadamente avançado, é possível solicitar uma remuneração (Artigo 648, Parágrafo 2), e se o cumprimento for interrompido a meio do caminho devido a uma causa que não pode ser atribuída ao mandatário, é possível solicitar uma remuneração proporcional ao cumprimento já realizado (Artigo 648, Parágrafo 3). Pode-se dizer que o contrato de empreitada é “orientado para o resultado”, enquanto o contrato de mandato é “orientado para o processo”.

Portanto, no contrato de mandato, o “dever de cuidado” no processo de avançar o trabalho delegado é mais provável de se tornar um problema legal. Ou seja, quando se pode perseguir a violação do dever de cuidado com base no contrato de mandato, assumindo que se tem uma alta confiança.

Por outro lado, o que é importante no contrato de empreitada é a “conclusão do trabalho”. Se o trabalho que deveria ser concluído não for concluído, o fornecedor não poderá cumprir a obrigação que tem, e não poderá solicitar uma remuneração, como regra. No entanto, se o trabalho estiver concluído, não há razão para questionar a parte do progresso intermediário. Portanto, o problema de “quando é que o projeto de desenvolvimento do sistema está concluído” pode basicamente ser redefinido como um problema de interpretação legal da frase “conclusão do trabalho” no contrato de empreitada.

Quando é considerado concluído um trabalho em desenvolvimento de sistemas?

Então, quando especificamente devemos considerar que um “trabalho está concluído”? Vamos verificar alguns casos judiciais passados sobre este ponto.

Casos judiciais sobre a conclusão do trabalho

No caso judicial citado abaixo, surgiram problemas como velocidade de processamento e custos de comunicação no sistema entregue pelo fornecedor. Mesmo com a descoberta desses problemas, todo o processo de desenvolvimento foi concluído, e foi discutido se isso poderia ser considerado como “trabalho concluído”. Como resultado, foi indicado que a conclusão do trabalho poderia ser reconhecida.

Os artigos 632 e 633 do Código Civil Japonês estipulam que o momento do pagamento da remuneração ao contratado é quando o trabalho é concluído e o objeto do trabalho é entregue ao cliente. Por outro lado, o artigo 634 do mesmo código estipula que, se houver defeitos no objeto do trabalho, o contratado tem a responsabilidade de garantia para o cliente (parágrafo 1), e até que o contratado cumpra sua responsabilidade de garantia para os defeitos do objeto do trabalho, o cliente tem o direito de defesa de execução simultânea em relação ao pagamento da remuneração (parágrafo 2). De acordo com estas disposições do Código Civil, a lei distingue entre os casos em que o resultado do trabalho é incompleto e há defeitos no objeto do trabalho e os casos em que o trabalho não está concluído, e é entendido que, mesmo que haja defeitos no objeto do trabalho, seja eles ocultos ou aparentes, isso não significa que o trabalho não está concluído.
Portanto, se o contratado concluiu o trabalho ou não deve ser julgado com base em se o trabalho foi concluído até a última etapa planejada no contrato original, e é apropriado entender que o cliente não pode recusar o pagamento da remuneração apenas porque há defeitos no objeto do trabalho quando o contratado concluiu a última etapa do trabalho e entregou o objeto do trabalho.

No julgamento acima, foi decidido que a “conclusão do trabalho” é cumprida se o processo final no desenvolvimento do sistema for concluído. Como medida de alívio quando há defeitos (muitas vezes chamados de “defeitos” na lei) no sistema que o fornecedor criou, há um sistema separado de responsabilidade de garantia de defeitos.

Portanto, mesmo que o conceito de “conclusão do trabalho” seja interpretado de forma um pouco ampla, isso não resultará em injustiça para o lado do usuário no final. Em resumo, é o seguinte:

【Obrigação no contrato de empreitada = Conclusão do trabalho = Conclusão de todas as etapas】
========
Se o trabalho não for concluído…
↓
【Assumir a responsabilidade por não cumprimento da obrigação】
========
Se o trabalho estiver concluído, mas houver defeitos…
↓
【Reconhecer o cumprimento da obrigação e questão da responsabilidade de garantia de defeitos】

O caso judicial acima mostra como dividir esses problemas.

No entanto, em relação ao ponto de “conclusão do trabalho”, também é possível considerar a partir do ponto de vista da “aprovação da inspeção do lado do usuário”. Para problemas legais quando a inspeção do lado do usuário não progride, explicamos em um artigo separado.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

O que significa a conclusão de um trabalho em termos legais

No desenvolvimento de sistemas, se a “conclusão do trabalho” for reconhecida, isso significa que a obrigação foi cumprida, portanto, não haverá mais a possibilidade de ser responsabilizado por “incumprimento da obrigação”. No caso de um contrato de empreitada, se o trabalho não for considerado concluído, não será possível solicitar o pagamento e, mesmo que tenha sido acordado um pagamento antecipado, esses valores terão que ser devolvidos. Por outro lado, se a conclusão do trabalho for reconhecida, o fornecedor terá que lidar com questões como a responsabilidade por defeitos e garantias de qualidade do contrato.

O facto de o fornecedor ser libertado da responsabilidade pelo incumprimento da obrigação significa que o espaço para o utilizador cancelar o contrato diminui drasticamente. Isto porque o cancelamento do contrato com base na responsabilidade por defeitos é limitado a casos em que o objetivo do contrato não pode ser alcançado. Se o contrato for cancelado, o fornecedor também perderá o direito de solicitar o pagamento (ou seja, em termos simples, não receberá qualquer pagamento), por isso é comum haver disputas sobre a “conclusão do trabalho” na prática.

Para uma explicação detalhada sobre o “cancelamento” de contratos no desenvolvimento de sistemas, consulte o seguinte artigo.

Notas sobre a conclusão do trabalho

Como pensar em mudanças de especificações e desenvolvimento adicional

Além disso, para o fornecedor, pode-se prever situações em que “já conseguimos cumprir as especificações que nos foram inicialmente ditas, mas estamos a ser solicitados a mudar as especificações e adicionar funções, e mesmo que tentemos terminar o trabalho, não conseguimos encontrar um ponto de corte”. Mesmo nestes casos, surgem problemas como “o momento de terminar o desenvolvimento do sistema”. Uma explicação detalhada sobre este assunto pode ser encontrada no seguinte artigo.

https://monolith.law/corporate/increase-of-estimate[ja]

Atenção também à revisão do Código Civil Japonês

Além disso, as disposições sobre a responsabilidade pela garantia de defeitos com base no contrato de empreitada são uma área que tem sido fortemente influenciada pela revisão do Código Civil Japonês, devido ao facto de as ligações entre os artigos anteriores serem complexas e difíceis de entender. No meio da revisão do Código Civil Japonês, uma explicação detalhada sobre como interpretar o que é um “defeito” pode ser encontrada no seguinte artigo.

https://monolith.law/corporate/defect-warranty-liability[ja]

Resumo

Neste artigo, discutimos o caminho para ligar projetos de desenvolvimento de sistemas, que muitas vezes podem ser levados a situações onde se diz “não se vê uma saída”, à teoria jurídica do “trabalho concluído”. A saída de cada projeto pode variar dependendo dos requisitos de desenvolvimento, mas quando surge uma disputa sobre esses pontos, acredita-se que o conceito jurídico de “trabalho concluído” muitas vezes serve como um guia.