Diferenças e distinções entre contratos de empreitada e contratos de quase-delegação em desenvolvimento de sistemas

Na encomenda e recepção do desenvolvimento de sistemas, são trocados contratos com vários títulos, como contrato de comissão, contrato de trabalho comissionado, contrato de desenvolvimento de sistemas, entre outros.

Na lei, distingue-se entre contratos em que uma das partes assume um serviço (como o desenvolvimento de trabalho, por exemplo) e a outra paga uma remuneração por isso, diferenciando entre contratos de empreitada e contratos de mandato.

Em poucas palavras, temos:

• Contrato de empreitada: um contrato que permite receber uma remuneração pela entrega do que foi prometido

• Contrato de mandato: um contrato que envolve receber uma remuneração e fazer o melhor esforço correspondente a essa remuneração

É isso.

Desenvolvimento de Sistemas: Contrato de Prestação de Serviços ou Contrato de Mandato?

O desenvolvimento de sistemas tem como objetivo criar um “produto acordado”, que, de acordo com a distinção acima, pode ser considerado um contrato de prestação de serviços. No entanto, a situação não é tão simples. O desenvolvimento de sistemas difere ligeiramente de um contrato de prestação de serviços típico, como previsto pela lei.

Um contrato de prestação de serviços típico é, por exemplo, um fato feito por medida. No caso de um fato, uma vez que as dimensões são decididas, é fácil para as partes envolvidas imaginar o produto final, e é fácil julgar se o produto final corresponde ao pedido. Em contraste, no desenvolvimento de sistemas, normalmente não existem documentos que facilitem a compreensão da imagem geral do sistema, e pode-se dizer que é difícil para o cliente entender a imagem geral. Além disso, o sistema a ser desenvolvido tem a particularidade de ser gradualmente concretizado através de processos de natureza diferente.

Portanto, a natureza do contrato numa certa fase do desenvolvimento do sistema, especialmente na fase inicial, muitas vezes levanta a questão de se é um “contrato de prestação de serviços” que promete a conclusão do trabalho, ou um “contrato de mandato” que se esforça para o melhor. Dependendo desta distinção, se o trabalho não for concluído, a remuneração que a empresa de desenvolvimento de sistemas pode receber pode ser reduzida a zero, o que pode levar a uma das partes a ser forçada a assumir uma carga financeira excessiva e substancial. Portanto, é importante distinguir qual contrato se aplica.

Assim, explicaremos a diferença entre o contrato de prestação de serviços e o contrato de mandato, qual contrato deve ser celebrado e os critérios para distinguir entre os dois.

Diferenças entre o Contrato de Empreitada e o Contrato de Quase-Mandato

Primeiro, vamos explicar as diferenças entre as disposições do Contrato de Empreitada e do Contrato de Quase-Mandato no Código Civil Japonês, bem como o tratamento no caso de um contrato especial.

Recebimento de remuneração, rescisão, responsabilidade por defeitos, subcontratação e contrato especial no Contrato de Empreitada

O Contrato de Empreitada é um contrato em que uma das partes (empreiteiro/fornecedor) promete completar um determinado trabalho, e a outra parte (cliente/utilizador) promete dar uma recompensa (preço da empreitada) pelo resultado desse trabalho.

“Conclusão do trabalho” pode incluir a criação de produtos finais que são acordados por ambas as partes, como “planos”, “documentos de definição de requisitos”, “documentos de design básico”, “programas”, “sistemas”, etc.

Recebimento de remuneração

Se o trabalho não for concluído, o empreiteiro/fornecedor não poderá receber a remuneração. Se quiser ser pago antes da conclusão do trabalho, será necessário fazer um contrato especial de pagamento antecipado. No caso de projetos de desenvolvimento de sistemas baseados em contratos de empreitada, a “conclusão do trabalho” é um conceito muito importante. Este conceito é explicado em detalhe no seguinte artigo.

Além disso, a “conclusão do trabalho” mencionada aqui é normalmente reconhecida após a “inspeção” no caso do desenvolvimento de sistemas.

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

Mesmo que um contrato especial seja feito, se o trabalho não for concluído devido à interrupção do projeto, o empreiteiro/fornecedor deve devolver a remuneração já recebida ao cliente/utilizador como um ganho sem causa. Esta é a maior diferença em relação ao Contrato de Quase-Mandato.

Rescisão

