O que é a lei relacionada com a 'falha catastrófica' dos projetos de desenvolvimento de sistemas?

Um projeto de desenvolvimento de sistemas não é algo que possa ser alcançado da noite para o dia. Requer a contribuição de muitos recursos, incluindo um grande número de pessoas e organizações, uma quantidade significativa de dinheiro e um longo período de desenvolvimento. Neste artigo, vamos explicar como o fenómeno de “incêndio” num projeto de desenvolvimento de sistemas pode ser organizado dentro de um quadro legal, e também vamos compilar algumas diretrizes para soluções.

Por que os projetos “incendeiam”?

Um sistema de TI, mesmo que não seja um projeto de grande escala, só funciona corretamente devido à acumulação de uma grande quantidade de arquivos de programa e código-fonte que foram criados. Muitas vezes, a construção é tão detalhada e precisa que é difícil de imaginar a partir da sensação de operação vista do lado do ecrã (ou, pelo contrário, especialmente em sistemas de TI onde a sensação de operação vista do lado do ecrã é simples e concisa).

• O prazo de entrega é o único que foi decidido antecipadamente, e o tempo passa com as especificações e requisitos ainda vagos
• Muitos membros abandonam devido ao stress das relações humanas, pois estão constantemente distraídos com questões políticas internas
• Há uma falta de habilidades de negociação na camada de gestão, incluindo o PM, e os membros não estão sendo solicitados a fazer relatórios, comunicações e consultas adequadas

As razões específicas para a “incineração” de um projeto podem variar de projeto para projeto. No entanto, do ponto de vista legal, as razões para a “incineração” de um projeto podem ser organizadas de forma relativamente simples em vários tipos.

Tipo de Incêndio 1: Quando um Projeto Falha a meio do Caminho

Na progressão do desenvolvimento de sistemas, a falta de comunicação entre o lado do utilizador e o lado do fornecedor é frequentemente citada como uma razão típica para um projeto falhar a meio do caminho. Em primeiro lugar, um projeto de desenvolvimento de sistemas requer não só a competência técnica e organizacional especializada do lado do fornecedor, mas também a cooperação do lado do utilizador que irá utilizar o sistema final.

Portanto, se um projeto avança com uma compreensão vaga de que papel cada parte deve desempenhar, e se surge uma espécie de “empurrar de responsabilidades” entre as partes, isso pode impedir o progresso suave do projeto. Para uma análise legal das obrigações do lado do utilizador e do lado do fornecedor, por favor consulte os seguintes artigos.

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

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

Embora os detalhes das responsabilidades que cada parte deve assumir possam ser encontrados nos artigos acima, o ponto chave aqui é que, mesmo num único projeto de desenvolvimento de sistemas, tanto o utilizador como o fornecedor têm certas responsabilidades. Em termos gerais, os tribunais têm reconhecido que o lado do utilizador tem uma obrigação de cooperação em áreas que não podem ser concluídas sem a sua ajuda, como a definição de requisitos, o design da aparência da tela (ou seja, o design básico), e a aceitação.

Por outro lado, o lado do fornecedor também tem uma obrigação abrangente de garantir o progresso suave do projeto e de identificar e eliminar quaisquer obstáculos, após ter recebido a cooperação do lado do utilizador nos pontos acima (e ao mesmo tempo, ter feito esforços para comunicar e solicitar tal cooperação).

Com base neste pensamento, os tribunais têm demonstrado uma atitude de tratar todos os conflitos de forma justa, mostrando que o utilizador tem a obrigação de exercer a governança interna como um sistema interno, e que o fornecedor tem a obrigação de demonstrar a sua especialização e competência técnica como um especialista externo.

Além disso, um momento em que estas “falhas” são propensas a ocorrer é durante a aceitação. A aceitação é explicada em detalhe no seguinte artigo.

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

Nestes casos, uma vez que um conflito surge, a evidência objetivamente verificável, como a progressão de projetos anteriores e o conteúdo das reuniões, é muitas vezes enfatizada. Portanto, os documentos que foram registados antecipadamente muitas vezes têm um grande significado. Para não prejudicar a sua posição, é importante garantir uma gestão rigorosa dos documentos. Para uma explicação detalhada da importância da gestão de documentos no desenvolvimento de sistemas, por favor consulte o seguinte artigo.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Tipo de incêndio 2: Quando o cancelamento é feito por conveniência do usuário

