Quais são as obrigações de cooperação que os utilizadores, como contratantes do desenvolvimento de sistemas, devem assumir?

O trabalho de desenvolvimento de sistemas, quanto maior for o sistema a ser desenvolvido, mais necessita de um grande número de pessoas e de tempo para ser realizado. Portanto, não só o fornecedor que assume o desenvolvimento, mas também o utilizador que encomenda o desenvolvimento do sistema, tem um certo dever de cooperação.

Isto é diferente da relação normal de encomenda e recepção. Por exemplo, se encomendar a criação de um fato sob medida a um alfaiate, em vez de um sistema de TI, o cliente (utilizador) que faz a encomenda não tem necessariamente um “dever”. O “dever” recai principalmente sobre o alfaiate (fornecedor) que recebe a encomenda. É precisamente porque um sistema de TI requer muitas pessoas e tempo que o utilizador também precisa de “cooperar” com o fornecedor.

Neste artigo, explicaremos quais são as obrigações legais do lado do encomendador em relação ao desenvolvimento de sistemas, que não pode ser deixado apenas ao fornecedor.

Não é suficiente “delegar tudo” quando se trata do seu próprio sistema

Num único projeto de desenvolvimento de sistemas, muitas vezes há um grande número de pessoas e organizações envolvidas. Não só os engenheiros e programadores especializados em codificação, mas também o papel do gestor de projeto é crucial para reunir o output desses profissionais num único resultado.

Contudo, mesmo que o fornecedor tenha uma elevada capacidade técnica e organizacional, o desenvolvimento do sistema não pode ser realizado apenas com o esforço do fornecedor. Por exemplo, termos usados apenas internamente na empresa ou conhecimentos de negócios específicos da empresa não podem ser conhecidos apenas pelos esforços unilaterais do fornecedor. Quanto maior o desenvolvimento do sistema, mais comum é a tendência de a empresa que vai utilizar o sistema ser uma grande empresa com muitas pessoas e operações. Para levar um projeto de desenvolvimento de sistema ao sucesso, muitas vezes a organização da lógica de negócios tem um grande peso, mesmo antes do trabalho no computador.

Portanto, em vez de os utilizadores se tornarem passivos com a desculpa de “não serem especialistas em tecnologia da informação”, muitas vezes o progresso do projeto é facilitado pela prestação ativa de informações. Neste sentido, o papel que os utilizadores desempenham num projeto de desenvolvimento de sistemas não é de todo pequeno.

O que é o dever de cooperação do usuário com base em precedentes judiciais

Então, concretamente, que tipo de dever de cooperação o usuário tem em um projeto de desenvolvimento de sistema? Existem muitas dicas deixadas em precedentes judiciais sobre este ponto.

No tribunal, no caso de atraso na entrega pelo fornecedor (réu), a questão de se o usuário (demandante) tem um dever de cooperação no desenvolvimento devido a atrasos na tomada de decisões, etc., tornou-se um ponto de disputa. Neste caso, o tribunal reconheceu a violação do dever de cooperação do usuário e negou a responsabilidade do fornecedor por inadimplemento. (Embora a rescisão do contrato tenha sido permitida, também foi permitida uma compensação de 60% da culpa.)

Este contrato de desenvolvimento de sistema de computador é um contrato de desenvolvimento de sistema feito sob medida, e em tal contrato de desenvolvimento de sistema feito sob medida, o contratado (fornecedor) não pode completar o sistema sozinho, e o contratante (usuário) deve, durante o processo de desenvolvimento, coordenar as opiniões internas de forma precisa, unificar as opiniões, comunicar claramente ao contratado que tipo de função deseja, discutir a função desejada com o contratado, finalmente decidir a função, além disso, decidir a tela e os relatórios, e desempenhar um papel na aceitação dos resultados.

Julgamento do Tribunal Distrital de Tóquio, 10 de março de 2004 (2004)

Este julgamento, além de indicar que o próprio desenvolvimento do sistema é um trabalho conjunto com o usuário, também declara “em que pontos específicos devemos colaborar”, o que parece ser muito sugestivo.

Vamos tentar traduzir a linguagem do texto da decisão acima para termos de TI de desenvolvimento de sistemas.

Podemos organizar desta forma. Todos estes são coisas que não podem ser feitas sozinhas, não importa quão avançada seja a especialização no sistema de TI, sem a cooperação do usuário. O que se quer em termos de funcionalidade e como deve ser o layout da tela são basicamente coisas que o usuário deve esclarecer, e se o que foi solicitado foi realizado ou não só pode ser verificado pelo usuário.

Além disso, assim como o fornecedor tem o dever de gerenciar o projeto, o usuário também tem o dever de cooperar. Portanto, se o usuário violar o dever de cooperação no processo acima, pode-se pensar que o fornecedor pode reivindicar indenização por inadimplemento ou ato ilícito contra o usuário.

Como são interpretados os pedidos de alteração de especificações após a conclusão do projeto?

Além disso, se assumirmos que o projeto de desenvolvimento de sistemas é um trabalho conjunto entre o utilizador e o fornecedor, a discussão avançará para um debate mais avançado. A questão é: “Se o utilizador solicitar adições ou alterações de funcionalidades após a conclusão do projeto, tornando difícil cumprir o prazo de entrega, de quem será a responsabilidade?”