Se não houver incumprimento de obrigações (violação de promessas) por ambas as partes, o cliente/utilizador pode rescindir o contrato a qualquer momento antes da conclusão do trabalho, indemnizando o empreiteiro/fornecedor. Neste caso, o “dano” é o montante que é a diferença entre o custo que o empreiteiro/fornecedor gastou e a remuneração que ele teria recebido, menos o custo que ele pôde economizar por ser liberado da obrigação de concluir o trabalho. Por outro lado, o empreiteiro/fornecedor não pode rescindir o contrato.

Se um contrato especial for feito para que o contrato não possa ser rescindido a menos que haja incumprimento de obrigações por parte da outra parte, o empreiteiro/fornecedor não correrá o risco de ser rescindido a qualquer momento, mesmo que não haja violação do contrato.

Responsabilidade por defeitos

Se houver defeitos no objeto do trabalho, o cliente pode solicitar a reparação dos defeitos, reivindicar indenização por danos, e pode rescindir o contrato se o objetivo do contrato não puder ser alcançado.

Um “defeito” significa uma falha ou defeito, e é reconhecido quando a qualidade ou desempenho que o objeto deve ter de acordo com o propósito do contrato está faltando. Um “defeito” ocorre quando o sistema não atinge as especificações ou desempenho prometidos após a conclusão do último processo planejado no contrato.

Em um caso judicial, foi decidido que um bug relacionado ao vazamento de informações pessoais no sistema de construção de uma universidade não era um “defeito”, mas a falta de controle exclusivo, que é essencial para o sistema em questão, era um “defeito”. É possível fazer um contrato especial para não assumir a responsabilidade por defeitos, ou para encurtar o período de responsabilidade por defeitos.

Além disso, a responsabilidade por defeitos é explicada em detalhe no seguinte artigo.

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

Subcontratação

O empreiteiro/fornecedor pode subcontratar livremente. Se um contrato especial for feito para proibir a subcontratação, a subcontratação não será permitida.

Recebimento de remuneração, rescisão, responsabilidade por defeitos, subcontratação e contrato especial no Contrato de Quase-Mandato

O Contrato de Quase-Mandato é um contrato em que uma pessoa (mandatário/fornecedor) realiza o processamento de negócios que foi confiado a ela por outra pessoa (mandante/utilizador). E o mandatário tem o dever de exercer a habilidade que possui e realizar o trabalho de forma razoável, que é o dever de cuidado de um bom gerente. Em outras palavras, é “fazer o melhor possível”.

Um exemplo típico é o ato médico, que promete fornecer um nível de tratamento acima do padrão no processo de tratamento, mas não assume a responsabilidade pelo resultado da cura.

A grande diferença em relação ao Contrato de Empreitada é que não é necessário assumir a responsabilidade pelo resultado do trabalho.

Recebimento de remuneração

Diferentemente do Contrato de Empreitada, mesmo que o trabalho não seja concluído, se o processamento de negócios for realizado adequadamente, o mandatário/fornecedor poderá receber a remuneração. Além disso, se o mandato terminar no meio do desempenho devido a uma causa que não pode ser atribuída ao mandatário, o mandatário pode solicitar a remuneração de acordo com a proporção do desempenho já realizado.

Além disso, na revisão da Lei das Obrigações anunciada em 2017 (implementada em abril de 2020), foi estabelecida uma disposição que permite que a remuneração seja paga pelos resultados alcançados, mesmo no caso de um Quase-Mandato, e que a remuneração pode ser solicitada após a conclusão dos resultados, em princípio.

Além disso, se é possível aumentar a remuneração que foi decidida uma vez, levando em consideração o curso do desenvolvimento do sistema, é explicado em detalhe em outro artigo.

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

Rescisão

Mesmo que não haja incumprimento de obrigações por parte da outra parte, tanto o mandante/utilizador como o mandatário/fornecedor, ao contrário do Contrato de Empreitada, podem rescindir o contrato a qualquer momento.

Se um contrato especial for feito para que o contrato não possa ser rescindido a menos que haja incumprimento de obrigações por parte da outra parte, o risco de ser rescindido a qualquer momento sem motivo será eliminado.

Os problemas legais quando o desenvolvimento do sistema é interrompido devido à conveniência do utilizador são explicados em detalhe no seguinte artigo.

Responsabilidade por defeitos

Não há disposição para a responsabilidade por defeitos, ao contrário do Contrato de Empreitada. “Responsabilidade por defeitos” e “inspeção” mencionados anteriormente são conceitos que aparecem apenas no caso de um Contrato de Empreitada, e são bastante conhecidos como termos legais relacionados ao desenvolvimento de sistemas. No entanto, o mandatário tem o dever de “fazer o melhor possível”, e se ele não realizar o trabalho de forma razoável, pode haver um pedido de indenização por danos ou rescisão com base no incumprimento de obrigações.

