Um contrato de desenvolvimento de sistema pode ser estabelecido sem um contrato escrito?

No desenvolvimento de sistemas, não é incomum que os desenvolvedores avancem com o trabalho antes de criar um contrato. No entanto, este fluxo de trabalho é, na prática, “perigoso”. Se um contrato não for criado, existe o risco de, em caso de problemas posteriores, o cliente afirmar que “o contrato ainda não foi estabelecido, portanto, não há necessidade de pagar uma remuneração”. Na realidade, em disputas relacionadas ao desenvolvimento de sistemas, não é incomum que a própria formação do contrato seja contestada e que decisões desfavoráveis sejam tomadas para o lado do desenvolvedor. Como desenvolvedor, existe o risco de não receber o pagamento se o cliente cancelar o projeto ou mudar para outra empresa. Além disso, como mencionado posteriormente, mesmo que um contrato seja criado, pode haver casos em que a formação do contrato é negada.

Aqui, explicaremos a validade do contrato de desenvolvimento de sistemas e a estrutura legal para reivindicar dinheiro se a formação do contrato não for reconhecida.

Formação de Contrato

Um contrato é formado, em princípio, quando ambas as partes concordam com os elementos do contrato (a coincidência entre a intenção de aplicar e a intenção de aceitar).

Quando um contrato é formado, ambas as partes são vinculadas por ele e, se uma das partes não cumprir o conteúdo do contrato, a outra parte pode forçar o cumprimento por meio de um processo judicial ou reivindicar indenização por não cumprimento. Os “elementos do contrato” devem ser especificados ou concretos o suficiente para serem o objeto de execução forçada e reconhecimento de não cumprimento.

Formação de Contrato de Desenvolvimento de Sistema

A natureza de um contrato de desenvolvimento de sistema é principalmente um contrato de empreitada e um contrato de mandato. Um contrato de empreitada é uma promessa de conclusão do trabalho e pagamento pela mesma. Um contrato de mandato remunerado é uma promessa de execução do trabalho e pagamento pela mesma.

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

Portanto, se houver um acordo entre as partes sobre os “elementos do contrato”, que são o “conteúdo do trabalho ou serviço” e o “valor da remuneração”, o contrato é considerado formado.

Além disso, um contrato pode ser formado por um simples acordo verbal, e um contrato escrito não é obrigatório.

Reivindicação de Dinheiro no Caso de Cancelamento Após a Formação de um Contrato de Desenvolvimento de Sistema

Se um contrato de desenvolvimento de sistema for formado e o usuário unilateralmente decidir cancelá-lo, legalmente, isso é considerado como uma notificação de rescisão do contrato.

Se um contrato de empreitada for formado, o fornecedor pode ser rescindido pelo usuário a qualquer momento antes da conclusão do trabalho, mas é estipulado que o fornecedor tem o direito de ser indenizado (Artigo 641 do Código Civil Japonês). Portanto, se o usuário não indenizar o fornecedor, este pode reivindicar uma “indenização” pelo valor dos custos incorridos até aquele ponto e a remuneração que teria sido obtida, menos os custos que foram economizados por não ter que concluir o sistema.

Além disso, se um contrato de mandato for formado, o mandatário pode reivindicar remuneração com base na proporção de desempenho quando o mandato termina durante o desempenho (Artigo 648, parágrafo 3, do Código Civil Japonês revisado). Portanto, o fornecedor pode reivindicar o pagamento pelo trabalho já realizado.

Sucesso ou fracasso do contrato de desenvolvimento de sistemas

Especificidade do conteúdo do sistema

Normalmente, as transações entre empresas, especialmente contratos de grande valor, são feitas por escrito, por isso, se um contrato for elaborado, é mais fácil reconhecer a sua formação.

O sistema que é o objeto de desenvolvimento é gradualmente concretizado através de vários processos, por isso a especificidade do conteúdo do sistema, que é um elemento do contrato de empreitada, é entendida como sendo suficiente se o escopo e a visão geral do que se pretende sistematizar forem conhecidos.

Em um caso julgado, não houve disputa sobre a conclusão do contrato básico e do contrato de confidencialidade, e o contrato básico continha uma descrição de que “apoio técnico ao negócio de comércio eletrónico, apoio à construção de sites e negócios relacionados” seriam contratados, mas o conteúdo específico do negócio de comércio eletrónico, o escopo do trabalho contratado, e o escopo do desenvolvimento e design como sistema não foram explicitados, e a formação do contrato foi negada.

Mesmo que um contrato básico de desenvolvimento de sistemas seja elaborado, se o trabalho ou o conteúdo do trabalho for abstrato e não for especificado, será difícil reconhecer a formação do contrato. A formação do contrato pode ser reconhecida por meio de contratos e outros documentos que descrevam especificamente o trabalho ou o conteúdo do trabalho e o valor da remuneração, a ponto de poderem ser usados para forçar o cumprimento e reconhecer o não cumprimento.

