A relação entre o atraso na entrega do desenvolvimento do sistema e o atraso no cumprimento legal

Um projeto de desenvolvimento de sistemas é, em certo sentido, sempre uma luta contra o prazo. Do ponto de vista jurídico, podemos considerar o “risco que se torna aparente caso o prazo não seja cumprido” no desenvolvimento de sistemas.

Neste artigo, explicaremos em que circunstâncias o “atraso na entrega” é tratado como um atraso no cumprimento e resulta em responsabilidade legal, como o incumprimento de obrigações.

O que é o prazo de entrega no desenvolvimento de sistemas

Prazo de entrega em termos gerais

Em termos gerais, o “prazo de entrega” refere-se à data limite para a entrega do produto solicitado pelo cliente. Mesmo no local de desenvolvimento, onde se presume que possam ocorrer problemas inesperados, muitas vezes é exigido o cumprimento rigoroso do prazo de entrega. Em situações onde existe uma diferença de poder entre o lado do contratante e o lado do contratado, a tendência de cumprir rigorosamente o prazo de entrega é ainda mais acentuada. Ou, em caso de atraso na entrega, pode haver casos em que se oferece um desconto proporcional ao excesso, ou se torna gratuito o trabalho adicional. De qualquer forma, o prazo de entrega é geralmente considerado importante para a manutenção da relação de confiança com o cliente.

Explicamos o conceito de “conclusão do trabalho” na lei e o prazo de entrega em outro artigo.

O que é o prazo de entrega do ponto de vista legal

Do ponto de vista legal, quando o lado do fornecedor e o lado do usuário celebram um contrato, o fornecedor tem a obrigação (dívida) de entregar o sistema. E o prazo de entrega é uma restrição sobre quando essa obrigação deve ser cumprida. Ou seja, um atraso na entrega é equivalente a um atraso no cumprimento, que é um tipo de inadimplência. Portanto, se o atraso na entrega for causado por dolo ou negligência do lado do fornecedor, ele será responsável pela inadimplência devido ao atraso no cumprimento (Artigo 412 do Código Civil Japonês).

1. Quando há um prazo fixo para o cumprimento da obrigação, o devedor assume a responsabilidade pelo atraso a partir do momento em que o prazo chega.
2. Quando há um prazo incerto para o cumprimento da obrigação, o devedor assume a responsabilidade pelo atraso a partir do momento em que sabe que o prazo chegou.
3. Quando não se estabelece um prazo para o cumprimento da obrigação, o devedor assume a responsabilidade pelo atraso a partir do momento em que recebe o pedido de cumprimento.

Artigo 412 do Código Civil Japonês

O “assumir a responsabilidade” mencionado neste artigo refere-se, em termos simples, à responsabilidade por danos e prejuízos.

Quando o devedor não cumpre a sua obrigação de acordo com o propósito principal da mesma, o credor pode reclamar a compensação pelos danos causados por isso. O mesmo se aplica quando o devedor não pode cumprir a sua obrigação devido a uma causa que lhe é imputável.

Artigo 415 do Código Civil Japonês

Além disso, se o usuário estabelecer um “período razoável” e notificar o fornecedor para entregar até esse dia, mas o fornecedor não entregar, o usuário pode cancelar o contrato.

Quando uma das partes não cumpre a sua obrigação, a outra parte pode cancelar o contrato se, após ter notificado o cumprimento da obrigação dentro de um prazo razoável, não houver cumprimento dentro desse prazo.

Artigo 541 do Código Civil Japonês

Para uma explicação geral sobre a opção de “cancelamento” nestes casos, consulte o seguinte artigo.

Nem todos os atrasos na entrega constituem incumprimento legal

No entanto, o facto superficial de “não cumprir o prazo” não significa necessariamente um atraso no cumprimento como incumprimento de uma obrigação. Para que uma simples situação de atraso na entrega se torne um atraso legal, é necessário cumprir várias condições, como indicado abaixo.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Além disso, dado que o desenvolvimento do sistema é normalmente um projeto em que tanto o utilizador como o fornecedor têm obrigações, pode haver casos em que se conclui que ambos violaram as suas obrigações e a indemnização por danos é compensada.

