Até que ponto deve-se implementar funcionalidades não especificadas na documentação de desenvolvimento de sistemas, do ponto de vista legal?

Os projetos que desenvolvem sistemas de TI utilizados nas empresas são, em princípio, criados de acordo com especificações previamente definidas. No entanto, considerando o significado de confiar o trabalho de desenvolvimento a um fornecedor como especialista em desenvolvimento de sistemas, as expectativas do lado do utilizador podem não ser tão baixas quanto simplesmente implementar mecanicamente o que está escrito nas especificações. Neste artigo, discutiremos até que ponto se deve assumir a responsabilidade de implementar um programa que, embora não esteja descrito na especificação, é necessário implementar à luz do objetivo do desenvolvimento.

Problemas legais associados à implementação de elementos não especificados

É exigida discrição nas tarefas do fornecedor

Uma das grandes características dos contratos relacionados a projetos de desenvolvimento de sistemas e dos vários problemas legais associados a eles é que o fornecedor que aceita o trabalho tem grande discrição.

Artigo relacionado: O que são as obrigações de gestão de projetos no desenvolvimento de sistemas[ja]

No entanto, a “discrição” mencionada aqui não se aplica necessariamente a todo o processo de desenvolvimento de sistemas. Após identificar cada processo e avançar na identificação de tarefas detalhadas, pode haver muitos trabalhos que se aproximam de tarefas simples. No entanto, em geral, quanto mais se trata de tarefas de processo a montante, mais difícil se torna executar o trabalho sem ter grande discrição. A razão pela qual os contratos de agência são frequentemente bem adaptados aos processos a montante também se deve a este ponto.

Artigo relacionado: A distinção e diferença entre contratos de empreitada e contratos de agência no desenvolvimento de sistemas[ja]

A discrição também deve ser exercida dentro de um rigoroso processo de desenvolvimento

Contudo, mesmo que o fornecedor que desenvolve o sistema tenha grande discrição, aceitar as solicitações do cliente de forma desorganizada causará danos significativos nos processos posteriores. Um sistema de TI é composto por uma coleção de pequenas peças, portanto, mesmo que pareça uma pequena mudança na aparência, pode exigir uma grande mudança no tempo de trabalho do ponto de vista do desenvolvedor. Além disso, existem artigos que explicam como gerir as mudanças nas especificações do desenvolvimento de sistemas do ponto de vista legal. O artigo abaixo discute como gerir as mudanças, mas também discute o impacto significativo que as mudanças nas especificações podem ter no trabalho do ponto de vista do engenheiro.

Artigo relacionado: Como gerir mudanças no desenvolvimento de sistemas do ponto de vista legal[ja]

O que um especialista deve fazer sem se ater às especificações?

Para que um projeto de desenvolvimento de sistemas prossiga sem problemas, é importante definir os requisitos de desenvolvimento com antecedência e prosseguir de forma planejada de acordo com eles. Por outro lado, existem situações em que simplesmente fazer o que foi dito de acordo com os requisitos definidos previamente não é suficiente para desempenhar plenamente o papel de um especialista em desenvolvimento de sistemas. Dentro deste dilema, surge a questão de “o que deve ser implementado, embora não esteja indicado nas especificações”.

As obrigações legais são determinadas de acordo com o ‘propósito’ especificado nos documentos de especificações e contratos

O conteúdo do que deve ser implementado, mesmo que não esteja descrito nos contratos ou documentos de especificações, ainda é determinado pelo ‘propósito’ desses itens descritos nos contratos e documentos de especificações, ou seja, ‘qual é o significado ou intenção por trás da decisão tomada dessa maneira’. Vamos examinar alguns exemplos de casos judiciais abaixo.

Caso judicial em que a obrigação de implementação foi negada devido à falta de descrição

O caso judicial citado abaixo envolve um sistema desenvolvido por um fornecedor que chegou ao ponto de operação provisória, mas foi objeto de disputa quando o usuário solicitou a rescisão do contrato por falta de funcionalidades necessárias. A funcionalidade que o usuário alegou estar faltando era a “função de atualização automática de dados”, que foi alegada como um dos principais pontos de venda do sistema em questão, mas o tribunal não reconheceu esta obrigação de implementação.

Conforme reconhecido acima, não há descrição nos contratos deste caso, nem nos documentos de design básico e detalhado, que indique que a funcionalidade ③ é objeto de desenvolvimento deste sistema.

O autor alega que a funcionalidade ③ era um dos principais pontos de venda do sistema em questão para o réu, e enfatiza a necessidade dessa funcionalidade, mas se essa alegação fosse verdadeira, deveria estar claramente indicada nos contratos deste caso, e é difícil acreditar que o desenvolvimento dessa funcionalidade foi acordado na ausência de tal indicação.

Decisão do Tribunal Distrital de Tóquio, 18 de fevereiro de 2009 (Heisei 21)

De facto, se retirarmos apenas a conclusão deste julgamento, poderíamos dizer que “se não está descrito no documento de design, não é necessário criar o que não existe”. No entanto, para ser mais preciso, não se trata de um facto formal de se a descrição está ou não no documento de design, mas de um julgamento feito com base no “propósito” da descrição no documento de design e contrato. Ou seja, “considerando o motivo pelo qual a descrição não foi feita no documento de design e contrato, é razoável pensar que não houve acordo correspondente à descrição”.

Casos judiciais que afirmaram a obrigação de implementação mesmo sem especificação

