Qual é a lei no caso de não pagamento da recompensa pelo desenvolvimento do sistema?

Para os fornecedores que assumem o trabalho de desenvolvimento de sistemas, um dos maiores riscos, em certo sentido, pode ser a situação em que “apesar de terem entregue o produto, o utilizador não paga a recompensa”. Os custos de desenvolvimento de sistemas são muitas vezes elevados devido à necessidade de pessoal qualificado, incluindo programadores. A falha na recuperação de vendas pode por vezes tornar-se uma questão de vida ou morte. Neste artigo, assumindo o caso em que o utilizador não responde ao pagamento da recompensa, discutiremos os pontos que o fornecedor deve considerar do ponto de vista legal.

Primeiro, é necessário verificar se é possível solicitar o pagamento

• O fornecedor entregou o produto ao utilizador, mas o utilizador não aceita a entrega, o que atrasa o processo de faturação
• Apesar de se acreditar que a aceitação estava concluída, há algum desacordo com a percepção do utilizador, que se recusa a pagar

Estas situações são bastante possíveis na realidade.

Além disso, o termo usado no desenvolvimento de sistemas para o utilizador verificar as especificações do sistema concluído e aceitar a entrega é “aceitação”. O significado e as questões a considerar quando o progresso da aceitação não é satisfatório são explicados em detalhe no seguinte artigo.

Artigo relacionado: Aplicação e cenários da cláusula de aceitação presumida no desenvolvimento de sistemas[ja]

Embora a explicação geral sobre a aceitação seja deixada para o artigo acima, do ponto de vista legal, é necessário considerar se a aceitação do utilizador foi concluída, levando em conta as disposições da “cláusula de aceitação presumida”.

Com isso em mente, o primeiro ponto a considerar ao lidar com um caso em que o utilizador se recusa a pagar é o seguinte:

1. Se o trabalho foi concluído ou ainda está inacabado
2. Se a responsabilidade pela garantia de defeitos (Artigo 635 do Código Civil Japonês) é aplicável ou não

A razão pela qual a verificação dos dois pontos acima deve ser feita em primeiro lugar é que, a menos que se confirme antecipadamente que o trabalho foi concluído e que a responsabilidade pela garantia de defeitos (Artigo 635 do Código Civil Japonês) não se aplica, mesmo que se inicie um processo judicial, não se pode esperar que o pagamento seja feito.

Então, o que o responsável do lado do fornecedor deve verificar para considerar os dois pontos acima? Vamos ver quais documentos devem ser verificados.

Documentos a verificar para determinar a possibilidade de cobrança de honorários

Além disso, temos um artigo separado que explica em detalhe como gerir as alterações nas especificações do sistema a ser desenvolvido e como criar um documento de gestão de alterações.

Artigo relacionado: Como gerir as alterações no desenvolvimento de sistemas do ponto de vista jurídico[ja]

Em seguida, verifique quanto pode ser cobrado

Em princípio, o valor que pode ser cobrado deve estar indicado no contrato. No entanto, pode haver situações em que não existe um contrato adequado (ou um documento equivalente) se houver alterações nas especificações ou algo semelhante após o facto. Explicamos em detalhe no artigo abaixo sobre como recalcular a estimativa com base em razões subsequentes, como alterações nas especificações e adição de funcionalidades.

Artigo relacionado: É possível aumentar o valor estimado do desenvolvimento do sistema após o facto?[ja]

Embora o método de recálculo da estimativa seja conforme descrito neste artigo, especialmente do ponto de vista de considerar se é possível aumentar o valor a ser cobrado,

1. A existência e o conteúdo da estimativa para o desenvolvimento adicional e a correção da funcionalidade
2. A reação do usuário à estimativa
3. A existência de um acordo sobre a situação que causou o desenvolvimento adicional e a correção da funcionalidade listada na tabela de gestão de problemas e o valor correspondente

Estes são os pontos principais a considerar. Em outras palavras, o processo envolve verificar se houve um acordo com o usuário sobre “encomendar o trabalho por esse valor” (ou seja, se um contrato foi estabelecido).

Por fim, considerando as questões pendentes ao realizar um processo

Atenção à possibilidade de uma reivindicação de contra-ação

No desenvolvimento de sistemas, não é incomum que, quando um dos lados (usuário ou fornecedor) inicia um processo contra o outro, este último responda com uma contra-ação. Ou seja, em situações onde o pagamento da remuneração não é feito, pode haver algum argumento do lado do usuário.

Em primeiro lugar, o desenvolvimento de sistemas implica que o lado do usuário também tem várias obrigações de cooperação, mas não devemos esquecer que, como ponto de partida, o lado do fornecedor, como especialista em desenvolvimento de sistemas, tem uma ampla margem de manobra e uma grande responsabilidade. Detalhamos as obrigações de gestão de projetos que o fornecedor tem em relação ao desenvolvimento de sistemas no seguinte artigo.

Artigo relacionado: O que são as obrigações de gestão de projetos no desenvolvimento de sistemas[ja]

Portanto, é necessário considerar cuidadosamente se é possível atribuir a culpa ao lado do usuário que unilateralmente não paga a remuneração. Ao olhar para os precedentes judiciais, há muitos casos em que, embora o fornecedor tenha inicialmente iniciado um processo para solicitar o pagamento da remuneração, o usuário, por sua vez, fez reivindicações para a restauração do status quo e indenização por danos.

É necessário considerar se realmente há benefícios comerciais

Mesmo que a argumentação do fornecedor seja aceite e seja reconhecido em tribunal que é possível solicitar a remuneração, se a situação se tornar contenciosa a ponto de levar a um processo, é previsível que a continuação das transações futuras se torne praticamente difícil. Além disso, mesmo que a sua argumentação seja aceite em tribunal, deve estar preparado para o facto de que pode levar bastante tempo até que a remuneração seja realmente recebida. Se considerarmos também o tempo e o custo envolvidos na realização de um processo, muitas vezes pode ser mais sensato e melhor fazer um esforço para encontrar um ponto de compromisso.

Resumo

Se um utilizador não cumprir com o pagamento de uma recompensa, a análise legal dessa questão requer a verificação de vários tipos de documentos. Além disso, não basta apenas ter uma boa gestão de documentos, também é necessário considerar os riscos e desvantagens organizacionais que podem surgir se decidir avançar para um processo judicial.

A gestão rigorosa dos documentos no dia-a-dia é, sem dúvida, normalmente uma tarefa a nível operacional. No entanto, se decidir avançar para um processo judicial com base nos documentos e materiais armazenados, isso pode tornar-se numa decisão de gestão significativa. Deve-se entender todo o processo, juntamente com o facto de que é nestas situações irregulares que a coesão e a força organizacional entre a gestão e a equipa operacional são postas à prova.