Em particular, as obrigações que o fornecedor deve cumprir no desenvolvimento de sistemas incluem a obrigação de gestão de projetos.

Subcontratação

O mandatário/fornecedor, ao contrário do Contrato de Empreitada, não pode, em princípio, subcontratar. Se quiser subcontratar, terá de fazer um contrato especial para esse efeito.

Esta parte é muitas vezes um problema na prática e requer cuidado. Se você contratar um projeto de desenvolvimento de tipo Quase-Mandato sem um contrato especial para permitir a subcontratação, pensando que “como é o desenvolvimento de um sistema, a subcontratação deve ser possível a menos que seja especificamente mencionado”, você pode acabar em uma situação onde o fato de ter subcontratado em si é considerado uma violação do contrato.

O cliente/utilizador, que é o ordenante, também tem obrigações

Embora a discussão até agora tenha sido principalmente sobre as obrigações do fornecedor, que é o contratado, no cenário de desenvolvimento de sistemas, que requer muita mão-de-obra e tempo, o cliente/utilizador, que é o ordenante, também tem uma certa “obrigação de cooperação”. Este ponto é explicado em detalhe em outro artigo.

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

Como escolher entre um contrato de empreitada e um contrato de quase-mandato

Vantagens e desvantagens para a empresa de desenvolvimento/fornecedor

Para a empresa de desenvolvimento/fornecedor, a vantagem de optar por um “contrato de empreitada” é que, se conseguirem fazer bem o trabalho com menos pessoas, podem ganhar mais do que com um quase-mandato. Ao contrário do quase-mandato, a empreitada tem a “obrigação de completar” o trabalho, o que significa que, mesmo que reduzam o número de pessoas ou melhorem a eficiência do trabalho e consigam manter os custos baixos, desde que completem o trabalho, terão cumprido a sua obrigação.

As desvantagens são:

• Não poder garantir a remuneração até que o trabalho esteja concluído
• Se surgirem horas de trabalho não previstas inicialmente para completar o trabalho que atenda aos requisitos, poderão surgir custos adicionais de trabalho, o que pode resultar em prejuízo
• Assumir a responsabilidade pela garantia de defeitos
• Se surgirem horas de trabalho não previstas inicialmente para completar o trabalho que atenda aos requisitos, mesmo que surjam custos adicionais de trabalho, poderão surgir custos adicionais de trabalho que excedam o previsto, o que pode resultar em prejuízo
• Assumir a responsabilidade pela garantia de defeitos

Estes são os pontos a considerar.

As vantagens de optar por um “contrato de quase-mandato” são as seguintes:

• Poder receber pagamento mesmo que o trabalho não esteja concluído
• Poder receber pagamento pelas horas de trabalho adicionais
• Não ter que assumir a pesada responsabilidade de completar o trabalho e produzir algo sem defeitos
• Ao contrário da empreitada, o quase-mandato tem a “obrigação de fazer um esforço que corresponda à remuneração”, o que torna mais fácil prever os custos necessários para cumprir essa obrigação

Vantagens e desvantagens para o cliente/utilizador

Para o cliente/utilizador, as vantagens de optar por um “contrato de empreitada” são as seguintes:

• Não ter que pagar até que o trabalho esteja concluído (pode ser reembolsado mesmo que tenha pago antecipadamente)
• A remuneração a ser paga é fixa, por isso não há custos adicionais de trabalho devido a horas de trabalho adicionais

A desvantagem é que pode ser apresentado um orçamento elevado para evitar o risco de perdas.

A vantagem de optar por um “contrato de quase-mandato” é que pode esperar um orçamento mais baixo do que o da empreitada. A desvantagem é que não pode fazer com que o contratado/fornecedor assuma a responsabilidade de completar o trabalho, e se surgirem horas de trabalho não previstas inicialmente, poderão surgir custos adicionais de trabalho.

Casos judiciais

Existem casos judiciais em que se considerou que era um contrato de quase-mandato até à confirmação da definição dos requisitos e do desenho básico, e casos em que se considerou que era um contrato de empreitada para o trabalho a partir do desenho básico até ao teste unitário.

Deve celebrar um contrato de empreitada ou um contrato de quase-mandato?

Pode considerar-se a celebração de um contrato de modelo de acordo com o processo, mas a dificuldade e o conteúdo do desenvolvimento, o montante que deseja receber/que pode preparar, a intenção da outra parte e a relação de poder entre as duas partes, e se pode ou não imaginar o produto final e incluí-lo no contrato, devem ser decididos e negociados com base em circunstâncias individuais em cada empresa, do ponto de vista da gestão e do direito.