Além disso, os pontos a serem observados nos contratos entre engenheiros individuais e corporações são explicados em detalhes no seguinte artigo.

O fornecedor apresenta uma estimativa e especificações, e o usuário aprova e faz o pedido

Normalmente, as transações entre empresas são feitas por escrito, por isso, se um contrato não for elaborado, será difícil reconhecer a formação do contrato. No desenvolvimento de sistemas, muitas vezes o trabalho começa antes de o contrato ser elaborado, mas como é que se pensa sobre o sucesso ou fracasso do contrato nesse caso?

Em um caso julgado (decisão do Tribunal Distrital de Nagoya em 28 de janeiro de 2004), a formação do contrato de empreitada para o desenvolvimento de sistemas foi descrita da seguinte forma:

• Após negociações entre o fornecedor e o usuário para confirmar as especificações, etc.,
• O fornecedor apresenta as especificações e a estimativa, etc.,
• O usuário aprova e faz o pedido, resultando na formação do contrato.

Neste caso julgado, o fornecedor, que foi contratado por uma autoridade local, o usuário, para introduzir um sistema de contabilidade financeira, etc., foi apresentado com um RFP intitulado “Sobre a apresentação de uma proposta para a introdução de um sistema de informação administrativa geral (pedido)”, e apresentou uma proposta e uma estimativa em resposta a isto, e o usuário apresentou uma “notificação de adoção”. O fornecedor não considerou adequadamente o conteúdo do trabalho do usuário, etc., sem ter uma reunião com o usuário, e não foi reconhecido que o conteúdo e o custo da personalização foram considerados especificamente dentro do usuário, e o conteúdo da proposta do fornecedor também não era específico, e não estava claro o que o usuário tinha aprovado, e a formação do contrato não foi reconhecida.

Eu vou explicar em detalhes sobre a formação do contrato mencionada no caso julgado, levando em consideração outros casos julgados, etc.

Após negociações entre o fornecedor e o usuário para confirmar as especificações, etc.

A partir da frase “após negociações”, se o conteúdo do sistema e o valor da remuneração, que são elementos do contrato, estiverem “em negociação”, será difícil reconhecer a formação do contrato, pois não se chegou a um acordo.

No entanto, em um contrato de empreitada, é possível estabelecer o preço como o preço de mercado, por isso há um caso julgado que reconheceu a formação de um contrato de empreitada com um preço equivalente ao preço de mercado, a partir do fato de que o usuário aprovou o conteúdo do sistema e o “valor aproximado” da remuneração, etc.

Para poder dizer que “negociações foram realizadas”, o fornecedor deve ter considerado adequadamente o conteúdo do trabalho do usuário, o conteúdo do sistema, etc., tendo reuniões, etc., com o usuário, e deve ser bom registrar isso em e-mails, atas de reuniões, etc.

O fornecedor apresenta as especificações e a estimativa, etc., e o usuário aprova e faz o pedido

• Se o usuário emitir uma ordem de compra ou um pedido, será mais fácil reconhecer a formação do contrato. Se o fornecedor apresentar um pedido ou realizar trabalho com base em uma ordem de compra, etc., será mais fácil reconhecer a formação do contrato, pois haverá mais “acordo”.
• Os documentos internos do usuário são muitas vezes sobre a intenção de celebrar um contrato no futuro, e é difícil reconhecer a formação do contrato. No entanto, se não houver tal descrição e os elementos do contrato, como o conteúdo do desenvolvimento do sistema e o valor da remuneração, forem descritos o mais concretamente possível, isso funcionará na direção de reconhecer a formação do contrato.
• Memorandos, acordos, e cartas de confirmação são difíceis de reconhecer a formação do contrato se forem baseados na premissa de celebrar um contrato separadamente, ou se o conteúdo for abstrato.
• Se o selo não for colocado no rascunho do contrato, o selo significa a conclusão, e é difícil reconhecer a formação do contrato.
• A estimativa é uma prova para reconhecer o valor da remuneração acordado entre as partes.

Além disso, no desenvolvimento de sistemas, quando o processo avança até certo ponto, e se for solicitada uma mudança de especificações posterior ou a adição de funções, se é possível cobrar um adicional ao valor estimado anteriormente, etc., é explicado em detalhes no seguinte artigo.

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

Acordo de liquidação

Se o trabalho for realizado com base em instruções do usuário com a premissa de celebrar um contrato, no caso de uma parada de trabalho, pode ser reconhecido um “acordo de liquidação” para liquidar a remuneração pelo trabalho até então. Para tornar este acordo mais facilmente reconhecível, seria bom obter a aprovação de uma pessoa autorizada pelo usuário para um documento que descreva o método de liquidação da remuneração no caso de um contrato não ser celebrado, ou para um documento elaborado pelo fornecedor.