Além disso, o que normalmente acontece perto do prazo de entrega é a “aceitação” do produto. A aceitação é tratada em detalhe no artigo abaixo. Aqui, explicamos casos em que a entrega não é concluída porque o utilizador não aceita.

O ponto principal da discussão é que “não cumprir o prazo = incumprimento da obrigação” não é tão simples. Mesmo que se fale de atraso na entrega, as razões podem variar, seja por culpa do fornecedor ou do utilizador. Há uma grande diferença entre o “atraso no prazo” como facto formal e o “atraso no cumprimento” que constitui uma violação substancial da obrigação.

Casos judiciais sobre atrasos no cumprimento

Vamos analisar abaixo um caso judicial em que se discutiu se é possível perseguir a responsabilidade por incumprimento de dívida devido a atrasos na entrega. Embora seja uma disputa sobre a data de entrega, a essência é que a organização dos casos com base nos fundamentos do desenvolvimento do sistema, seja o “dever de cooperação do usuário” ou o “dever de gestão do projeto”, é importante e não difere de outras disputas.

Caso em que o atraso no cumprimento foi compensado pela violação do dever de cooperação do usuário e negligência

No caso citado na sentença abaixo, o usuário tornou-se o queixoso e iniciou um processo devido ao atraso na entrega do fornecedor. Esta ação foi parcialmente aceite em tribunal, mas ao mesmo tempo, foi indicado que a falta de cooperação adequada por parte do usuário também foi um fator, e 40% dos danos causados pelo atraso na entrega foram atribuídos à responsabilidade do usuário.

Com base na discussão acima, pode-se dizer que o usuário queixoso não tomou decisões oportunas e adequadas, como não resolver questões pendentes solicitadas pelo réu até o prazo estipulado, e que houve casos em que não cooperou adequadamente. No entanto, em relação à alegação do réu de violação do dever de cooperação em relação às solicitações de adição ou alteração de funções do usuário queixoso, embora se reconheça que o usuário queixoso fez solicitações que resultaram em adições e alterações ao conteúdo do desenvolvimento previsto no documento de design básico do caso, não se pode dizer que isso constitui uma violação do dever de cooperação do usuário queixoso, e a alegação do réu é infundada. Além disso, em relação à alegação do réu de violação do dever de cooperação em relação às solicitações excessivas do usuário queixoso, não se pode admitir que o usuário queixoso fez solicitações excessivas em relação ao pagamento do contrato de desenvolvimento do sistema de computador do caso, e não há razão. Pelo contrário, pode-se dizer que houve pontos inadequados na gestão do projeto do réu, como o fato de o réu ter percebido o número de processos (o número de “processos” em julho ou agosto do mesmo ano) a partir de janeiro do ano 11 (1999) e ter feito propostas para reduzir o processamento e assumir o pagamento adicional de taxas de contrato inadequadas a partir de 31 de maio do mesmo ano.

Julgamento do Tribunal Distrital de Tóquio, 10 de março do ano 16 da era Heisei (2004)

A sentença acima reconheceu o atraso na entrega do fornecedor como um atraso no cumprimento, mas também reconheceu que parte da causa era que o usuário não resolveu as questões pendentes levantadas pelo fornecedor, e aceitou a reivindicação do usuário, cortando 60% dos danos reivindicados pelo usuário. Isto é o mesmo que o tratamento de “compensação por negligência” em acidentes de trânsito onde a vítima também é culpada.

Na sentença completa deste caso, a frase “dever de cooperação” aparece mais de 40 vezes, incluindo o índice. Do ponto de vista legal, pode-se dizer que a essência era como dividir o dever de gestão do projeto do fornecedor e o dever de cooperação do usuário.

Caso em que o atraso no cumprimento foi totalmente reconhecido

