Qual é o método de lidar com a interrupção do trabalho de desenvolvimento do sistema devido à conveniência do usuário?

O trabalho de desenvolvimento de sistemas geralmente assume a forma de um projeto de longo prazo. Então, se o usuário unilateralmente disser algo como “já não precisamos desse sistema, não precisa ser criado” para um desenvolvimento de sistema que já começou, o que pode ser feito pelo fornecedor que aceitou o trabalho?

Neste artigo, vamos organizar as características únicas do contrato de desenvolvimento de sistemas e explicar as medidas a serem tomadas nesse caso.

A importância de considerar interrupções devido a conveniências do utilizador

Existem vários pontos característicos quando se olha para um contrato de desenvolvimento de sistemas. Um deles é que o prazo normalmente é longo e, como parte da obrigação de gerir o projeto, o fornecedor tem uma grande discricionariedade e assume uma grande responsabilidade. O conteúdo geral das obrigações de gestão de projetos que o fornecedor assume é explicado em detalhe no seguinte artigo.

https://monolith.law/corporate/project-management-duties[ja]

Outro ponto é que o utilizador, mesmo sendo um cliente, tem uma ampla obrigação de cooperar com o trabalho do fornecedor. Como se trata de um sistema a ser usado internamente, não é suficiente simplesmente “delegar” ao fornecedor. Há uma obrigação de cooperar adequadamente para que o fornecedor possa exercer a sua especialidade no trabalho, mesmo a partir do interior da empresa. Isto é explicado em detalhe no seguinte artigo.

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

Resumindo o conteúdo acima, entre o fornecedor e o utilizador, além da relação de troca entre o “prestador de serviços externo” que desenvolve o sistema e o “cliente” que paga a remuneração, há também um aspecto de “companheiros” que devem colaborar para alcançar o objetivo comum do projeto. Esta complexidade da relação não é normalmente encontrada em simples alfaiates de fatos feitos por medida, por exemplo, e é uma grande característica dos contratos relacionados com o desenvolvimento de sistemas. Os conflitos relacionados com o desenvolvimento de sistemas são, devido a esta complexidade da relação, propensos a complicar-se quando se trata de como organizar legalmente a relação entre as duas partes, uma vez que se tornam emaranhados.

Considerar a questão de como entender a relação de direitos e obrigações entre as duas partes quando o utilizador muda de ideia e de repente diz “Afinal, não precisamos desse sistema, por isso não precisamos continuar com o projeto” tem o significado de apresentar um exemplo real de pensamento jurídico perante esta complexa relação contratual. A seguir, organizaremos as questões a serem consideradas após assumir tal situação.

Primeiro, organize as razões para o pedido de rescisão

Do ponto de vista do fornecedor, pode haver casos em que o “utilizador quer interromper unilateralmente o projeto”, mas essa percepção pode não ser necessariamente partilhada com o utilizador. Por exemplo, suponha um caso em que um projeto estava em andamento para desenvolver um sistema para gerir o pessoal destacado para trabalhar em bases estrangeiras, mas depois o próprio plano de expansão para o estrangeiro foi retirado, tornando o desenvolvimento desse sistema desnecessário. Certamente, com base apenas nesta explicação, pode parecer que o utilizador mudou de ideia unilateralmente.

Contudo, e se houvesse uma realidade de violação das obrigações de gestão do projeto, como atrasos em cada etapa, por parte do fornecedor, e o progresso do próprio desenvolvimento estava a ser difícil, o que também contribuiu para a mudança de política da empresa?

Como mencionado anteriormente, o desenvolvimento de sistemas é algo que tanto o fornecedor como o utilizador assumem grandes obrigações e avançam em estreita colaboração. Portanto, mesmo que o utilizador tenha iniciado a interrupção e o fornecedor pense que é uma rescisão por conveniência do utilizador, deve-se estar ciente de que pode haver uma possibilidade de ser apontado como uma causa atribuível ao fornecedor e ser reivindicado como uma rescisão baseada em incumprimento de obrigações ou rescisão por acordo mútuo.

A distinção entre se é uma rescisão por conveniência própria, uma rescisão baseada em incumprimento de obrigações, ou uma rescisão por acordo mútuo, tende a ser julgada individualmente para cada caso, dependendo do progresso do projeto e do histórico de negociações até então. Portanto, se o fornecedor avançar com o processamento pós-evento sob a percepção de que é uma rescisão por conveniência do utilizador, é importante garantir que isso seja claramente registado em atas de reuniões, etc., para evitar disputas sobre este ponto mais tarde.

Confirmação das cláusulas de base para reivindicações de remuneração e indemnizações por danos

Com base nos pontos acima, se a conversa puder prosseguir como um cancelamento por conveniência do usuário, a próxima etapa é considerar se o fornecedor pode ou não reivindicar ao usuário uma remuneração proporcional ao trabalho concluído ou uma indemnização por danos.

As cláusulas a serem referidas nestes casos variam de acordo com o tipo de contrato. Isto porque os contratos de desenvolvimento de sistemas podem ser amplamente distinguidos em contratos de empreitada e contratos de mandato.

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

E, no caso de contratos de mandato e contratos de empreitada, o Código Civil Japonês estabelece o seguinte:

