Qual é o significado legal dos objetivos de gestão e metas numéricas em projetos de desenvolvimento de sistemas?

Os projetos de desenvolvimento de sistemas muitas vezes estão intimamente ligados a melhorias significativas nas empresas e nos locais de trabalho. Nesses casos, pode ser exigida uma postura que contribua para a resolução de problemas de gestão do lado do utilizador da empresa, ou para a realização de objetivos numéricos. No entanto, será que o compromisso com esses objetivos de gestão é realmente uma obrigação legal? A questão é qual o significado legal dos objetivos numéricos e de gestão. Neste artigo, vamos discutir os problemas legais associados aos vários “objetivos” e “metas” no desenvolvimento de sistemas.

Por que os objetivos e metas do desenvolvimento de sistemas se tornam a causa de conflitos?

Porque é um desafio localizado entre a obrigação de cooperação do usuário e a discrição do fornecedor

Quando visto como uma forma de transação comercial, existem alguns pontos característicos nos projetos de desenvolvimento de sistemas. Um deles é que o próprio projeto de desenvolvimento de sistemas pelo fornecedor não pode ser realizado apenas pelo fornecedor, mas requer a cooperação do lado do usuário. A existência desta obrigação é claramente estabelecida na jurisprudência como “obrigação de cooperação”. Principalmente nas fases de ① definição de requisitos ② design básico ③ aceitação de produtos, é exigido que o usuário também coopere no desenvolvimento do sistema.

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

Outro ponto é que geralmente se espera que o fornecedor exerça grande discrição e se envolva nos negócios. Existe um termo legal que resume o que o fornecedor deve fazer em todo o projeto de desenvolvimento de sistemas, chamado “obrigação de gestão de projeto”. Este ponto é explicado em detalhe no seguinte artigo.

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

Resumindo o conteúdo acima, podemos apontar dois pontos importantes aqui.

• O usuário deve fornecer as informações necessárias ao fornecedor conforme necessário e cooperar com o trabalho de desenvolvimento do fornecedor.
• O fornecedor deve entender o propósito e os objetivos do projeto para o usuário e tomar medidas que se alinhem com eles.

Devido a estas duas circunstâncias, torna-se um problema até que ponto o cumprimento dos objetivos de gestão e dos objetivos numéricos, que foram explicados antecipadamente pelo usuário, pode se tornar uma obrigação do lado do fornecedor. Em outras palavras, há um aspecto em que é uma obrigação do usuário resumir o que o fornecedor deve fazer (não algo vago como objetivos) em especificações e apresentá-las, enquanto o fornecedor também tem a obrigação de fornecer o que o usuário essencialmente exige como um especialista. Este é um aspecto. O conflito entre estas duas partes opostas é uma característica dos conflitos em torno dos “objetivos” e “propósitos” do desenvolvimento de sistemas. Além disso, do ponto de vista legal, apresentar diretrizes para a resolução de conflitos que beneficiem ambas as partes é um desafio prático.

Cenas concretas em que os objetivos do usuário afetam o projeto

Muitos projetos de desenvolvimento de sistemas estão ligados a medidas de melhoria e eficiência de grandes operações de empresas e locais de trabalho, e muitas vezes há audiências sobre questões de gestão e objetivos de gestão mesmo na fase de planejamento e proposta. Nesse ponto, é possível que haja trocas sobre o custo-benefício do desenvolvimento do sistema e trocas através de vários objetivos numéricos.

• Redução de custos de pessoal devido à economia de trabalho
• Aumento das vendas e lucros
• Redução do tempo de trabalho

Por exemplo, no caso em que os itens acima são o objetivo final do projeto, o fornecedor pode explicar o efeito do investimento no desenvolvimento do sistema como um consultor com antecedência e pode ser considerado que ele está fazendo vendas.

Exemplos de casos judiciais onde os objetivos de gestão propostos pelo utilizador foram problemáticos

No entanto, o fornecedor é normalmente um especialista em desenvolvimento de sistemas. Se toda a responsabilidade recair sobre ele em relação aos objetivos de gestão do utilizador, isso pode ser demasiado severo.

Caso onde a melhoria da velocidade das operações foi estabelecida como objetivo

Relacionado com este assunto, no caso citado na sentença abaixo, os objetivos e propósitos do projeto de desenvolvimento do sistema foram escritos no plano de negócios criado no início do projeto. No entanto, quando o sistema foi concluído e começou a ser utilizado, não foi possível atingir esses objetivos e propósitos, o que levou a um conflito. O plano inicial indicava que, após a conclusão do sistema e o início da sua utilização, se pretendia alcançar o seguinte estado:

• Reduzir o tempo de entrada manual em 50%
• Concluir o processamento administrativo usando o sistema de TI dentro de um período especificado

O utilizador tentou responsabilizar o fornecedor por incumprimento de obrigações e responsabilidade por defeitos, uma vez que não conseguiu alcançar estes resultados. No entanto, o tribunal não aceitou este argumento (as partes sublinhadas e em negrito foram adicionadas pelo autor).

