Quais são as medidas a tomar quando se descobre um problema no sistema após a aceitação?

Em termos gerais, o desenvolvimento de sistemas envolve a implementação de um programa de acordo com o conteúdo decidido na fase de definição de requisitos. No final, tanto o utilizador como o fornecedor verificam se o produto final está de acordo com as especificações e, se passar na inspeção, o processo é considerado concluído.

Contudo, na realidade, é perfeitamente possível que bugs ou falhas que não foram detetados durante a fase de teste e inspeção venham a ser descobertos durante a fase de operação subsequente. Se já aceitou a entrega, o que pode legalmente exigir?

Não é surpreendente que ainda existam bugs após a aprovação da aceitação ou após o processo de teste

Do ponto de vista técnico, não é incomum que vários bugs e problemas sejam revelados após a conclusão de vários processos de teste do lado do fornecedor e após a aprovação da aceitação do lado do utilizador. O que o utilizador normalmente faz no processo de aceitação é principalmente verificar as entradas e saídas que podem ser confirmadas a partir do ecrã. No entanto, os sistemas de TI muitas vezes têm uma estrutura complexa e detalhada na base de dados por trás e nas partes do programa que controlam vários cálculos e controles, além da aparência no ecrã que pode ser confirmada pelo lado do utilizador. Portanto, há um limite para o que pode ser investigado a partir da verificação das entradas e saídas no ecrã do ponto de vista do utilizador. Portanto, não é realista verificar exaustivamente todas as possibilidades de problemas que podem ocorrer na fase de operação após a verificação.

A mesma situação se aplica quando se olha do ponto de vista do fornecedor que é responsável pelo desenvolvimento. Por exemplo, o processo de teste é para verificar se há bugs ou problemas com o conteúdo do programa implementado. No entanto, mesmo no processo de teste, não é necessariamente possível verificar todas as possibilidades de bugs e problemas. Mesmo após o sistema desenvolvido começar a ser usado em pleno na operação, é necessário um alto nível de habilidade técnica para criar um sistema que continue a funcionar sem problemas, mesmo quando operações inesperadas são realizadas pelo lado do fornecedor, ou quando uma grande quantidade de dados começa a ser registada, ou quando vários utilizadores começam a aceder ao mesmo tempo.

Deve-se entender primeiro que, em estágios como aceitação e teste, não é realista descobrir todos os bugs e problemas, e que podem surgir vários problemas depois de começar a usar o sistema de TI.

Normalmente, a dívida em si é considerada cumprida

Então, como devemos lidar quando esses problemas realmente surgem? Vamos organizar de acordo com a ordem legal.

Primeiro, se vários bugs ou problemas foram descobertos após o fato, o usuário provavelmente desejará responsabilizar o fornecedor que tem solicitado o trabalho até agora. No entanto, normalmente, se a entrega já foi concluída e a inspeção foi aprovada, muitas vezes é difícil responsabilizar com base no não cumprimento da dívida.

Em primeiro lugar, a menos que haja algum acordo especial, as disposições relativas à implementação do programa em contratos de desenvolvimento de sistemas são cobertas pelas disposições do contrato de trabalho sob o Código Civil Japonês. Explicamos em detalhes o que é um contrato de trabalho no seguinte artigo.

E num contrato de trabalho, a “conclusão do trabalho” é um requisito para o cumprimento da dívida. Explicamos em detalhes o que significa a “conclusão do trabalho” no seguinte artigo.

Aqui, explicamos que a “conclusão do trabalho” num contrato de trabalho, no contexto do desenvolvimento de sistemas, significa o fim de todo o processo de desenvolvimento, com base em precedentes judiciais anteriores. E explicamos que problemas como bugs e defeitos que surgem após a conclusão de todo o processo de desenvolvimento são uma questão de responsabilidade pela garantia de defeitos num contrato de trabalho.

Em resumo, se a entrega foi aceita uma vez e a inspeção foi aprovada, normalmente a dívida em si já é considerada cumprida, e a questão é se a garantia de qualidade subsequente, ou seja, a possibilidade de responsabilização pela garantia de defeitos, pode ser perseguida.

Perseguindo a responsabilidade com base na responsabilidade de garantia de defeitos

Então, quando se pede ao fornecedor para responder com base na responsabilidade de garantia de defeitos, o que e em que ordem devemos considerar? Vamos verificar abaixo.

Primeiro, verifique a gravidade e a seriedade dos bugs e falhas

