Quais são as obrigações de suporte que o fornecedor assume após o término do desenvolvimento do sistema?

É bem conhecido que, no desenvolvimento de sistemas, o fornecedor especializado em desenvolvimento de sistemas assume a “obrigação de gestão de projetos”. No entanto, legalmente, um conceito semelhante mas distinto, a “obrigação de suporte”, também tem sido levantado. Neste artigo, vamos discutir a “obrigação de suporte”, levando em consideração precedentes judiciais anteriores.

O que é a Obrigação de Suporte

Visão Geral da Obrigação de Suporte

Quando falamos sobre as obrigações que um fornecedor tem para com o utilizador, a obrigação de gestão de projeto é uma das mais representativas. Este é um conceito que foi estabelecido através de repetidas referências em casos judiciais anteriores, e resume as obrigações que o fornecedor, como especialista em desenvolvimento de sistemas, tem para com um projeto.

A obrigação de gestão de projeto é um termo legal muito famoso no que diz respeito ao desenvolvimento de sistemas, e não há dúvida de que é uma das principais obrigações que o fornecedor assume. No entanto, alguns casos judiciais reconhecem a existência de uma obrigação diferente da obrigação de gestão de projeto, a qual é chamada de “obrigação de suporte”.

A Obrigação de Suporte torna-se um problema no apoio operacional ao utilizador

Então, o que é a obrigação de suporte? E por que é que é chamada de forma diferente da obrigação de gestão de projeto? A obrigação de suporte geralmente torna-se um problema após o término do desenvolvimento do sistema. Um projeto de desenvolvimento de sistema, sendo um “projeto de desenvolvimento”, termina, de acordo com o pensamento básico, quando o sistema a ser criado é concluído. Ou seja, um projeto de desenvolvimento de sistema começa com a clarificação do que o sistema a ser criado deve ser (= definição de requisitos) e termina com a confirmação de que foi realmente concluído (= teste ou aceitação). Quanto ao processo de aceitação, tendo em conta que tem um significado importante como o “fim do projeto de desenvolvimento de sistema”, os problemas legais que tendem a surgir nesta fase são tratados em detalhe no seguinte artigo.

No entanto, mesmo que um projeto de desenvolvimento de sistema seja entendido como o próprio processo de criação de um novo sistema, é naturalmente assumido que o sistema desenvolvido será utilizado nos negócios subsequentes. Ou seja, pode ser considerado irracional dizer que, desde que se esteja apenas a criar como parte do trabalho de desenvolvimento, não importa como o sistema será utilizado após o seu desenvolvimento. Tendo isto em conta, em casos judiciais anteriores, surgiu a questão de se poderia ou não ser imposta ao fornecedor, que é responsável pelo desenvolvimento do sistema, uma certa obrigação de apoio operacional. Em outras palavras, a questão é se, nas obrigações que o fornecedor assume num contrato de desenvolvimento de sistema, deveria ser incluída a obrigação relacionada com o apoio operacional após o desenvolvimento. Como o apoio operacional não faz parte do próprio processo de desenvolvimento, acredita-se que a expressão “obrigação de suporte” tenha sido usada para distingui-la da obrigação de gestão de projeto.

Exemplos de casos judiciais onde a obrigação de suporte foi questionada

Caso em que a realização das tarefas do usuário foi prejudicada na fase de teste do sistema

No caso citado na sentença abaixo, o usuário não conseguiu utilizar o sistema como inicialmente previsto durante o teste do sistema realizado antes do início da operação do sistema, resultando na desistência do usuário de operar o sistema. Este caso é um problema que ocorreu no momento do início da operação do usuário, e a questão era como justificar a responsabilidade do fornecedor a partir do contrato de desenvolvimento do sistema acordado previamente. Como conclusão, a reivindicação de indenização por danos do usuário foi reconhecida, e a “violação da obrigação de suporte” foi apontada como a base para isso.

I Violação da obrigação de suporte
(A) O representante do autor, em 14 de julho de 1997 (ano Heisei 9), solicitou ao réu que “não apenas crie o sistema, mas cuide dele até que funcione corretamente.“, “Somos amadores, então, como estamos pagando muito dinheiro, queremos que você faça com que possamos usá-lo até o fim.“. Em resposta, o réu explicou que era possível construir um sistema que pudesse atingir o objetivo de introdução do autor e prometeu apoiar até que pudesse ser usado corretamente. Com isso, foi estabelecido um acordo entre o autor e o réu de que o réu apoiaria até que o autor pudesse usar o sistema corretamente.
É claro que o réu tem a obrigação de apoiar o autor, pois ele registrou um custo de 1.726.000 como “taxa de contrato do projeto” para “suporte à introdução do pacote”, e na estimativa, a “taxa de manutenção mensal” é listada como “manutenção gratuita por seis meses após a introdução”, e no documento intitulado “Sobre o suporte SE no futuro (material de discussão interna)”, é confirmado que o suporte SE pode ser recebido para “criação de procedimento (plano) de introdução” e “trabalho de verificação de dados/operacional” para pedidos de produtos frescos.