E então, (omissão)… De acordo com o argumento geral, ① o objetivo deste caso é “melhorar a eficiência das operações”, “construir a base do CRM”, “gerir de forma visível”, etc., que são abstratos, e os objetivos são “aumentar os pontos de contato com os clientes”, “redistribuir o esforço dos funcionários administrativos para o controle interno e o apoio às vendas”, “fazer previsões de vendas mais precisas”, “restringir descontos excessivos nas vendas”, etc., que são em grande parte abstratos, e “reduzir o tempo de entrada em 50%”, “reduzir o tempo de estimativa em 50%”, “realizar a divulgação legal dentro do prazo legal”, etc., são objetivos que dependem da gestão e do método de operação do réu após a introdução do SBO, e não são de natureza que a empresa de desenvolvimento de sistemas, que é a autora, possa assumir a sua realização, ② nas atas da reunião após o início deste projeto, não há menção de que se discutiu concretamente a realização dos objetivos e propósitos deste caso, ③ no plano de projeto deste caso, “tornar-se uma empresa listada”, etc., são expressões que não têm a natureza de um contrato em si, (omissão)… considerando estas circunstâncias, é reconhecido que o autor criou a descrição do propósito deste caso no plano de projeto deste caso com base na explicação do réu, a fim de evitar o fracasso deste projeto, para obter um entendimento comum sobre o propósito e os resultados deste projeto, e não se pode reconhecer que o réu contratou o autor para desenvolver um sistema para alcançar o propósito deste caso, (omissão)… portanto, não se pode reconhecer que o autor assumiu o desenvolvimento de um sistema para alcançar o propósito deste caso a pedido do réu, (omissão)… não há razão para a alegação de responsabilidade por incumprimento de obrigações e responsabilidade por defeitos.

Decisão do Tribunal Distrital de Tóquio, 28 de dezembro de 2010 (Heisei 22)

Qual é o significado legal dos objetivos de gestão e dos objetivos numéricos que podem ser lidos a partir dos exemplos de casos judiciais?

Como mencionado nesta decisão, se os objetivos do desenvolvimento do sistema ou os objetivos quantificados numericamente podem ser alcançados ou não, normalmente depende de vários fatores, como os esforços de gestão do utilizador que utiliza o sistema. Portanto, o limiar para tornar isso uma responsabilidade do lado do fornecedor deve ser considerado muito alto. Em primeiro lugar, se a responsabilidade do fornecedor por incumprimento de obrigações e responsabilidade por defeitos for reconhecida, isso significa que a realização dos “objetivos” e “metas” foi incorporada como parte do conteúdo do contrato. No entanto, no presente caso, os “objetivos” e “metas” foram avaliados legalmente como:

• Para coisas abstratas e vagas, é difícil vê-las como parte do conteúdo do contrato porque não se encaixam na natureza das obrigações legais.
• Para coisas que requerem esforço próprio do lado do utilizador, especialmente do lado da gestão, é impróprio responsabilizar o lado do fornecedor, pois estão fora do controle do fornecedor, e é difícil vê-las como parte das obrigações contratuais.

Esta foi a avaliação legal que eles receberam.

O que mais pode ser aprendido com esta decisão

Esta decisão também contém vários outros conteúdos interessantes.

• O fato de que o tribunal também considera que o compartilhamento dos “objetivos” e “metas” do projeto de desenvolvimento do sistema pode ser apenas um esforço de comunicação para obter um “entendimento comum” entre o utilizador e o fornecedor.
• O fato de que eles também se referem às atas das reuniões ao considerar quão essenciais eram esses “objetivos” e “metas” em todo o projeto.

Além disso, do ponto de vista da importância da gestão de documentos e das atas das reuniões em relação aos problemas legais associados aos projetos de desenvolvimento de sistemas, estamos a explicar no seguinte artigo.

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

Considerações Legais sobre Objetivos de Gestão e Metas Numéricas

No entanto, em relação a estas “finalidades” e “objetivos”, devemos também considerar os seguintes pontos adicionais.

A questão muda dependendo se a consultoria é paga ou gratuita

Se, além do projeto de desenvolvimento do sistema, houver um contrato de consultoria pago, a situação pode mudar significativamente. Se, independentemente dos recursos de gestão disponíveis para o usuário, um plano de execução com pouca viabilidade foi estabelecido, é possível que a responsabilidade por inadimplemento seja perseguida na parte do contrato de consultoria pago.

Defeitos no produto final, inconsistências nas funções e requisitos de especificação são questões separadas

Além disso, se houver defeitos no próprio projeto de “desenvolvimento”, ou seja, se forem confirmados bugs ou problemas no produto final, essas questões devem ser entendidas separadamente. Nesse caso, a discussão sobre “finalidades” e “objetivos” de gestão é desnecessária, e a consistência entre o produto final e as funções e especificações requeridas é o problema. Por exemplo, as medidas a serem tomadas pelo usuário se um defeito for descoberto no sistema após a sua implementação são explicadas no seguinte artigo.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Outro tópico relacionado é que pode haver coisas que são reconhecidas como tendo a obrigação de serem implementadas à discrição do fornecedor, mesmo que não estejam incluídas nos requisitos. Isso é explicado em detalhes no seguinte artigo.

https://monolith.law/corporate/system-development-specs-function[ja]

Em qualquer caso, deve-se entender que as disputas sobre “finalidades” e “objetivos” são semelhantes, mas não idênticas.

É exigida uma compreensão fundamental de temas como responsabilidade e contratos

Acima, fizemos uma explicação sobre os problemas legais relacionados com os “objetivos” e “metas” do desenvolvimento de sistemas. Em disputas sobre esses pontos, acredita-se que os tribunais entendem bem que, na maioria das vezes, os esforços para alinhar os passos entre o usuário e o fornecedor são feitos como parte dos esforços de comunicação. No entanto, mesmo que a validade da conclusão em si possa ser plenamente compreendida pelo senso prático do profissional, no processo que leva a isso, é exigida uma compreensão fundamental de coisas como “responsabilidade” e “contratos”. Explicamos sobre esses pontos no seguinte artigo.

É importante obter uma compreensão mais essencial, considerando que a responsabilidade legal é diferente da responsabilidade moral vaga, e que a “concordância de intenções” clara entre as duas partes é o que gera a responsabilidade contratual.