A seguir, citamos a sentença de um caso em que a responsabilidade por incumprimento de dívida devido a atrasos na entrega foi totalmente comprovada e reconhecida como atraso no cumprimento. Neste caso, o usuário rescindiu o contrato quando o sistema estava quase concluído, e o fornecedor iniciou um processo, mas o usuário argumentou que o atraso na entrega era a causa.

Não se pode negar que o réu deu várias instruções de alteração para o sistema de design e que, como resultado, a conclusão foi atrasada até certo ponto. Em particular, o réu deu a instrução final de alteração em 23 de junho do ano 17 (2005), por isso é reconhecido que a função de “cálculo automático para itens detalhados de pedras laterais” baseada nessa instrução não estava concluída, e isso não pode ser atribuído à culpa do autor. No entanto, as outras alterações instruídas pelo réu foram feitas até o início de abril do mesmo ano, e não se reconhece que houve circunstâncias que deveriam ser interpretadas como tendo alterado o plano de conclusão do sistema de design (exceto a parte devido à instrução de alteração do réu em 23 de junho do mesmo ano). Não se pode admitir que o autor tinha concluído o sistema de design até o final de junho do mesmo ano, excluindo a parte devido à instrução de alteração em 23 de junho do mesmo ano, a um nível que permitisse a operação real, e se reconhece que partes importantes do sistema, como a incapacidade de exibir imagens ou a função de pesquisa não funcionar, estavam incompletas. (Omissão) Pode-se inferir que o autor não geriu adequadamente os procedimentos de trabalho associados ao desenvolvimento do sistema. Com base no acima exposto, não se pode admitir que a principal causa do não cumprimento do prazo de entrega pelo autor estava nas instruções do réu, e não se pode admitir que não havia razões que pudessem ser atribuídas à culpa do autor.

Julgamento do Tribunal Distrital de Tóquio, 16 de fevereiro do ano 19 da era Heisei (2007)

Neste julgamento, foi indicado que a parte que não estava concluída devido à instrução de alteração de especificações dada cerca de uma semana antes do prazo de entrega não pode ser atribuída à culpa do fornecedor. No entanto, considerando que:

• Ainda não foi respondido à instrução de alteração dada vários meses antes
• Depois que a instrução acima foi dada, um e-mail foi enviado pelo fornecedor informando a data prevista de conclusão
• As partes incompletas são partes importantes do sistema, como a implementação da exibição de imagens e a função de pesquisa, e o fato de que não foi respondido a isso é um elemento que suporta a violação do dever de gestão do projeto

Foi reconhecida a responsabilidade por incumprimento de dívida devido a atrasos no cumprimento.

O que podemos aprender com o conteúdo de ambos os julgamentos

Considerando ambos os julgamentos, pode-se dizer que o problema do “prazo de entrega” no desenvolvimento do sistema é, em última análise, uma questão de como traçar a fronteira entre o dever de cooperação do usuário e o dever de gestão do projeto do fornecedor. Em outras palavras, como o atraso no cumprimento é um tipo de responsabilidade por incumprimento de dívida, a questão de se houve ou não alguma violação do dever por parte do fornecedor naturalmente se torna um ponto de disputa. E para considerar se o dano que se manifestou como resultado (ou seja, a perda do usuário devido ao atraso na entrega) pode ser atribuído ao fornecedor, é necessário também considerar como interpretar o dever de cooperação do usuário ao mesmo tempo.

Resumo

O termo “atraso no cumprimento” pode, à primeira vista, parecer uma mera reformulação do facto formal de “atraso na entrega”. No entanto, o atraso no cumprimento é uma forma de incumprimento de uma obrigação. Portanto, é mais apropriado entender isso como uma “violação do dever de gestão de projeto”.

Quando se trata de problemas de “prazo de entrega” em projetos de desenvolvimento de sistemas, é importante não se concentrar apenas na sequência superficial do prazo de entrega, mas reorganizar a questão em termos do dever do fornecedor de gerir o projeto e do dever do utilizador de cooperar.