O que é a gestão de mudanças no desenvolvimento de sistemas do ponto de vista jurídico?

Em projetos de desenvolvimento de sistemas, é comum que o conteúdo previamente explicado pelo usuário seja alterado à medida que o trabalho avança. Portanto, mesmo como fornecedor que aceita o trabalho, pode haver necessidade de concordar com alterações no conteúdo do contrato que foi celebrado uma vez.

Este artigo explica como lidar com o fenómeno das “alterações” que ocorrem posteriormente, do ponto de vista legal, em relação a projetos de desenvolvimento de sistemas que não avançam conforme o esperado.

Por que os projetos de desenvolvimento de sistemas são “alterados” após a conclusão?

O desenvolvimento de sistemas é um trabalho conjunto entre fornecedores e usuários

O desenvolvimento de sistemas geralmente passa por uma fase de planeamento e proposta, onde os requisitos de desenvolvimento são definidos e um contrato é celebrado. Após a celebração do contrato, o processo passa por várias fases de design, implementação de acordo com o design, e finalmente testes antes de ser concluído. Em todo este processo, é claro que o fornecedor, como especialista em desenvolvimento de sistemas, tem uma ampla gama de responsabilidades, mas também há um certo grau de obrigação de cooperação por parte do usuário. Em particular, a cooperação do usuário é importante em processos como a identificação das funções que o sistema deve ter (definição de requisitos), a aparência e a sensação de operação do lado do ecrã (design básico), e a verificação se o que foi feito está de acordo com os requisitos (teste ou aceitação). Para uma explicação geral das obrigações que o usuário tem no desenvolvimento de sistemas, consulte o seguinte artigo.

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

Apesar da obrigação de cooperação, os usuários tendem a pedir mudanças

No entanto, não é sempre que os usuários, que não são especialistas em desenvolvimento de sistemas, conseguem transmitir todas as informações necessárias para o desenvolvimento de sistemas de forma completa e abrangente ao fornecedor. Na realidade, devido à natureza detalhada e meticulosa do trabalho, muitas vezes é difícil para o usuário prever que tipo de factos terão um significado decisivo nas fases posteriores. Ironicamente, é mais provável que os factos mais importantes surjam aos poucos. Devido a estas circunstâncias, na realidade dos projetos, embora o ideal seja “passar de uma fase a outra de uma só vez”, é importante considerar como gerir as “alterações” que podem ocorrer posteriormente, assumindo que várias alterações podem ser feitas após o facto.

O que é um Documento de Gestão de Alterações

Contextos em que o Documento de Gestão de Alterações é utilizado

O Documento de Gestão de Alterações é um documento usado quando o utilizador solicita ao fornecedor alterações nas especificações ou adições de funcionalidades, divergindo do conteúdo explicado previamente. Como mencionado anteriormente, durante fases como a definição de requisitos e o design básico, o utilizador também tem a obrigação de cooperar com o trabalho do fornecedor, mas é possível que surjam pedidos diferentes nos processos subsequentes.

Exemplos de situações em que o Documento de Gestão de Alterações é necessário incluem:

• Quando há omissões na definição de requisitos ou no design básico, e é necessário solicitar a adição de funcionalidades posteriormente
• Quando, durante o desenvolvimento, é necessária uma revisão da política de negócios, entre outros, e uma alteração das especificações se torna necessária

Estes são apenas alguns exemplos.

Além disso, em relação a tópicos como a adição de funcionalidades e alteração de especificações, o que mais preocupa quem recebe o trabalho é se a alteração do valor estimado é legalmente permitida. Este ponto é explicado em detalhe num artigo separado.

https://monolith.law/corporate/increase-of-estimate[ja]

O Documento de Gestão de Alterações serve como base para avaliar a validade do conteúdo da estimativa quando se aumenta a estimativa posteriormente. Ao fazer uma cobrança com base numa estimativa aumentada posteriormente, a criação de um Documento de Gestão de Alterações torna-se importante para evitar disputas com a outra parte (e também para dar credibilidade ao seu argumento em caso de disputa).

Informações a incluir no Documento de Gestão de Alterações

Então, quais são os itens que devem ser incluídos no Documento de Gestão de Alterações, do ponto de vista legal? O mecanismo de contrato que utiliza o Documento de Gestão de Alterações para responder a alterações de especificações e adições de funcionalidades já é amplamente reconhecido em geral. Portanto, ao verificar modelos de cláusulas contratuais apresentadas por agências governamentais, como o Contrato Modelo do Ministério da Economia, Comércio e Indústria, torna-se geralmente claro quais itens devem ser mantidos como registro.

(Procedimento de Gestão de Alterações)
Artigo 37 Se o Partido A ou B receber uma proposta de alteração com base no Artigo 34 (Alteração do Documento de Especificações do Sistema, etc.), Artigo 35 (Aprovação do Usuário de Documentos Intermediários), Artigo 36 (Tratamento de Itens Indeterminados), deverá, dentro de ○ dias a partir da data de recebimento, entregar à outra parte um documento escrito (doravante referido como “Documento de Gestão de Alterações”) que contenha os seguintes itens, e o Partido A e B deverão discutir a aprovação ou não da referida alteração no Conselho de Comunicação estipulado no Artigo 12.
① Nome da alteração
② Responsável pela proposta
③ Data
④ Motivo da alteração
⑤ Detalhes da alteração, incluindo as especificações relacionadas à alteração
⑥ Se a alteração requer custos, o valor
⑦ Cronograma de trabalho de alteração, incluindo o período de consideração
⑧ Outros impactos que a alteração terá nos termos deste contrato e do contrato individual (prazo de trabalho ou prazo de entrega, taxa de comissão, cláusulas contratuais, etc.)

