MONOLITH LAW OFFICE+81-3-6262-3248Dias da semana 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Quais são os problemas legais e contratuais relacionados ao desenvolvimento ágil?

IT

Quais são os problemas legais e contratuais relacionados ao desenvolvimento ágil?

Existem metodologias para o avanço do desenvolvimento de sistemas. O modelo mais clássico e comum é o modelo Waterfall, e muitos livros de direito que lidam com o desenvolvimento de sistemas discutem com base neste modelo. Neste artigo, explicaremos quais são os problemas legais relacionados ao desenvolvimento de sistemas baseado no modelo de desenvolvimento ágil, que é difícil de obter informações a partir de livros e outros recursos.

Desenvolvimento Ágil e Assuntos Jurídicos

Explicaremos as características do desenvolvimento ágil.

O que é um modelo em desenvolvimento de sistemas

Em projetos de desenvolvimento de sistemas, existe algo chamado modelo de desenvolvimento, que serve como uma estrutura para a compreensão geral do progresso. O exemplo mais representativo seria o chamado “modelo waterfall”. Ou seja, assim como a água que cai de uma vez só do “topo” para o “fundo” de um rio, este modelo envolve a realização de todas as etapas, como definição de requisitos, design, implementação, testes, etc., de uma só vez. O objetivo é minimizar o retrabalho e a duplicação de esforços, tornando-o um método adequado para avançar o trabalho de forma planejada.

Por outro lado, no modelo de desenvolvimento ágil, pequenos programas são implementados e testados repetidamente. Através deste processo iterativo de implementação e teste de pequenos programas, um sistema maior é gradualmente construído. Para uma explicação mais detalhada deste modelo de desenvolvimento de sistemas e uma comparação dos prós e contras de ambos os modelos de desenvolvimento, consulte o artigo abaixo.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Características do modelo de desenvolvimento ágil

Uma grande vantagem do desenvolvimento com o modelo ágil é a capacidade de entrar no trabalho real com um sentido de velocidade. Como as tarefas de “upstream”, como a definição de requisitos e a criação de documentos de design, e as tarefas de implementação do programa não estão separadas, é adequado para avançar de forma flexível, incluindo a resposta a adições e alterações de funcionalidades e alterações de especificações. Do ponto de vista jurídico, o que é particularmente importante para o sucesso do modelo de desenvolvimento ágil é como gerir a documentação e as alterações. No modelo de desenvolvimento ágil, os papéis e responsabilidades não são tão claramente definidos como no modelo waterfall. Além disso, como é um método que enfatiza a “velocidade” de execução e início, em vez de “gestão”, é fácil levar à insuficiência de vários documentos de design, especificações e atas de reuniões.

Além disso, em relação à gestão de alterações, o modelo de desenvolvimento ágil é suave na resposta a alterações, por isso há um risco de que o projeto possa incendiar-se ao responder a pedidos de alteração de especificações ao nível do local de trabalho, ignorando o processo de aprovação do tomador de decisões. Se isso acontecer, a vantagem do modelo de desenvolvimento de “resposta suave a alterações posteriores” pode tornar-se um risco de incêndio para o projeto.

Como gerir documentos e alterações no desenvolvimento ágil

Como gerir documentos e alterações de especificações no modelo de desenvolvimento ágil?

A importância da gestão de documentos

Num projeto de desenvolvimento baseado no modelo ágil, uma preocupação legal é a acumulação de interações verbais, que pode levar à falta de documentação. Explicamos em detalhe a importância da gestão de documentos em projetos de desenvolvimento de sistemas no seguinte artigo.

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

Nesse artigo, explicamos a importância da gestão de documentos em projetos de desenvolvimento de sistemas, tanto do ponto de vista da prevenção de conflitos (ou seja, “gestão legal preventiva”) como da preservação de provas em caso de conflito (ou seja, “gestão de crises”).

A implementação de um conselho de coordenação é eficaz na gestão de documentos

Quando se adota o modelo de desenvolvimento ágil, ao contrário do modelo waterfall, não há um plano claro preparado antecipadamente. Portanto, não basta apenas gerir a discrepância entre o plano e os resultados reais, há o risco de os custos aumentarem tanto financeira como temporalmente se tudo for deixado ao critério do local de trabalho.

Portanto, é eficaz que o responsável implemente a realização regular de um conselho de coordenação para facilitar o progresso do projeto. Quando o tamanho do desenvolvimento é pequeno, é verdade que é preferível reunir-se sempre que os responsáveis possam reunir-se, em vez de realizar regularmente um conselho de coordenação. No entanto, no caso do modelo de desenvolvimento ágil, o risco de não tratar de problemas atuais em tempo útil numa reunião é particularmente elevado. Portanto, é seguro incluir a realização regular de um conselho de coordenação no contrato. A forma de estipulação é indicada da seguinte forma no contrato modelo do Ministério da Economia, Comércio e Indústria.

(Estabelecimento do Conselho de Coordenação)

Artigo 12 A e B, até a conclusão deste projeto, para discutir o progresso, a gestão e o relatório de riscos, a implementação de trabalhos conjuntos e individuais por A e B, a confirmação do conteúdo a ser incluído nas especificações do sistema, a discussão e resolução de problemas, e outros assuntos necessários para a execução suave deste projeto, deverão realizar um Conselho de Coordenação. No entanto, (omissão).

2. O Conselho de Coordenação será realizado regularmente, em princípio, com a frequência estipulada no contrato individual, e além disso, será realizado a qualquer momento quando A ou B considerar necessário.