Por outro lado, existem casos judiciais que afirmam a obrigação de implementação, mesmo que não esteja especificado no contrato ou nas especificações. O caso citado abaixo envolve o desenvolvimento de um sistema para gerir o histórico de medicação, onde não foi possível transferir os dados do sistema existente para o novo sistema, impedindo a utilização do novo sistema e levando o utilizador a rescindir o contrato. No entanto, a questão evoluiu para uma disputa, com o fornecedor alegando que a transferência de dados estava fora do âmbito do seu trabalho.

O desenvolvimento de um novo sistema muitas vezes envolve a eliminação do sistema existente e a transferência de dados. A importância destas tarefas e os problemas legais associados são explicados em detalhe no artigo abaixo.

Artigo relacionado: Problemas legais associados à transição do sistema antigo no desenvolvimento do sistema[ja]

O sistema existente já tinha mais de 50.000 dados de pacientes armazenados, e o demandante estava a tentar melhorar a eficiência do trabalho utilizando estes dados. Se não fosse possível transferir os dados dos pacientes do sistema existente para o novo sistema, seria óbvio que isso causaria problemas na dispensação de medicamentos na farmácia, e é razoável pensar que o representante do demandante estava ciente disso. Além disso, antes da celebração do contrato em questão, o representante do demandante perguntou ao representante do réu sobre a possibilidade de transferência de dados, e o representante do réu também reconheceu isso. Portanto, é difícil pensar que o representante do demandante, sabendo que haveria uma alta probabilidade de ter que inserir manualmente os dados de mais de 50.000 pacientes, decidiu ousadamente introduzir o novo sistema. Além disso, como mencionado acima em (1) I, o réu não conseguiu transferir os dados de histórico de medicamentos do sistema existente para o novo sistema, e estava a processar esses dados imprimindo-os em papel e incorporando-os em ficheiros PDF. É difícil pensar que o réu teria realizado este trabalho laborioso como um serviço, mesmo que a transferência de dados não fosse assumida no contrato em questão.

Decisão do Tribunal Distrital de Tóquio, 18 de Novembro de 2010 (Ano 22 da era Heisei, 2010)

O que é importante aqui é o “propósito” do contrato e o “espírito” das cláusulas do contrato. Se ambas as partes celebraram o contrato reconhecendo que a transferência de dados estava fora do âmbito do trabalho, o tribunal apontou que tanto o utilizador como o fornecedor teriam celebrado o contrato com intenções não naturais. Ou seja, o utilizador teria assumido uma grande quantidade de trabalho manual, e o fornecedor teria abordado o projeto sabendo que isso causaria problemas no trabalho do utilizador no futuro, o que seria uma história extremamente irracional.

O que podemos aprender com ambas as decisões judiciais

Em relação à migração de dados, mesmo que não esteja mencionado no contrato ou nas especificações, a obrigação de implementação foi afirmada. Uma das razões para isso parece ser que estávamos a falar de “dados”, um assunto que não aparece na aparência na tela. A “ausência de funcionalidade obrigatória” mencionada anteriormente é algo que aparece diretamente na tela do sistema. Portanto, mesmo para um leigo em desenvolvimento de sistemas, não é tão difícil descobrir omissões nas especificações. Por outro lado, o problema da migração de dados tem a característica de ser difícil para um leigo em desenvolvimento de sistemas perceber a importância do processo, a dificuldade do trabalho e o tempo necessário. Portanto, pode-se pensar que havia circunstâncias em que era mais provável que fosse tratado como uma questão que o fornecedor deveria gerir suavemente com especialização.

Olhando desta forma, a omissão nas especificações e contratos pode ser dita como um problema intimamente relacionado com o “dever de cooperação” do usuário. Ou seja, a questão é se o usuário realmente cumpriu o “dever de cooperação” para a celebração do contrato e a criação das especificações. Uma explicação geral sobre as obrigações legais que o usuário deve cumprir em um projeto de desenvolvimento de sistema é tratada em detalhes no seguinte artigo.

Artigo relacionado: O que é o dever de cooperação do usuário, que é o cliente do desenvolvimento do sistema[ja]

Se você também verificar o artigo acima, você pode entender que a solicitação de cooperação do usuário, como a identificação da tela e funcionalidades obrigatórias, é uma área grande, e a omissão na consideração da migração de dados é uma história muito diferente.

Como devemos considerar a remuneração para o desenvolvimento que não está especificado no documento de especificações?

Outra questão que pode surgir em relação ao tema deste artigo é se é legalmente permitido cobrar uma remuneração adicional por criar algo que não está especificado no documento de especificações. Discutimos em detalhe a possibilidade de aumentar a remuneração e como calcular o valor estimado nesses casos no artigo abaixo.

Artigo relacionado: É possível aumentar o valor estimado após o desenvolvimento do sistema?[ja]

No artigo acima, explicamos que é importante determinar se houve tarefas que excederam o escopo do trabalho que estava relacionado à remuneração. Em outras palavras, em relação a este artigo, se o fornecedor concordou com o desenvolvimento de algo que não estava inicialmente especificado (ou seja, o exemplo negativo neste artigo), então é possível permitir uma solicitação de remuneração adicional.

Resumo

No desenvolvimento de sistemas, o papel que o fornecedor deve desempenhar é, numa certa perspectiva, determinado de acordo com o conteúdo do contrato e das especificações. No entanto, considerando que estão a ser confiadas tarefas com base numa elevada confiança como especialistas, percebe-se que a realidade não é determinada apenas por formalidades. No entanto, ao compreender essa realidade, deve-se entender que a lei desempenha um papel importante.