Quando bugs e falhas são descobertos após o fato e se busca alguma garantia por serem “defeitos” legais, a gravidade desses bugs e falhas se torna um problema. A questão dos defeitos legais é, em primeiro lugar,

1. Embora possa ser chamado de bug ou falha, é apenas um problema menor e não pode ser chamado de “defeito” legal
2. Aplica-se a “defeitos” legais, mas ainda é possível atingir o objetivo do contrato
3. Aplica-se a “defeitos” legais e também não é possível atingir o objetivo do contrato

Estes são divididos em três padrões. O que divide a possibilidade de perseguir a responsabilidade com base na responsabilidade de garantia de defeitos é a linha entre 1 e 2, e o que divide a possibilidade de rescindir o contrato com base na responsabilidade de garantia de defeitos é a linha entre 2 e 3.

Artigo 634

1. Quando há defeitos no objeto do trabalho, o cliente pode solicitar ao contratado que corrija os defeitos dentro de um prazo razoável. No entanto, isso não se aplica se o defeito não for significativo e a correção exigir um custo excessivo.

2. O cliente pode solicitar indenização por danos em vez de, ou além da, correção do defeito. Neste caso, as disposições do artigo 533 são aplicadas

Artigo 635

Quando há defeitos no objeto do trabalho e, por causa disso, não é possível atingir o objetivo do contrato, o cliente pode rescindir o contrato. No entanto, isso não se aplica a edifícios e outras estruturas de terra.

Além disso, para uma explicação detalhada sobre esta distinção gradual de “defeitos”, consulte o seguinte artigo.

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

Em seguida, esclareça o que deve ser solicitado ao fornecedor

Além disso, é necessário esclarecer o que deve ser solicitado à outra parte. Se você deseja rescindir o contrato, não é suficiente provar que é um defeito, mas também deve ser algo que “não pode atingir o objetivo do contrato”. As atas das reuniões realizadas no início do projeto de desenvolvimento do sistema e os itens descritos nas especificações são pistas importantes para julgar o “objetivo” mencionado aqui. Como é possível que bugs e falhas sejam descobertos após a aceitação, é importante manter todos os documentos mesmo após o término do projeto de desenvolvimento.

Além da rescisão, outras coisas que podem ser solicitadas como parte da responsabilidade de garantia de defeitos incluem pedidos de indenização por danos e pedidos de correção de defeitos.

Outros pontos a considerar

Atenção ao procedimento quando realizar atos legais, como a rescisão de um contrato

Se, como parte da responsabilidade pela garantia de defeitos, for necessário rescindir um contrato, também deve adquirir conhecimento sobre como realizar os procedimentos legais para a rescisão. Explicamos em detalhe em um artigo abaixo sobre os efeitos da rescisão do contrato, como fazer uma declaração de intenção válida e como notificar para evitar problemas futuros.

É preferível resolver através de negociações, em vez de disputas

Além disso, essas discussões legais não são significativas apenas quando um processo judicial ocorre. A resolução de disputas por meio de litígios é um grande fardo para ambas as partes. Pelo contrário, esses conhecimentos devem ser bem utilizados mesmo na fase de negociação antes de chegar ao tribunal. Explicamos em um artigo abaixo sobre o significado desses conhecimentos legais em negociações fora do tribunal.

Deve-se distinguir entre bugs e defeitos, e a falta de funcionalidades

A discussão difere se houver bugs ou defeitos nas funcionalidades ou especificações implementadas, ou se as funcionalidades necessárias não estiverem disponíveis desde o início. Se as funcionalidades necessárias não estiverem todas disponíveis, pode-se argumentar que a “conclusão do trabalho” no contrato de empreitada não é reconhecida e que o cumprimento da obrigação não pode ser reconhecido.

Além disso, mesmo que as funcionalidades ou especificações necessárias não estejam disponíveis, se o resultado for que o usuário não forneceu informações adequadas na fase de definição de requisitos, pode ser inadequado considerar isso como parte do conteúdo do contrato.

Resumo

Os problemas que surgem durante o processo de um projeto podem tornar-se evidentes durante a sua execução ou até mesmo numa fase posterior, como a fase de operação. Mesmo que todas as etapas do projeto sejam concluídas com sucesso, a natureza dos projetos de desenvolvimento de sistemas, que não permitem um relaxamento total, parece ser simbolizada pelo sistema de “responsabilidade pela garantia de defeitos”. Acredita-se que seja importante ter uma gestão rigorosa da documentação que leva em conta o período após a conclusão do projeto de desenvolvimento do sistema, bem como entender todo este processo.