O que é o dever de gestão de projetos no desenvolvimento de sistemas

O desenvolvimento de sistemas é algo que só avança através da cooperação mútua entre o utilizador que encomenda o trabalho e o fornecedor que o aceita.

Os projetos para desenvolver sistemas de TI usados nas empresas raramente avançam exatamente como planeado ou previsto. Em vez disso, é mais comum que sejam confrontados com vários problemas e desafios, grandes ou pequenos, e que avancem superando-os um a um. Neste contexto, é claro que é importante que o lado do utilizador e o lado do fornecedor façam esforços para se sincronizarem, mas também é importante a gestão de crises que antecipa situações de conflito.

Do ponto de vista jurídico, o primeiro passo na gestão de crises é esclarecer quais são as obrigações de cada parte e o que cada uma pode reivindicar como direito. Neste artigo, vamos explicar principalmente sobre a obrigação de gestão de projetos que o fornecedor tem em relação a todo o projeto.

O que são as obrigações de gestão de projetos do lado do fornecedor

Primeiramente, vamos analisar o conteúdo das obrigações de gestão de projetos do lado do fornecedor.

De acordo com os precedentes judiciais, o conteúdo das obrigações de gestão de projetos é o seguinte:

– Obrigação de avançar com o trabalho de desenvolvimento de acordo com o acordado, gerir constantemente o progresso e esforçar-se para descobrir fatores que possam impedir o trabalho de desenvolvimento, e lidar adequadamente com eles

– Obrigação de gerir adequadamente o envolvimento do usuário no desenvolvimento e trabalhar com o usuário para garantir que não haja ações que impeçam o trabalho de desenvolvimento por parte de usuários que não possuem conhecimento especializado em desenvolvimento de sistemas

Isso inclui mostrar ao usuário questões que requerem tomada de decisão e preocupações que precisam ser resolvidas, juntamente com prazos, indicar problemas que podem surgir se a tomada de decisão do usuário for atrasada, aconselhar o usuário a tomar decisões, e se houver pedidos que não podem ser aceitos devido ao progresso do desenvolvimento, explicar completamente as razões e recusar os pedidos do usuário.

Assim, o fornecedor tem a obrigação de promover o trabalho de desenvolvimento e ao mesmo tempo incentivar o usuário a tomar decisões, e esforçar-se para que o desenvolvimento do sistema seja bem-sucedido.

Obrigações de cooperação do lado do usuário

No entanto, no desenvolvimento de sistemas, não é o caso de o fornecedor assumir unilateralmente todas as obrigações. Afinal, como se trata de um sistema de TI a ser usado na empresa que faz o pedido, o projeto de desenvolvimento do sistema não deve ser considerado como “assunto de outra pessoa” para o lado que faz o pedido.

Mesmo que se recorra a especialistas externos confiando na sua capacidade técnica e organizacional para desenvolver o sistema, a governança interna deve ser aplicada. Sem esforço para aproveitar as habilidades dos especialistas externos, é impossível entregar o trabalho necessário considerando tudo como assunto de outra pessoa. Nesse sentido, o lado do usuário também tem a obrigação de cooperar no desenvolvimento do sistema.

As obrigações de cooperação que o lado do usuário deve cumprir incluem o seguinte:

① O usuário realiza uma análise de risco de forma proativa, coordena adequadamente as opiniões internas e unifica as opiniões antes de transmitir os pedidos ao fornecedor

② Verificar os produtos finais

③ Responder aos pedidos de cooperação do fornecedor

É exigido que o lado do usuário transmita claramente ao fornecedor as funções que deseja do sistema e coopere ativamente no desenvolvimento.

A gestão de projetos não é fácil

Pode ser difícil para o lado do usuário, que só vê a tela, perceber que o sistema de TI é composto por uma combinação de pequenas peças. No entanto, isso é extremamente importante ao considerar a dificuldade de gerir um projeto de desenvolvimento de sistemas. Precisamente porque o sistema de TI é assim, o fornecedor é exigido a ter uma atenção meticulosa e ao mesmo tempo a capacidade de organizar a visão geral de forma concisa e a capacidade de visão geral.

Há dificuldades no trabalho que podem não ser imaginadas apenas olhando para a tela, e isso também pode ser a razão pela qual o projeto “incendeia” se você mudar o ponto de vista. Primeiro, entenda esses pontos e saiba que “gerir um projeto para desenvolver um sistema de TI não é uma tarefa fácil”. Isso será uma grande premissa ao aprender sobre a gestão de riscos do projeto.

O que pode acontecer em caso de violação do dever de gestão de projetos

Então, o que pode acontecer especificamente se houver uma violação do dever de gestão de projetos?