3. No Conselho de Coordenação, os responsáveis e os principais responsáveis de A e B, e aqueles que os responsáveis considerarem apropriados, estarão presentes. Além disso, A e B podem solicitar a presença de pessoas necessárias para a discussão no Conselho de Coordenação, e a outra parte deve cumprir, a menos que haja uma razão razoável para não o fazer.

4. B, no Conselho de Coordenação, irá preparar e submeter um relatório de gestão de progresso no formato acordado entre A e B, e irá confirmar o progresso com base nesse relatório de gestão de progresso, a existência de atrasos, as razões e medidas para os atrasos, se houver, a necessidade de alterar a estrutura de promoção estabelecida neste capítulo (mudança de pessoal, aumento ou diminuição, mudança de subcontratante, etc.), o estado de implementação das medidas de segurança, a existência de razões para alterar o contrato individual, o conteúdo das razões para alterar o contrato individual, se houver, e discutirá e confirmará os assuntos decididos, os assuntos a serem considerados continuamente, e o cronograma de consideração e as partes a considerar, se houver assuntos a serem considerados continuamente.

(Os parágrafos 5, 6 e 7 são omitidos.)

O ponto principal é que a existência do Conselho de Coordenação é legitimada pelas cláusulas contratuais, e é atribuído um significado diferente das reuniões que são realizadas de forma ad hoc.

Como aproveitar o Conselho de Coordenação para a gestão de alterações

Além disso, no desenvolvimento ágil, é uma premissa que os itens acordados inicialmente entre as partes serão alterados posteriormente. Portanto, é muito importante como gerir a situação das alterações de especificações posteriores.

Neste caso, se o Conselho de Coordenação for realizado regularmente, a gestão de alterações também será muito suave. Por exemplo, a discussão sobre alterações é realizada no Conselho de Coordenação, e se houver um pedido de discussão sobre alterações de uma das partes, a outra parte é obrigada a responder a essa discussão no contrato. (A seguir, é extraída a disposição do contrato modelo do Ministério da Economia, Comércio e Indústria.)

(Procedimento de Gestão de Alterações)

Artigo 37 A ou B, quando receber uma proposta de alteração de (omissão) da outra parte, deverá entregar à outra parte um documento (doravante referido como “Documento de Gestão de Alterações”) que contenha os seguintes itens, dentro de ○ dias a partir da data de recebimento, e A e B deverão discutir a aceitação ou rejeição da referida alteração no Conselho de Coordenação estabelecido no Artigo 12. (Os itens a serem incluídos são omitidos)

Os pontos da disposição acima podem ser organizados da seguinte forma:

  • A unificação do método de aceitação de propostas de alteração no formato de “Proposta de Alteração”
  • Estabelecimento de um prazo para a discussão sobre a proposta de alteração após a sua recepção → Mesmo que não seja especificado como “dentro de ◯ dias”, pode ser substituído por palavras como “imediatamente”.
  • A unificação do local de discussão sobre a aceitação ou rejeição de alterações no “Conselho de Coordenação”

Em outras palavras, para evitar mal-entendidos como “Eu fiz uma proposta de alteração, não fiz”, “Eu respondi à aceitação ou rejeição da alteração, não respondi”, o método de procedimento é clarificado.

É exigido um entendimento das obrigações de boa fé e dos princípios de lealdade

Até agora, apresentamos modelos de cláusulas contratuais relacionadas com “Conselhos de Comunicação”, “Negociações de Alterações”, entre outros. No entanto, para uma compreensão essencial destes, é importante considerar questões como “Obrigações de Boa Fé” e “Princípios de Lealdade”. O modelo de desenvolvimento ágil, em primeiro lugar, tende a ser difícil de prosseguir sem uma relação de confiança entre o cliente e o fornecedor. Isto porque se dá prioridade à velocidade de início do trabalho real, e os procedimentos até ao início são geralmente mantidos ao mínimo. Por isso, é comum na prática incluir cláusulas que impõem “Obrigações de Boa Fé” à outra parte.

Artigo 4, parágrafo 3: Nas negociações de alterações, devem ser considerados o objeto da alteração, a possibilidade de alteração, o impacto da alteração no preço e no prazo de entrega, etc., e ambas as partes devem discutir sinceramente se devem proceder à alteração.

Isto é para prevenir uma abordagem que trai a outra parte com uma teoria legal formalista, como “Se concordar com a alteração do contrato ou não, é inteiramente à discrição da parte que recebe a proposta, e não há obrigação de cumprir a força”, em negociações que foram baseadas numa relação de confiança desde o início. Reflete também os princípios legais que se aplicam às transações entre indivíduos, não apenas ao desenvolvimento de sistemas.

Artigo 1, parágrafo 2 do Código Civil Japonês

O exercício de direitos e o cumprimento de obrigações devem ser realizados com lealdade e sinceridade.

A lei não necessariamente valoriza apenas o “conteúdo do contrato escrito” ou “a redação do artigo” que é formalista. Especialmente em transações com a outra parte, deve ser usado de forma flexível, incorporando a “lealdade” e “sinceridade” substanciais. Além disso, temos um artigo detalhado sobre o fato de que as “obrigações” impostas pela lei não são necessariamente baseadas no procedimento de “contrato”.

https://monolith.law/corporate/system-development-unlawful-responsibility[ja]

Resumo

É claro que é importante entender o risco de os procedimentos administrativos e a estrutura de gestão se tornarem negligentes em projetos de desenvolvimento de sistemas baseados no modelo de desenvolvimento ágil. No entanto, não é apenas isso, acredita-se que também é importante entender as características flexíveis inerentes à lei, como o “princípio da boa fé”, e ter a atitude de aplicá-las na prática.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Retornar ao topo