a.) No caso de um contrato de mandato
Reivindicação de remuneração: Artigo 648, parágrafo 3, do Código Civil Japonês
Quando o desempenho termina a meio do caminho devido a uma causa que não pode ser atribuída ao mandatário, o mandatário pode reivindicar uma remuneração proporcional ao desempenho já realizado.
Reivindicação de indemnização por danos: Artigo 651 do Código Civil Japonês
1. O mandato pode ser revogado a qualquer momento por qualquer das partes.
2. Se uma das partes revogar o mandato em um momento desvantajoso para a outra parte, essa parte deve indemnizar a outra parte pelos danos. No entanto, isto não se aplica se houver uma razão inevitável.

b.) No caso de um contrato de empreitada
Reivindicação de indemnização por danos: Artigo 641 do Código Civil Japonês
Enquanto o empreiteiro não completar o trabalho, o cliente pode a qualquer momento indemnizar os danos e rescindir o contrato.

Além disso, acredita-se que o alcance da indemnização por danos com base no Artigo 641 do Código Civil Japonês inclui não apenas os custos já incorridos, mas também “os lucros que teriam sido obtidos se o contrato não tivesse sido rescindido”. Isto reflete a ideia de que é inútil a lei forçar a conclusão de um trabalho que se tornou desnecessário para o cliente, e que, nesses casos, é mais razoável garantir o lucro do lado do empreiteiro através do pagamento de uma compensação equivalente.

No entanto, em relação à indemnização por danos com base no Artigo 641 do Código Civil Japonês, muitas vezes acontece que, em contratos individuais entre fornecedores e usuários, certos danos são excluídos da indemnização. Nesses casos, a promessa individual (= contrato) feita entre as partes prevalece, e é possível que as disposições do Código Civil Japonês não se apliquem, portanto, é necessário ter cuidado.

Avançar com a prova de volume de negócios e danos

No caso de rescisão por conveniência do utilizador, é comum que o contrato estipule que se pode solicitar a cobrança de taxas de comissão pelo volume de negócios (ou seja, a parte concluída) e a indemnização por danos. Portanto, normalmente, o fornecedor precisa provar o volume de negócios e os danos para fazer uma reivindicação de indemnização.

No entanto, a prova do volume de negócios, ou seja, a percentagem de conclusão, pode ser um trabalho muito difícil se for realmente realizado. Isto porque, especialmente quando existem vários subcontratados, é previsível que a quantidade de entrevistas para verificar o progresso, se realmente realizadas, seja considerável. Além disso, se tiver que criar documentos para apoiar os resultados das entrevistas e documentar o conteúdo das entrevistas, o trabalho será enorme. Se, apesar de todo esse esforço, ainda houver risco de a prova ser considerada insuficiente, o trabalho gasto na preparação da prova pode ser em vão, entre outras dificuldades.

Considerando estes pontos, uma medida possível seria, desde o início da fase de contrato, especificar que, em caso de rescisão a meio do caminho, o cálculo será feito pro rata com base no número de dias até ao momento da rescisão, de modo a simplificar o cálculo. Além disso, considerando o trabalho envolvido na prova do volume de negócios, pode-se considerar a renúncia à reivindicação do volume de negócios em si e a adoção de uma abordagem que envolva a reivindicação dos “custos incorridos no desenvolvimento da parte já concluída”. Se os custos de desenvolvimento forem internos, muitas vezes é possível calcular facilmente com uma fórmula simples de “horas de trabalho x taxa”. Especialmente em projetos com baixa margem de lucro, ao priorizar a cobrança com base nos custos em vez do volume de negócios, pode-se esperar compensar as perdas enquanto se facilita a recuperação de créditos, o que pode ser uma medida de alívio mais realista em muitos casos.

O que deve ser considerado do lado do utilizador?

A propósito, também há pontos que devem ser considerados antecipadamente pelo lado do utilizador que inicia o cancelamento por sua própria conveniência. Isso é, entre o utilizador e o fornecedor, verificar antecipadamente o montante aproximado de indemnização a ser pago, como quanto provavelmente será. O termo “aproximado” é usado aqui para dar uma ideia geral e orientar o fluxo das negociações subsequentes (como o atraso na expressão da intenção de cancelamento seria contraproducente, um valor exato não é necessário).

Se o montante aproximado verificado for considerado excessivamente alto, deve-se pedir uma explicação, mas se tentar negociar de forma irracional para reduzir o montante a pagar, também há o risco de surgirem litígios desnecessários e a situação se tornar ainda mais complicada. Se as negociações entre as duas partes parecerem difíceis, consultar um advogado pode ser uma opção.

Além disso, neste artigo, explicamos com base na premissa de que um contrato para o desenvolvimento do sistema está em vigor, mas na realidade do desenvolvimento do sistema, muitas vezes há disputas sobre se o contrato foi efetivamente estabelecido. Detalhes sobre isso são explicados no artigo abaixo.

https://monolith.law/corporate/system-development-contract[ja]

Resumo

Neste artigo, explicamos o processo de lidar com casos de interrupção de projetos devido a circunstâncias do utilizador. No entanto, o ponto principal deste artigo é a necessidade de considerar se realmente se pode atribuir a situação à vontade do utilizador e se o fornecedor não teve realmente nenhuma falha.

Um projeto de desenvolvimento de sistemas é caracterizado pelo facto de tanto o fornecedor como o utilizador assumirem grandes responsabilidades. Dado isto, é necessário considerar cuidadosamente se é realmente possível atribuir a culpa unilateralmente à outra parte. Se não o fizermos, podemos acabar por agravar a situação, o que deve ser levado em conta.