Qual é a lei relacionada à saída de membros de projetos de desenvolvimento de sistemas?

Em projetos de desenvolvimento de sistemas, normalmente, cada processo e tarefa são subdivididos, e a ênfase é colocada em avançar com o máximo de planeamento possível. No entanto, por mais que se valorize o planeamento, existem problemas relacionados com as ‘pessoas’ que são inevitáveis, como problemas inesperados. Em particular, os riscos de ausências inesperadas ou demissões de membros do projeto são aspectos que, por mais que se tente prevenir, são inevitáveis até certo ponto. Neste artigo, explicaremos como a lei se relaciona com a saída de membros do projeto.

A saída de membros e a discussão sobre as obrigações de gestão de projetos

Primeiramente, é considerado que, num projeto de desenvolvimento de sistemas, o fornecedor tem a responsabilidade abrangente de garantir o seu progresso suave. Este tem a obrigação de estimar o pessoal, o tempo, o orçamento e o esforço necessários para o progresso suave do projeto, solicitar a cooperação necessária ao utilizador conforme apropriado e gerir o progresso do projeto. Estas obrigações são chamadas de “obrigações de gestão de projetos” e a sua existência tem sido repetidamente apontada em precedentes judiciais.

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

A ocorrência de uma saída repentina por parte do fornecedor pode ser considerada um tipo de problema com as obrigações de gestão de projetos do fornecedor.

• Problemas físicos devido a excesso de horas extras e trabalho aos fins de semana por parte do responsável
• Stress psicológico devido a conflitos interpessoais

Existem várias razões possíveis para a ocorrência de uma saída repentina num projeto. No entanto, estes são basicamente problemas de gestão de trabalho do lado do fornecedor. Portanto, mesmo que estas circunstâncias resultem em atrasos na entrega, a possibilidade de isenção de violação de obrigações é baixa. Em outras palavras, o fornecedor é esperado para gerir o progresso do projeto com planeamento, antecipando a ocorrência de tais vagas repentinas.

Decisões judiciais importantes relacionadas à saída de membros

Caso em que a saída de um membro levou ao atraso na entrega

O caso citado na decisão judicial abaixo envolve um atraso na entrega após a saída repentina de um membro do projeto, o que impediu o progresso do projeto conforme planejado. Neste caso, o responsável do lado do usuário adotou uma atitude intimidadora para com o responsável do lado do fornecedor, o que também causou um fardo psicológico.

O usuário, que queria buscar responsabilidade por inadimplência devido ao atraso no cumprimento, e o fornecedor, que queria buscar violação do dever de cooperação contra o usuário que adotou tal atitude de alta pressão e intimidadora, tiveram um conflito intenso sobre o caso.

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

Contudo, o tribunal decidiu que as várias circunstâncias não isentam o fornecedor de seu dever de gestão do projeto e apoiou a visão do usuário (as partes sublinhadas e em negrito foram adicionadas pelo autor).

O fornecedor alega que o representante do usuário insultou o responsável do fornecedor com palavras e ações agressivas e de alta pressão, fazendo com que o responsável do fornecedor tivesse que se retirar do trabalho contratado.

É verdade que o representante do usuário disse em uma reunião em novembro de 2003 (Heisei 15) com um tom forte, “Não tem vontade de trabalhar?“, “Este contrato está acabado. Se eu sair desta sala, está acabado.“, mas isso se deve ao atraso no trabalho do fornecedor e à sua resposta, apesar do fato de que o período protótipo foi definido como o final de outubro de 2003 (Heisei 15) no acordo básico, e a função adicional do objetivo do desenvolvimento deste caso não foi incluída na proposta do documento de definição de requisitos, e mesmo que comentários fossem adicionados à proposta do documento de definição de requisitos e respondidos, não houve resposta. Portanto, não pode ser dito que foi um comportamento excessivo.

Além disso, embora a causa da saída de C do trabalho contratado devido à doença não seja clara, mesmo que o stress do trabalho contratado tenha sido a causa, a previsão da carga de trabalho do trabalho contratado, etc., deve ser considerada basicamente um problema de gestão de trabalho do fornecedor, e não pode ser atribuída à culpa do usuário.

Decisão do Tribunal Distrital de Tóquio, 4 de dezembro de 2007 (Heisei 19)

Na decisão judicial acima, mesmo após considerar o fato de que o usuário pressionou o fornecedor com um “tom forte”, o tribunal não isentou o fornecedor de sua responsabilidade. O que está por trás dessa decisão é provavelmente a consideração do equilíbrio com a má resposta do fornecedor, e a consideração de que seria injusto atribuir a culpa ao usuário que pressionou com vários “tons fortes”. É uma decisão que adota o esquema de que o projeto de desenvolvimento do sistema é estabelecido pela execução do dever de gestão do projeto pelo fornecedor e pela execução do dever de cooperação pelo usuário, e ainda assim não deve ser reconhecida a violação do dever de cooperação pelo usuário. O significado disso deve ser visto na frase “não pode ser dito que foi um comportamento excessivo”.