Não existe um artigo claro que diga “o dever de gestão de projetos é isto”.

No entanto, a partir de precedentes judiciais, podemos inferir uma espécie de posição consistente sobre o que um utilizador pode fazer se houver uma violação do dever por parte do fornecedor.

Se o fornecedor violar o seu dever, o utilizador pode reivindicar indenização por danos ou rescisão do contrato ao fornecedor. No entanto, se o utilizador também tiver um problema, pode ser determinado que o fornecedor não é responsável, ou pode haver uma compensação por negligência, o que pode reduzir o montante da indenização por danos.

Por outro lado, se o utilizador violar o seu dever de cooperação, o fornecedor pode reivindicar ao utilizador um montante equivalente à remuneração, com base no risco de não conclusão do trabalho (Artigo 536, parágrafo 2, do Código Civil Japonês) ou incumprimento do contrato.

Exemplos de casos judiciais que demonstram a obrigação de gestão de projetos

Existem vários casos judiciais representativos que explicam o que é a obrigação de gestão de projetos.

O caso a seguir evoluiu para um litígio que chegou ao tribunal devido a atrasos no prazo de entrega e ao aumento do orçamento inicial solicitado pelo fornecedor no desenvolvimento do sistema. Pode ser um exemplo típico de um caso “em chamas”, onde a disputa se arrasta até ao tribunal sobre como dividir a responsabilidade entre o utilizador e o fornecedor.

O réu, como especialista em desenvolvimento de sistemas, tinha a obrigação de completar o sistema de computação em questão até o prazo de entrega acordado, construindo o sistema descrito no contrato e na proposta do sistema de computação em questão, com base no seu alto nível de conhecimento e experiência especializada.
Portanto, o réu deveria ter a obrigação de avançar com o trabalho de desenvolvimento de acordo com os procedimentos e métodos de desenvolvimento e os processos de trabalho apresentados no contrato e na proposta do sistema de computação em questão, para completar o sistema de computação em questão até o prazo de entrega, gerir constantemente o progresso, esforçar-se para descobrir fatores que impedem o trabalho de desenvolvimento e lidar adequadamente com eles. Além disso, como o desenvolvimento do sistema é realizado em consulta com o cliente, o réu deveria ter a obrigação de gerir adequadamente o envolvimento do cliente, o demandante Kokumin Hoken, no desenvolvimento do sistema e de influenciar o demandante Kokumin Hoken, que não tem conhecimento especializado em desenvolvimento de sistemas, para evitar ações que impeçam o trabalho de desenvolvimento (a seguir, estas obrigações serão referidas como “tarefas de gestão de projetos”).

Decisão do Tribunal Distrital de Tóquio, 10 de março de 2004 (Heisei 16)

Não é importante decifrar a linguagem detalhada e o curso complexo do caso a partir do resumo da decisão acima. O ponto é que a frase “obrigação de gestão de projetos” é usada tal como está. Embora não exista uma cláusula explícita, pode-se ver a atitude do tribunal em estabelecer diretrizes para a divisão de responsabilidades legais.

Vamos reorganizar o conteúdo da decisão acima de forma simples e organizá-lo em pontos. A “obrigação de gestão de projetos” mencionada aqui é:

• Avançar com o trabalho real de acordo com o plano prévio (procedimentos de desenvolvimento, métodos, processos, etc.)
• Gerir o progresso para ver se o trabalho real está a progredir sem problemas
• Se houver algum “fator de impedimento” que impeça o trabalho real de progredir sem problemas, descobri-lo e tomar medidas adequadas conforme necessário

Além disso, em relação aos três pontos acima,

• Não se trata apenas de esforços de autoajuda unilaterais do lado do fornecedor, mas também de esforços de comunicação, como solicitar a cooperação necessária do lado do utilizador conforme necessário

Podemos organizar que é um termo geral para tais coisas.

Além disso, o desenvolvimento do sistema é quase sempre contratado sob a forma de um contrato de agência ou um contrato de trabalho. E um contrato de agência é, simplesmente falando, um contrato para “trabalhar com a precisão correspondente à remuneração recebida”, por isso a obrigação de gestão de projetos também pode ser organizada como um conceito que é absorvido na “precisão, etc.” a ser realizada.

Embora seja um tema de debate, mesmo no caso de um contrato de trabalho, que é um contrato para “fazer o que foi pedido”, acredita-se que a obrigação de gestão de projetos ainda possa surgir. A razão, como já mencionado, é que o desenvolvimento do sistema, seja um contrato de agência ou um contrato de trabalho, ainda requer a gestão do projeto, e acredita-se que o lado do fornecedor deve fazê-lo.