Para questões legais e pontos a considerar no caso de não pagamento da remuneração, consulte o artigo abaixo para uma explicação detalhada.

Critérios para distinguir entre um contrato de empreitada e um contrato de quase-mandato

O que é a determinação da natureza do contrato

“Determinar se a natureza do contrato é um contrato de empreitada ou um contrato de quase-mandato” é uma questão que surge em que contexto e que tipo de problema é,

Se o contrato (relativo ao trabalho em questão) é um contrato de empreitada ou um contrato de quase-mandato, e se não houve um acordo explícito entre as partes, ou seja, se não foi feito um contrato especial e se essa cláusula não foi incluída no contrato, qual das disposições do tipo de contrato estabelecidas no Código Civil Japonês se aplica, será baseado numa decisão posterior sobre “qual é o tipo de contrato”, e essa decisão será tomada com base num certo critério de decisão

É isso.

Além disso, isto é,

1. Assumindo que um contrato relativo ao desenvolvimento do sistema foi estabelecido
2. Se esse contrato é um contrato de empreitada ou um contrato de quase-mandato

Esta é a questão, mas antes desta questão, há a questão de “se um contrato relativo ao desenvolvimento do sistema foi realmente estabelecido”. Este ponto é explicado em detalhe num artigo separado.

E, assumindo que o desenvolvimento do sistema foi estabelecido, como mencionado acima em 2, a questão de qual contrato se aplica, leva à decisão de qual das partes irá suportar uma quantidade excessiva de dinheiro, e torna-se um grande problema.

Não é incomum que não haja uma indicação clara de “empreitada” ou “quase-mandato” no contrato, ou mesmo que haja uma indicação, a substância é diferente, e há uma discrepância na compreensão entre as partes. Portanto, vou explicar os critérios para distinguir entre um contrato de empreitada e um contrato de quase-mandato.

A natureza do contrato é determinada considerando vários elementos

Para determinar a natureza do contrato, olhamos para o contrato como um todo e consideramos se o seu objetivo é “fornecer o produto acabado” ou se o fornecedor “executa o trabalho de forma razoável”. O ponto é se o conteúdo do objeto a ser concluído foi determinado de forma concreta e se o projeto estava progredindo em direção a ele.

Os seguintes elementos são considerados em conjunto para determinar a natureza do contrato.

Desempenho da empresa de desenvolvimento

Se houver um histórico de criação de sistemas do mesmo nível ou superior, é provável que seja considerado que “era esperado que fosse concluído naturalmente, que a conclusão era uma obrigação, e que havia um acordo de que o pagamento seria feito após a conclusão”, e é mais provável que seja um contrato de empreitada

Se o objetivo no cronograma é “conclusão”

Se for a conclusão, é provável que seja considerado que “era uma obrigação concluir”, e é mais provável que seja um contrato de empreitada

Clareza do conteúdo do produto no contrato e no contrato

Quanto mais claro, mais provável é que seja considerado que “era esperado que algo com requisitos claros fosse concluído”, e é mais provável que seja um contrato de empreitada

Se a remuneração é baseada num preço unitário

Se sim, é provável que seja considerado que “havia um entendimento de que a remuneração seria gerada após a conclusão, e que era uma obrigação concluir”, e é mais provável que seja um contrato de empreitada

Se a remuneração é paga após a conclusão

Se sim, é provável que seja considerado que “era uma obrigação concluir”, e é mais provável que seja um contrato de empreitada

Existência de cláusulas de aceitação, responsabilidade por defeitos e garantias

Se existirem, é provável que seja considerado que “era uma obrigação concluir” e “cláusulas como aceitação, responsabilidade por defeitos e garantias foram preparadas com base nisso”, e é mais provável que seja um contrato de empreitada

Existência de linguagem de empreitada ou quase-mandato

Claro, a linguagem também é um importante elemento de consideração. No entanto, a decisão não é simplesmente baseada na linguagem de “empreitada” ou “quase-mandato”, por isso é necessário ter cuidado na redação do contrato.

Além disso, tais decisões são feitas não apenas com base no contrato, mas também com base em evidências como as atas que foram criadas durante o processo de desenvolvimento do sistema. A importância das atas é explicada em detalhe no seguinte artigo.

Resumo

“Subcontratação” e “quase-delegação” podem parecer semelhantes, mas os seus efeitos legais são completamente diferentes. Ao estabelecer um contrato, é aconselhável procurar o conselho de um especialista. O nosso escritório possui conhecimento avançado em casos como o desenvolvimento de sistemas subcontratados. Não hesite em nos consultar.