O que pode ser aprendido com a decisão judicial acima

Além disso, podemos tirar as seguintes lições importantes:

• Quando se pensa em atribuir a culpa ao usuário na saída de um membro do projeto devido a doença, o fornecedor é solicitado a provar a relação causal de que a saída foi devido ao usuário → No entanto, geralmente é considerado difícil provar que há uma relação causal.
• Mesmo que se possa provar que a carga de trabalho aumentou devido ao usuário e o membro ficou doente, geralmente acaba sendo considerado um problema de gestão de trabalho do fornecedor → Se prestarmos atenção ao fato de que a expressão forte “comportamento excessivo” é usada na decisão, devemos considerar que as circunstâncias que isentam a responsabilidade de gestão de trabalho do fornecedor são bastante limitadas.

Preparando-se para o risco de saída de membros

Como mencionado acima, mesmo que ocorra uma situação em que haja uma súbita falta de pessoal, é extremamente difícil atribuir isso ao lado do usuário. Pode acontecer que sejamos forçados a realizar um grande desenvolvimento adicional ou a fazer mudanças abruptas nas especificações, mas não é fácil provar a relação causal entre a alteração física e mental e a carga de trabalho. Considerando essas circunstâncias, é importante avançar na organização do pessoal, assumindo a ocorrência de problemas como ausências por doença ou má condição física dos membros do projeto.

Se este ponto for disputado em tribunal, é claro que o lado do fornecedor estará em uma posição muito desvantajosa. Portanto, o que é importante é, em vez disso, medidas para prevenir tais disputas. As medidas possíveis incluem o seguinte:

Estabelecer um sistema que não isole o responsável

É aconselhável evitar situações em que o responsável participe sozinho de uma reunião e criar um sistema em que várias pessoas participem da reunião, o que pode prevenir situações de isolamento psicológico.

Manter uma margem na alocação de pessoal

Também é importante manter uma margem na alocação de pessoal. Garantir pessoal com uma margem certamente levará a um aumento nos custos. No entanto, se considerarmos o custo da indenização por danos devido ao atraso na entrega e a preocupação com a ocorrência de mais saídas na situação de lidar com tais problemas, muitas vezes é mais racional garantir pessoal com uma certa margem desde o início.

Revisar a alocação antes de a saúde se deteriorar

Se uma pessoa sair, a carga de trabalho dos outros funcionários aumentará, o que pode levar a um ciclo vicioso de mais saídas. Para evitar esse ciclo vicioso, é importante revisar a alocação antes que a saúde se deteriore seriamente.

Garantir a gestão de mudanças e a gestão de documentos do projeto

Não é fácil provar a relação causal entre a saída de membros da equipe e a violação do dever de cooperação do lado do usuário, mas ainda é importante garantir a gestão de mudanças e a gestão de documentos. Isso porque, mesmo que não possamos provar a causa da saída dos membros da equipe, se houver uma situação de excesso de trabalho que leve à ausência por doença do responsável, isso pode conter elementos que apoiem a violação do dever de cooperação do lado do usuário. Essas circunstâncias podem servir como elementos para justificar a compensação por negligência, mesmo que a responsabilidade por inadimplemento ou garantia de defeitos seja perseguida pelo lado do fornecedor no caso de um projeto “incendiado”.

No seguinte artigo, discutimos a importância da gestão de documentos em projetos de desenvolvimento de sistemas.

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

Além disso, para uma discussão mais detalhada sobre a mudança de especificações, consulte o seguinte artigo.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Resumo

Acima, discutimos a teoria jurídica associada ao fenómeno da “saída de membros da equipa”. Para os fornecedores, é inegável que é extremamente difícil, do ponto de vista jurídico, responsabilizar os utilizadores pela saída dos membros.

No entanto, mesmo com essas circunstâncias, é importante não mal interpretar que “a discussão legal não é útil no problema da saída dos membros da equipa”. O próprio processo de pensamento dos casos publicados está a questionar como definir a fronteira entre o “dever de gestão de projetos do fornecedor” e o “dever de cooperação do utilizador”, para não mencionar que as medidas para prevenir tais conflitos são muitas vezes derivadas ao reverter a partir das situações de conflito previstas.

Em vez de interpretar o ponto de “estar em desvantagem em um julgamento” como “a lei não é útil”, é importante entender que “a perspectiva da prevenção jurídica é importante”.