Exemplo de jurisprudência que indica a obrigação de gestão de projetos mesmo antes da celebração do contrato

Também se considera que a obrigação de gestão de projetos pode ser imposta mesmo antes da celebração do contrato. O exemplo de jurisprudência citado abaixo indica que a obrigação de gestão de projetos se aplica ao fornecedor mesmo na fase anterior ao contrato, ou seja, quando estão a ser apresentadas várias propostas e planos.

O caso seguinte envolve um projeto que falhou a meio do caminho, e a questão em disputa era se a obrigação de gestão de projetos poderia ser reconhecida devido a deficiências na planificação e nas propostas apresentadas antes da celebração do contrato, bem como nas estimativas e explicações fornecidas ao utilizador. Geralmente, como a planificação e a proposta são tarefas realizadas antes da celebração do contrato, a questão era se era legalmente possível reconhecer tal obrigação. No entanto, o tribunal reconheceu isso.

A abordagem da obrigação de gestão de projetos no exemplo de jurisprudência acima mencionado também se aplica à fase anterior à celebração do contrato, como se pode ver claramente a partir da leitura abaixo.

Na fase de planificação e proposta, são definidos os principais elementos relacionados com a concepção do projeto e a sua viabilidade, como a definição dos objetivos do projeto, os custos de desenvolvimento, o âmbito e o cronograma de desenvolvimento, e também são determinados os riscos associados ao projeto. Portanto, a análise e planificação do projeto e dos riscos exigidos ao fornecedor nesta fase são indispensáveis para a execução do desenvolvimento do sistema. Assim, o fornecedor deve, nesta fase, examinar e verificar as funções do sistema que propõe, o grau de satisfação das necessidades do utilizador, o método de desenvolvimento do sistema, a estrutura de desenvolvimento após a adjudicação, etc., e explicar ao utilizador os riscos previstos. Esta obrigação do fornecedor de verificação e explicação pode ser posicionada como uma obrigação legal baseada no princípio da boa fé no processo de negociação para a celebração do contrato, e pode-se dizer que o recorrente, como fornecedor, tem tal obrigação (a obrigação relativa à gestão de projetos nesta fase).

Acórdão do Tribunal Superior de Tóquio, 26 de setembro de 2013 (Ano 25 da era Heisei)

Além disso, a ideia de que existe uma certa obrigação legal para com a outra parte mesmo antes da celebração do contrato não se limita apenas ao tema dos projetos de TI, mas é algo que sempre existiu em todas as transações comerciais e negociações legais em geral.

Quanto maior a transação, mais provável é que o processo de “aproximação” até ao objetivo do contrato seja longo. Mesmo nesse processo, a ideia de que se deve ser honesto com a outra parte é algo que se entende bem, pelo menos moralmente. Para dizer de forma simples, essa ideia não se limita apenas a sentimentos morais emocionais, mas também tem um significado legal. (O texto da lei é citado abaixo. O sublinhado foi adicionado pelo autor.)

Artigo 1º, parágrafo 2, do Código Civil Japonês
O exercício de direitos e o cumprimento de obrigações devem ser realizados com boa fé e honestidade.

A palavra-chave “princípio da boa fé” no texto da decisão expressa de forma concisa o conteúdo acima.

Além disso, o exemplo de jurisprudência apresentado neste artigo também tem, de certa forma, o significado de “orientação para delinear a fronteira entre a obrigação de cooperação do utilizador e a obrigação de gestão de projetos do fornecedor”. Para mais informações sobre a obrigação de cooperação do utilizador no desenvolvimento de sistemas de TI, consulte o artigo abaixo.

Resumo: Em caso de problemas relacionados com a violação das obrigações de gestão de projetos, consulte um advogado

Neste artigo, tentámos organizar de forma geral o conceito de obrigações de gestão de projetos no desenvolvimento de sistemas. O desenvolvimento de sistemas vem sempre acompanhado de vários desafios e problemas, mas quando nos deparamos com tais situações, o que parece ser importante é a ‘base’ que é comum a qualquer cenário de conflito. Sem dúvida, existem infinitas variações na forma como cada situação irregular ocorre.

Contudo, a importância de questionar “quem assumiu quais obrigações legais desde o início?” diante de tais situações tem uma certa universalidade que vai além da individualidade do caso em si.

Ao invés de se limitar a resolver problemas de forma ad hoc, parece que a chave para buscar uma solução através da divisão construtiva de desafios está, mais uma vez, na lei e nos precedentes judiciais.

Se ocorrerem problemas relacionados com a violação das obrigações de gestão de projetos, consulte imediatamente um advogado.