Lendo o texto do artigo diretamente e confirmando os itens recomendados para inclusão, não é necessária mais explicação. Para evitar problemas de “disse/não disse” mais tarde, é importante registrar o histórico de alterações de forma detalhada e específica.

Ao declarar claramente esses itens e combiná-los com a assinatura ou selo do responsável/decisor do fornecedor e do utilizador, em caso de litígio, terá o mesmo significado que um contrato como prova.

Coisas boas para saber sobre a gestão de mudanças

A gestão de mudanças é geralmente algo que deve ser feito em conjunto com a gestão de tarefas

A razão para criar um documento de gestão de mudanças é que, ao gerir o histórico de mudanças, pode-se dizer que o objetivo é conduzir o projeto para a realização (ou, se não for possível alcançar a realização, evitar a perseguição injusta de responsabilidades). Para atingir este objetivo na prática, a criação de um documento de gestão de mudanças é muitas vezes feita em conjunto com a criação e atualização de uma tabela de gestão de tarefas. Ou seja, depois de gerir o histórico de mudanças na tabela de gestão de mudanças, os itens de mudança acordados são incorporados nos itens da tabela de gestão de tarefas como tarefas a serem abordadas no futuro.

É melhor também estabelecer regras sobre como conduzir discussões sobre mudanças

Não só a forma como se gere as mudanças, mas também a forma como se conduzem as discussões sobre as mudanças, se estabelecerem regras para isso, pode-se esperar que a resposta às mudanças seja suave. Este ponto é particularmente importante quando se adota um método de desenvolvimento, como o desenvolvimento ágil, que pressupõe que várias mudanças serão feitas posteriormente. Na prática, há muitos exemplos de regras que estipulam quando a outra parte deve responder a um pedido de discussão sobre a gestão de mudanças.

Discussões sobre mudanças e o dever de agir de boa fé

Quando se trata de alterar um contrato sobre o qual ambas as partes concordaram uma vez, isso é, por assim dizer, também um ato de celebrar um novo contrato. Em princípio, dado que o contrato é baseado na livre vontade das partes, o fornecedor não tem obrigação de concordar com o contrato de alteração. No entanto, se este aspecto dos direitos for demasiado enfatizado, pode haver preocupações de que o projeto de desenvolvimento do sistema não progrida suavemente na prática.

Por isso, muitas vezes se vê na prática que os contratos especificam algo como um “dever de agir de boa fé nas discussões sobre mudanças”, e há exemplos de disposições que permitem reivindicações de indemnização por danos se o fornecedor não responder de boa fé às mudanças.

Um exemplo de tal disposição seria o seguinte (a seguir, um exemplo de disposição do artigo é citado a partir do “Modelo de Contrato Básico/Contrato Individual” criado oficialmente pela Organização Independente de Promoção do Processamento de Informação).

Artigo 4, Parágrafo 3: Nas discussões sobre mudanças, as partes devem discutir de boa fé se devem fazer a mudança, considerando o objeto da mudança, a possibilidade de mudança, o impacto da mudança no preço e no prazo de entrega, etc.

Regras sobre o método de mudança

Como mencionado anteriormente, quando se faz uma mudança, é “seguro” do ponto de vista legal ter uma discussão sobre a mudança cada vez. No entanto, em projetos de pequena escala, pode haver casos em que não é necessário estabelecer a forma como as discussões sobre mudanças são conduzidas. Nesse caso, em vez de estabelecer regras para discussões, pode-se considerar um método em que as mudanças são feitas apenas quando o responsável do usuário e do fornecedor assina e carimba o documento de gestão de mudanças, mesmo sem discussões. Se permitir mudanças facilmente apenas com um acordo verbal, pode tornar-se ambíguo se as mudanças foram feitas ou não, o que pode levar a grandes problemas mais tarde, por isso a gestão de documentos deve ser rigorosa.

No entanto, pode ser que até mesmo a preparação de documentos separados para a gestão de mudanças cada vez seja um fardo, e que se queira dar prioridade a uma resposta flexível. Nesse caso, uma opção seria documentar os assuntos relacionados à mudança nas atas da reunião. Quanto à forma como se mantêm as atas das reuniões no desenvolvimento de sistemas, isso é explicado em detalhe no seguinte artigo.

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

Resumo

Em ambientes onde as mudanças de especificações são frequentes, é verdade que muitas vezes se corre o risco de enfrentar problemas e disputas. No entanto, em tais ambientes onde se exige flexibilidade, enfatizar rigidamente a “importância da gestão” pode tornar difícil implementar medidas práticas.

A questão de como equilibrar a velocidade exigida nos negócios e a preparação para situações imprevistas muitas vezes varia dependendo da situação da empresa e do conteúdo do projeto. Acreditamos que é importante ter uma atitude de buscar a melhor maneira de fazer as coisas para cada empresa e projeto, levando em consideração o conteúdo deste artigo.