Também é possível que um projeto seja interrompido a meio do caminho devido ao desejo do usuário. Por exemplo, suponha que uma empresa começou a desenvolver um sistema de TI para gerir todos os recursos humanos, incluindo as suas bases no estrangeiro, mas a estratégia de expansão para o estrangeiro foi retirada. Nesse caso, o desenvolvimento do sistema que estava a ser iniciado pode tornar-se desnecessário para o usuário.

Em primeiro lugar, a questão de como um sistema de TI deve ser construído numa empresa não pode ser separada da questão de que tipo de trabalho existe primeiro na empresa. Portanto, é possível que os requisitos do sistema que se tornam necessários (ou desnecessários) mudem após o facto, devido a mudanças significativas na estrutura organizacional, reorganização de departamentos de negócios, revisões radicais da estratégia, etc.

Devido a estas circunstâncias, quando um projeto é interrompido a meio do caminho, vários problemas legais podem surgir. Normalmente, como é por conveniência do usuário, o fornecedor tem certos direitos legais, como a cobrança de uma taxa proporcional ao grau de conclusão. Dependendo do tipo de contrato que foi adotado, há diferenças nos artigos que servem de base, mas o conteúdo é organizado da seguinte forma:

・No caso de um contrato de empreitada: Artigo 641 do Código Civil Japonês
Artigo 641 do Código Civil Japonês
→ Enquanto o empreiteiro não terminar o trabalho, o cliente pode cancelar o contrato a qualquer momento, indemnizando o dano.
・No caso de um contrato de mandato: Artigo 648, parágrafo 3, do Código Civil Japonês (dependendo das circunstâncias, também pode ser feito um pedido de indemnização com base no Artigo 651 do Código Civil Japonês)
Artigo 648 do Código Civil Japonês
→ Se o mandato terminar a meio do cumprimento por uma razão que não pode ser atribuída ao mandatário, este pode cobrar uma taxa proporcional ao cumprimento já realizado.
Artigo 651 do Código Civil Japonês
→ 1. O mandato pode ser cancelado a qualquer momento por qualquer das partes.
→ 2. Se uma das partes cancelar o mandato num momento desfavorável para a outra parte, essa parte deve indemnizar o dano da outra parte. No entanto, isto não se aplica se houver uma razão inevitável.

Tipo de Incêndio 3: Quando as falhas do sistema entregue são descobertas posteriormente

Os utilizadores tendem a avaliar a qualidade de um sistema com base na experiência de utilização, mas para quem desenvolve o sistema, os desafios mais complexos podem estar no design da base de dados ou na identificação de todos os possíveis métodos de operação para testar o sistema.

Portanto, mesmo que um sistema pareça funcionar sem problemas no início,

• À medida que a quantidade de dados registados aumenta, a velocidade de processamento pode diminuir
• Um sistema que parecia funcionar sem problemas nas operações diárias básicas pode revelar bugs em operações especiais que ocorrem apenas algumas vezes por mês ou por ano
• Embora pareça que os resultados estão a ser corretamente produzidos, a lógica pode estar errada (por exemplo, mesmo que a entrada do utilizador “1+1” produza corretamente “2”, isso não garante que o cálculo esteja a ser feito corretamente. Se qualquer equação produzir “2”, isso é um erro de lógica que muitas vezes não pode ser descoberto apenas operando o sistema. Neste sentido, um certo nível de “competência técnica” é exigido no processo de teste.)

Estes são exemplos de problemas que podem realmente ocorrer. Se analisarmos estes casos do ponto de vista legal, eles podem ser considerados como uma violação das obrigações de gestão de projetos por parte do fornecedor, ou seja, um problema de incumprimento parcial sob a lei civil japonesa.

Se não houver nenhuma disposição especial no contrato para este caso, as disposições relativas aos contratos de empreitada geralmente se aplicam.

Os pontos a considerar neste caso são os seguintes:

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

Os pontos são organizados desta forma.

Resumo

Cada projeto de desenvolvimento de sistema avança através de várias e diversas reviravoltas. No entanto, quando se trata de “incêndios” em projetos legais, a estrutura apresentada neste artigo serve como um mapa. Os problemas legais relacionados ao desenvolvimento de sistemas certamente abrangem uma variedade de temas.

Assim como o trabalho de desenvolvimento de sistemas requer pensamento construtivo, a gestão de riscos associada a ele também pode ser realizada de forma mais construtiva, evitando perder a visão geral do campo. Não seria isso possível?