O desenvolvimento de sistemas geralmente começa com a definição de requisitos, seguida de design básico, design detalhado, fabricação (implementação do programa) e teste, com o objetivo de evitar retrabalho tanto quanto possível (geralmente chamado de modelo waterfall). No entanto, na realidade, muitas vezes acontece que se descobre que há falhas no processo anterior devido a várias circunstâncias, o que leva a retrabalho no processo.

Como devemos pensar se não conseguirmos cumprir o prazo de entrega nestes casos? Ao interpretar precedentes, parece que a conclusão varia dependendo do momento em que o trabalho adicional ocorreu.

Se o trabalho adicional ocorreu antes da clarificação das especificações do design externo, etc.

O precedente mencionado indica que não é necessariamente uma violação do dever de cooperação fazer tal pedido durante o design básico (antes da fase de implementação do programa).

Para o utilizador, fazer várias solicitações ao fornecedor sobre o sistema a ser construído durante o trabalho de design básico é uma coisa natural no processo de desenvolvimento de sistemas como este, e além disso, para o utilizador sem conhecimento especializado, é difícil julgar corretamente se tal solicitação requer uma taxa adicional ou uma extensão do prazo de entrega, ou se interfere no processo de trabalho. Portanto, não se pode dizer que o utilizador deveria ter se controlado para fazer solicitações que levariam a taxas adicionais ou extensões do prazo de entrega. Pelo contrário, se o utilizador fez uma solicitação que requer uma taxa adicional ou uma extensão do prazo de entrega, o réu, que tem o dever de gestão do projeto, deveria ter informado o utilizador disso e solicitado discussões sobre a retirada da solicitação ou a extensão do prazo de entrega, etc., para evitar interferências no trabalho de desenvolvimento.

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

Nesta decisão, foi indicado que, embora o utilizador tenha um certo dever de cooperação, o facto de o utilizador não ser um especialista em desenvolvimento de sistemas deve ser levado em consideração. Em outras palavras, se o utilizador que faz o pedido não é um especialista em desenvolvimento de sistemas, não é estranho que ele faça pedidos em pedaços até que o conteúdo do sistema a ser desenvolvido seja esclarecido (e em alguns casos, ele pode não estar acostumado a fazer pedidos), e é duro dizer que ele “deveria ter percebido por si mesmo” que o conteúdo do pedido requer uma revisão do prazo de entrega, etc.

No entanto, o dever imposto ao fornecedor aqui é, em última análise, um esforço de comunicação, como solicitar uma extensão do prazo de entrega (ou, se o prazo de entrega não puder ser alterado, sugerir que o pedido adicional seja retirado). Portanto, não se deve entender que inclui a obrigação de aceitar todos os pedidos do utilizador e entregar tudo conforme o prazo inicial. Portanto, é necessário ter cuidado com este ponto.

Se o trabalho adicional ocorreu após a confirmação das especificações da fase de fabricação ou teste

Se invertermos o conteúdo da decisão acima, podemos prever até certo ponto qual seria a conclusão se fosse um desenvolvimento adicional após a confirmação das especificações. Nesse caso, tais pedidos seriam mais difíceis de aceitar. Certamente, o nível de compreensão do trabalho de desenvolvimento entre o utilizador e o fornecedor é muito diferente, independentemente de as especificações terem sido confirmadas antes ou depois.

No entanto, alterar ou adicionar ao conteúdo do pedido após a confirmação das especificações é provável que force o retrabalho. Em muitos casos, seria difícil defender que “é natural que o cliente faça várias solicitações” para atrasos na entrega que ocorreram até mesmo nesses casos. Além disso, a situação em que muitas alterações de especificações e adições de funcionalidades ocorrem após o fato levanta a questão de se houve uma violação do dever de cooperação do lado do utilizador nos processos a montante, como o design básico, que deveria ter sido concluído anteriormente.

A partir desses pontos, é realista pensar que não é realista responsabilizar o fornecedor pelo atraso na entrega causado pela alteração das especificações feita após a confirmação das mesmas. A partir do texto da decisão mencionada acima, seria apropriado interpretar que também tem esse significado.

Além disso, tais julgamentos tendem a ser feitos com base não apenas no contrato, mas também em atas que acompanham o progresso do desenvolvimento do sistema. Detalhes sobre as atas são explicados no artigo abaixo.

Artigo relacionado: Como manter as atas no desenvolvimento de sistemas do ponto de vista legal[ja]

Resumo: É importante não esquecer que a definição de requisitos é um processo do lado do utilizador

A definição de requisitos, embora seja uma oportunidade para o fornecedor mostrar as suas habilidades, deve ser conscientemente considerada como uma tarefa do lado do utilizador. Mesmo que o sistema seja desenvolvido com a ajuda de especialistas externos, é considerado legalmente que deve estar sob a governança da própria empresa, uma vez que é um sistema que a empresa usa.

Se o lado do utilizador não for cooperativo no processo de desenvolvimento, mesmo que o projeto falhe, é importante estar ciente de que o tribunal pode ter uma visão rigorosa para o lado do utilizador.