(B) E então, a obrigação de suporte que o réu tem para com o autor, especificamente, pelo menos até que o autor comece a operar o sistema, o réu deve fornecer ao autor ① aconselhamento adequado sobre como operar o sistema, ② lidar com problemas no sistema que ocorreram durante o teste de operação, ③ melhorar o sistema de acordo com os resultados do teste de operação, ④ fornecer treinamento de introdução para o operador.
No entanto, mesmo quando muitos problemas ocorreram durante o teste de operação, o réu não respondeu seriamente a eles, alegando que eram problemas de proficiência do operador, e apenas solicitou o custo do treinamento de introdução do operador, e não forneceu nenhum suporte adequado ao autor para a operação principal.

Decisão do Tribunal Distrital de Hachioji, Tóquio, 5 de novembro de 2003 (ano Heisei 15)

Nesta sentença, a palavra “suporte” aparece cerca de 30 vezes em todo o texto da sentença, incluindo o índice. A voz do usuário pedindo apoio adequado é diretamente registrada na sentença, e pode-se ver que foi uma conclusão após considerar bastante os detalhes do caso e visar uma resolução justa. Além disso, os pontos que devem ser especialmente notados na compreensão deste caso são:

• A violação da obrigação de suporte é tratada como “inadimplemento contratual”, e como resultado, foi ordenada a indenização pelos danos causados.
• O termo “obrigação de gestão de projeto” não é usado nem uma vez em toda a sentença.

Embora seja um conceito diferente da gestão de projetos, pode-se ver a atitude de tratar isso como uma obrigação contratual incluída no contrato de desenvolvimento de sistemas.

Como devemos interpretar a natureza da obrigação de suporte?

A obrigação de suporte ainda não é um conceito claro

O caso judicial mencionado anteriormente indica que o fornecedor que desenvolveu o sistema deve também fornecer o suporte necessário para o usuário iniciar a operação. No entanto, a obrigação de suporte não é tão bem definida como a obrigação de gestão de projeto, e não há muitas pistas para entender a sua realidade. Em particular, o termo “suporte” em si inclui o problema de não estar claro o que deve ser feito concretamente.

A obrigação de suporte não é reconhecida como ilimitada

Além disso, a sentença que reconheceu a violação da obrigação de suporte do fornecedor também indicou um ponto muito importante.

O réu é entendido como tendo a obrigação de fornecer um certo suporte necessário para o autor operar o sistema que construiu e entregou ao autor com base no contrato de empreitada. No entanto, o conteúdo não é entendido como sendo, como o autor alega, sem limitação de tempo, até que o autor possa realmente operar o sistema, fornecer todo o suporte gratuitamente.

Decisão do Tribunal Distrital de Tóquio, Hachioji Branch, 5 de novembro de 2003 (Ano 15 da era Heisei, 2003)

Se o principal trabalho aceito é o “desenvolvimento” do sistema, pode-se pensar que há necessariamente restrições ao que deve ser feito como suporte para a subsequente “operação”. Mesmo nesta decisão, há vários pontos característicos, como a citação da voz do usuário que pede apoio na sentença, a menção ao conteúdo da estimativa prévia, e a menção à existência de uma cláusula especial para fornecer suporte. Em outras palavras, considerando que a expansão ilimitada do conceito de obrigação de suporte colocaria uma grande carga no lado do fornecedor, acredita-se que a intenção era ser relativamente cauteloso na determinação da violação da obrigação.

A realidade da obrigação de suporte deve ser considerada juntamente com a obrigação de cooperação do usuário

Em resumo, a discussão até agora pode ser dita como “como o usuário e o fornecedor devem compartilhar a carga de trabalho na fase inicial de operação no desenvolvimento do sistema”. Certamente, isso inclui o problema um tanto complexo de quanto o fornecedor tem a obrigação legal de assumir no início da operação a partir do contrato de “desenvolvimento”. Ao mesmo tempo, é inevitável dizer que há uma forte tendência para exigir um julgamento baseado em circunstâncias individuais.

No entanto, acredita-se que a realidade da obrigação de suporte que o fornecedor deve assumir se tornará mais certa ao entender a obrigação de cooperação que o usuário deve assumir.

Em primeiro lugar, o esforço para melhorar o trabalho com um novo sistema tem o aspecto de ser um trabalho conjunto do fornecedor, que é um especialista em tecnologia, e do usuário, que tem conhecimento do trabalho interno. Portanto, em relação à tal obrigação de suporte, acredita-se que muitas vezes o escopo será naturalmente definido ao esclarecer o que o usuário deve resolver com esforço próprio como parte do “cumprimento da obrigação de cooperação”.

Resumo

Neste artigo, organizamos a questão do “dever de suporte”, que pode ser considerado uma derivação do gerenciamento de projetos, com base nos fundamentos deste último. Embora ainda existam muitos pontos ambíguos no conceito de dever de suporte, acreditamos que o que é importante para a sua compreensão são, sem dúvida, questões fundamentais como o “dever de gerenciamento de projetos” e o “dever de cooperação”.