Configuração legal para reivindicar dinheiro quando um contrato não é reconhecido

Negligência na celebração do contrato

Quando se inicia negociações para a celebração de um contrato, as partes têm o dever, baseado no princípio da boa fé, de não infringir a propriedade uma da outra (Artigo 1, Parágrafo 2, do Código Civil Japonês). Se o contrato não for celebrado, pode-se reivindicar indenização por danos se houver circunstâncias objetivas que levaram a outra parte a acreditar que a celebração do contrato era certa e se houver culpa. Isto é chamado de negligência na celebração do contrato.

Apresentamos um resumo dos casos em que a negligência na celebração do contrato foi reconhecida em decisões judiciais.

• O fornecedor completou a definição dos requisitos a pedido do usuário e também realizou parte do projeto básico e detalhado. Foi explicado ao fornecedor que a ação de convidar outras empresas para licitar era apenas uma formalidade para obter a aprovação do presidente, mas outra empresa foi escolhida pouco antes da celebração do contrato, e o contrato não foi celebrado.
• O fornecedor avançou com o trabalho a pedido do usuário para cumprir o prazo de entrega, e a data prevista para a celebração do contrato estava próxima. No entanto, a empresa do usuário estava a preparar-se para o desenvolvimento interno, mas isso foi mantido em segredo, e o contrato não foi celebrado.
• O fornecedor foi notificado pelo usuário de que tinha sido escolhido como o construtor, e não houve questões levantadas sobre a estimativa, e o fornecedor realizou trabalhos como a confirmação das especificações com base nas reuniões com o usuário, e o usuário estava ciente dos gastos. No entanto, a celebração do contrato foi recusada com a razão de que não se podia concordar com o valor estimado.

Por outro lado, há casos em que a negligência na celebração do contrato não foi reconhecida, como quando a possibilidade de escolha de outra empresa ou as condições para a celebração do contrato foram explicitamente indicadas.

Se as negociações do contrato forem abruptamente canceladas com a razão de que há a possibilidade de outra empresa ser escolhida ou que as condições de acordo não foram explicitamente indicadas, mesmo que o trabalho tenha sido avançado a pedido do usuário, pode ser possível reivindicar indenização por danos.

Não há disputa de que o “dano” neste caso inclui os custos incorridos até agora. Além disso, há casos em que se considera que o lucro do trabalho realizado está incluído. Além disso, se puder apresentar provas de que sofreu danos equivalentes ao lucro que teria obtido se tivesse recusado uma proposta de outra empresa e continuado a trabalhar a partir de então, isso também pode ser incluído.

Artigo 512 do Código Comercial Japonês

O fornecedor pode reivindicar uma remuneração razoável com base no Artigo 512 do Código Comercial Japonês, se tiver realizado ações relacionadas ao desenvolvimento do sistema para o usuário.

Quando se inicia negociações sobre o desenvolvimento do sistema, é bom deixar provas que confirmem que ambas as partes reconheceram o conteúdo do sistema e o valor da remuneração, usando e-mails e atas de reuniões, e que havia circunstâncias que faziam pensar que a celebração do contrato era certa e que os elementos do contrato foram concretizados.

Na verdade, mesmo se o pagamento for recusado com a razão de que não foi assinado um contrato, como mencionado acima, pode ser possível reivindicar dinheiro.

Resumo

Como tal, pode-se dizer que os tribunais tendem a fazer um julgamento “negativo” em relação às relações contratuais quando não existe um contrato escrito, pelo menos em comparação com a percepção da empresa contratada. Do ponto de vista da empresa contratada, gostariam de dizer “Eu deveria ter começado a trabalhar primeiro e o contrato deveria ter sido concluído posteriormente, então o contrato está em vigor”, mas este argumento nem sempre é aceite.

Além disso, se a formação do contrato for negada, como mencionado acima, existem casos em que se pode solicitar dinheiro com base em negligência na celebração do contrato ou no Artigo 512 do Código Comercial Japonês, mas isso também não é uma “certeza”.

Se for necessário iniciar o trabalho antes da celebração do contrato, é necessário:

• Primeiro, é uma ação arriscada, e mesmo considerando esse risco, é necessário fazer um julgamento de gestão sobre se deve ou não usar o tempo para esse projeto (especialmente no caso de pequenas e médias empresas e startups, se estiverem a receber um projeto de uma grande empresa, há situações em que têm de tomar a decisão de gestão de “mover-se primeiro” para obter um histórico de transações com essa grande empresa. Isso é uma decisão de gestão possível se o risco for levado em conta.)
• Considerar se não é possível celebrar um acordo de liquidação em caso de não conclusão do contrato

Pode-se dizer que é necessário fazer esse tipo de pensamento.