Quais são os pontos-chave a verificar num contrato de desenvolvimento de sistemas baseado em empreitada?

O Ministério da Economia, Comércio e Indústria japonês (METI) apresenta cláusulas modelo para contratos de desenvolvimento de sistemas de TI nas suas “Diretrizes para a Melhoria da Confiabilidade dos Sistemas de Informação”. Com a disseminação da Internet, o impacto social de interrupções ou diminuições de funcionalidade nos serviços e operações devido a falhas nos sistemas de informação está a tornar-se cada vez mais grave. Ao mesmo tempo, a melhoria da confiabilidade e segurança dos sistemas é uma questão urgente. No entanto, o tipo de contrato de desenvolvimento de sistemas de TI tende a tornar o conteúdo da transação obscuro. Portanto, estas cláusulas visam tornar visível e esclarecer a divisão de papéis e as relações de responsabilidade. Neste artigo, explicaremos os pontos a verificar nos contratos quando se celebra um contrato de empreitada para o desenvolvimento de sistemas de TI, citando as cláusulas do contrato modelo do METI.

Desenvolvimento de Sistemas e Contratos de Empreitada

O que é um Contrato de Empreitada

Um contrato de empreitada é definido no Código Civil Japonês da seguinte forma:

Artigo 632
Um contrato de empreitada entra em vigor quando uma das partes se compromete a completar um trabalho e a outra parte se compromete a pagar por esse trabalho.

No contrato de empreitada, é necessário que se comprometa a “completar um trabalho”. Por exemplo, se o objetivo do contrato é criar um determinado sistema até uma data específica, a obrigação do fornecedor é “completar o sistema até a data especificada”. Se não conseguir completar o sistema até a data prometida, pode ser responsabilizado por incumprimento devido a atraso na execução. No entanto, se o sistema for concluído e entregue até a data especificada e depois forem encontradas falhas, a obrigação do fornecedor já terá sido cumprida, por isso o incumprimento não será um problema, e a questão passará a ser a responsabilidade pela garantia de defeitos. No desenvolvimento de sistemas, a “conclusão do trabalho” é reconhecida em qualquer situação, conforme explicado em detalhe no seguinte artigo.

Diferenças em relação ao Contrato de Mandato

No contrato de empreitada, o fornecedor tem a obrigação de completar o trabalho, por isso, se o produto entregue tiver defeitos, será responsável pela garantia desses defeitos. Em contraste, num contrato de mandato, não há obrigação de completar o trabalho, por isso não há responsabilidade pela garantia de defeitos como num contrato de empreitada. No entanto, se for reconhecido um dever de cuidado na gestão durante o processo de tratamento do trabalho, pode haver uma responsabilidade separada por incumprimento, como indemnização por danos. Quais responsabilidades são problemáticas num contrato de desenvolvimento de sistemas é explicado em detalhe no seguinte artigo.

Modelo de Cláusulas Contratuais e Pontos de Verificação para Contratos de Prestação de Serviços

Apoio na Criação de Definições de Requisitos

A definição de requisitos é um processo que compila as especificações de requisitos do sistema que o utilizador pretende construir. Na fase de definição de requisitos, considera-se a direção da construção do sistema e decide-se que tipo de sistema construir. Dado que os resultados não podem ser especificamente previstos, o contrato modelo do Ministério da Economia, Comércio e Indústria japonês (METI) estabelece-o como um tipo de mandato quase-delegado. Para mais detalhes, consulte o artigo abaixo.

https://monolith.law/corporate/system-development-contract-check-quasi-mandate[ja]

Criação de Documentos de Design Externo

(Implementação do trabalho de criação de documentos de design externo)
Artigo ○ O segundo contratante, após a celebração do contrato individual especificado no artigo ○, realizará o trabalho de criação de documentos de design externo para o software em questão, com base no documento de definição de requisitos confirmado de acordo com as disposições do artigo ○.

2. Ao implementar o trabalho de criação de documentos de design externo, o segundo contratante pode solicitar a cooperação necessária ao primeiro contratante, e o primeiro contratante deve responder a essa solicitação em tempo hábil.

A criação de documentos de design externo é um trabalho que estabelece o uso de partes relacionadas à interface, como telas e formulários. Em princípio, os documentos de design externo devem conter todas as informações necessárias para que o fornecedor possa desenvolver o programa com base neles. Os documentos de design externo incluem detalhes sobre o uso do formato, mas quem pode alterar as especificações solicitadas é o lado do usuário que determina o conteúdo do trabalho. No entanto, se o documento de definição de requisitos, que é o resultado da fase anterior ao trabalho de criação de documentos de design externo, puder definir claramente as necessidades do usuário e o conteúdo do trabalho a ser concluído pelo fornecedor, é possível celebrar um contrato no qual o fornecedor assume a liderança na criação de documentos de design externo, em um formato de contrato.

O primeiro parágrafo estabelece que o fornecedor é o principal executor do trabalho, uma vez que este processo é contratado. No entanto, mesmo em contratos de empreitada, como o design externo tem uma grande parte relacionada à determinação do conteúdo do trabalho do usuário, é necessária a participação ativa do usuário. Portanto, o segundo parágrafo esclarece que o fornecedor pode solicitar a cooperação do usuário para considerar e determinar as especificações do sistema, e que o usuário deve responder a isso em tempo hábil, tornando claro que a consideração das especificações do sistema é um trabalho conjunto entre o fornecedor e o usuário.

(Celebração de contratos individuais relacionados ao trabalho de criação de documentos de design externo)
Artigo ○ O primeiro e o segundo contratantes, em relação ao trabalho de criação de documentos de design externo, decidirão as condições de transação descritas no artigo ○, parágrafo ○, após discussão, e celebrarão um contrato individual relacionado ao trabalho de criação de documentos de design externo.

O escopo do trabalho de criação de documentos de design externo será acordado em um contrato individual, de acordo com as condições de transação estabelecidas na cláusula anterior.

(Reunião de discussão de design externo)
Artigo ○ O segundo contratante, para esclarecer ou confirmar os assuntos necessários para a criação de documentos de design externo, realizará uma reunião de discussão de design externo (a seguir referida como “reunião de discussão” neste parágrafo) na frequência considerada necessária, e o primeiro contratante participará dela.

2. O primeiro contratante também pode realizar uma reunião de discussão quando considerar necessário para a criação de documentos de design externo, e o segundo contratante participará dela.

3. Se, como resultado da discussão na reunião de discussão de design externo, o primeiro contratante tentar alterar o conteúdo do documento de definição de requisitos e isso resultar em uma alteração nas condições do contrato individual, como o período de trabalho e a taxa de comissão, o procedimento do artigo 33 (alteração do conteúdo deste contrato e do contrato individual) será seguido.

A criação de documentos de design externo, que determina interfaces como telas e formulários, requer trabalho colaborativo entre o usuário e o fornecedor. Como este processo é contratado, o primeiro parágrafo estabelece que o fornecedor é o anfitrião da reunião de discussão e o usuário participará dela. A clarificação ou confirmação dos assuntos necessários para a criação de documentos de design externo será realizada em todas as reuniões de discussão, e o fornecedor e o usuário serão vinculados pelos resultados da discussão na reunião.

O segundo parágrafo estabelece que o usuário também pode realizar uma reunião de discussão quando considerar necessário para a implementação do trabalho de criação de documentos de design externo.
O terceiro parágrafo estabelece que, se a discussão resultar em uma alteração no conteúdo do documento de definição de requisitos pelo usuário, e isso afetar o período de trabalho e a taxa de comissão estipulados no contrato individual, o procedimento para alterar o conteúdo deste contrato e do contrato individual, estabelecido em outra cláusula, será seguido.

(Entrega de documentos de design externo)
Artigo ○ O segundo contratante entregará ao primeiro contratante os documentos de design externo e o pedido de aceitação de documentos de design externo (também um recibo de entrega) até a data especificada no contrato individual.

Como este processo é contratado, o fornecedor entregará os documentos de design externo, etc., como produtos acabados.

(Aprovação e confirmação de documentos de design externo)
Artigo ○ O primeiro contratante, dentro do período estipulado no contrato individual (a seguir referido como “período de inspeção de documentos de design externo”), verificará se os documentos de design externo estão em conformidade com o documento de definição de requisitos confirmado de acordo com as disposições do artigo ○ e os assuntos decididos na reunião de discussão de design externo especificada no artigo ○, e se não há erros lógicos, e como prova de aprovação de conformidade e ausência de erros lógicos, os responsáveis de ambos os contratantes assinarão e carimbarão o documento de aprovação de documentos de design externo. No entanto, se, como resultado da inspeção, for descoberto que os documentos de design externo não estão em conformidade com o documento de definição de requisitos confirmado de acordo com as disposições do artigo ○ e os assuntos decididos na reunião de discussão de design externo, ou se for descoberto um erro lógico, o segundo contratante criará uma versão corrigida dentro do prazo acordado após discussão e a apresentará ao primeiro contratante, e o primeiro contratante realizará novamente a inspeção e o procedimento de aprovação acima mencionados.

2. Se o primeiro contratante não apresentar objeções por escrito com razões específicas durante o período de inspeção de documentos de design externo, será considerado que o primeiro contratante aprovou os documentos de design externo no final do período de inspeção de documentos de design externo.

3. A aprovação do primeiro contratante de acordo com os dois parágrafos anteriores confirmará os documentos de design externo.

No processo de design externo, os requisitos necessários para a implementação de trabalhos subsequentes, como a criação de documentos de design interno, são confirmados, mas se a confirmação dos requisitos permanecer ambígua, podem surgir problemas no desenvolvimento subsequente. Esta cláusula estabelece o procedimento para inspecionar os documentos de design externo, que são a base para o trabalho de desenvolvimento subsequente, pelo usuário, e confirmá-los com a aprovação do usuário.

O primeiro parágrafo estabelece que o usuário inspecionará a conformidade dos documentos de design externo com o documento de definição de requisitos confirmado em outra cláusula e os assuntos decididos na reunião de discussão de design externo, bem como a ausência de erros lógicos. Pode haver casos em que é julgado necessário corrigir a inspeção para aprovação dos documentos de design externo, e a provisão de exceção neste parágrafo estabelece o procedimento neste caso.
O segundo parágrafo é uma disposição que considera que o usuário aprovou, mesmo que a assinatura de aprovação não tenha sido concluída, se o usuário não apresentar objeções dentro de um certo período de tempo. Entrar no design interno sem a aprovação do usuário pode causar problemas mais tarde, então esta cláusula tem a intenção de prevenir tais problemas.

E o terceiro parágrafo estabelece que os documentos de design externo serão confirmados com a aprovação do usuário.

(Responsabilidade pela garantia de defeitos)
Artigo ○ Após a confirmação do artigo anterior, se for descoberto que os documentos de design externo não estão em conformidade com o documento de definição de requisitos e os assuntos decididos na reunião de discussão de design externo especificada no artigo ○, ou se houver um erro lógico (a seguir referido como “defeito” neste artigo), o primeiro contratante pode solicitar ao segundo contratante que corrija o defeito, e o segundo contratante corrigirá o defeito. No entanto, o segundo contratante só será responsável por tal correção se o pedido for feito pelo primeiro contratante dentro de ○ meses após a confirmação do artigo anterior.

2. Não obstante o parágrafo anterior, se o defeito for menor e a correção dos documentos de design externo exigir um custo excessivo, o segundo contratante não será responsável pela correção especificada no parágrafo anterior.

3. As disposições do primeiro parágrafo não se aplicam quando o defeito é causado por documentos fornecidos pelo primeiro contratante ou instruções dadas pelo primeiro contratante. No entanto, isso não se aplica se o segundo contratante não informar que tais documentos ou instruções são inadequados, mesmo sabendo disso.

Esta cláusula estabelece a responsabilidade pela garantia de defeitos em relação aos documentos de design externo. O período de garantia de defeitos será determinado como um período considerado apropriado através de discussões entre as partes, levando em consideração a escala do sistema de informação e o preço, etc.

O primeiro parágrafo define como defeito a incompatibilidade dos documentos de design externo com o documento de definição de requisitos e os assuntos decididos na reunião de discussão de design externo, bem como os erros lógicos nos documentos de design externo.

O segundo parágrafo protege o fornecedor, estabelecendo que, mesmo que o defeito seja menor, se a correção do produto entregue exigir um custo excessivo, o fornecedor não será responsável pela correção gratuita, de acordo com a exceção do artigo 634, parágrafo 1, do Código Civil.

O terceiro parágrafo é uma disposição que, de acordo com a exceção do artigo 636 do Código Civil, se o defeito for causado por instruções ou documentos fornecidos pelo usuário, o fornecedor será isento da responsabilidade pela garantia, a menos que o fornecedor não informe que tais documentos ou instruções são inadequados, mesmo sabendo disso.

Por favor, note que a responsabilidade pela garantia de defeitos é uma disposição opcional, e se tal disposição não for estabelecida, o tratamento será feito de acordo com os princípios gerais do Código Civil. A responsabilidade pela garantia de defeitos é uma área que será grandemente afetada pela revisão do Código Civil que entrará em vigor em abril de 2020, e após a entrada em vigor da revisão do Código Civil, será uma área que será tratada de forma diferente do passado. Os detalhes são explicados no seguinte artigo.

https://monolith.law/corporate/defect-warranty-liability[ja]

Desenvolvimento de Software

(Implementação do Desenvolvimento de Software)
Artigo X O segundo partido, após a celebração do contrato individual especificado no Artigo 25, realizará o desenvolvimento de software, desde o design interno até o teste do sistema, como parte deste projeto, com base nas especificações do sistema confirmadas pelas seções anteriores.

2. Ao implementar o desenvolvimento de software, o segundo partido pode solicitar a cooperação necessária ao primeiro partido, e o primeiro partido deve responder apropriadamente quando solicitado a cooperar pelo segundo partido.

As cláusulas abaixo regulam o desenvolvimento de software realizado por fornecedores sob contrato. No processo de design interno do sistema, é comum que o objeto de desenvolvimento e as especificações sejam definidos até a fase anterior, portanto, o contrato modelo do Ministério da Economia, Comércio e Indústria define isso como um contrato.

(Celebração de Contrato Individual Relacionado ao Desenvolvimento de Software)
Artigo X O primeiro e o segundo partido, sobre o referido desenvolvimento de software, decidirão as condições de negociação descritas no Artigo X, Parágrafo X, após discussão, e celebrarão um contrato individual relacionado ao desenvolvimento de software.

O escopo do desenvolvimento de software, etc., será determinado por um contrato individual de acordo com as condições de negociação estabelecidas anteriormente.

(Entrega dos Produtos Entregáveis)
Artigo X O segundo partido entregará ao primeiro partido os produtos entregáveis especificados no contrato individual, juntamente com o pedido de aceitação (também uma nota de entrega), até a data especificada no contrato individual.
2. Quando a entrega ocorrer, o primeiro partido realizará a inspeção de acordo com as especificações de inspeção do próximo artigo, de acordo com as disposições do Artigo X (Aceitação do Software em Questão).
3. Ao entregar os produtos entregáveis, o segundo partido pode solicitar a cooperação necessária ao primeiro partido, e o primeiro partido deve responder prontamente quando solicitado a cooperar pelo segundo partido.
4. O risco de perda ou dano aos produtos entregáveis será suportado pelo segundo partido antes da entrega e pelo primeiro partido após a entrega.

Como este processo é um contrato, o software concluído, etc., será entregue como um produto entregável para inspeção. O primeiro parágrafo estipula que os produtos entregáveis serão entregues juntamente com o pedido de aceitação (também uma nota de entrega).

O segundo parágrafo estipula a implementação da inspeção pelo usuário.
O terceiro parágrafo estipula a obrigação de cooperação do usuário para a entrega no local de entrega especificado no contrato individual (por exemplo, quando a entrega é feita no escritório do usuário, quando a entrega é feita em um estado operacional no ambiente de operação real do usuário).
O quarto parágrafo é uma cláusula sobre o risco de perda ou dano aos produtos entregáveis, dividindo o momento da transferência do risco pela transferência do controle físico.

(Aceitação do Software em Questão)
Artigo X Para o software em questão entre os produtos entregáveis, o primeiro partido deve inspecionar de acordo com as especificações de inspeção do artigo anterior dentro do período especificado no contrato individual (doravante referido como “período de inspeção”) e verificar se as especificações do sistema e o software em questão correspondem.

2. Se o software em questão for compatível com a inspeção do parágrafo anterior, o primeiro partido deve assinar e carimbar o certificado de aprovação da inspeção e entregá-lo ao segundo partido. Além disso, se o software em questão não passar na inspeção do parágrafo anterior, o primeiro partido deve entregar prontamente ao segundo partido um documento que indique claramente a razão específica para a falha e solicitar correção ou complementação, e quando a razão para a falha for reconhecida, o segundo partido deve corrigir gratuitamente dentro do prazo acordado após a discussão e entregar ao primeiro partido, e o primeiro partido deve realizar novamente a inspeção especificada no parágrafo anterior na medida necessária.

3. Mesmo se o certificado de aprovação da inspeção não for entregue, se o primeiro partido não apresentar objeções por escrito indicando uma razão específica durante o período de inspeção, o software em questão será considerado como tendo passado na inspeção especificada neste artigo.

4. A aceitação do software em questão será concluída com a aprovação da inspeção especificada neste artigo.

Como este processo é um contrato, este artigo estipula o procedimento para a aceitação do software entregue.

O primeiro parágrafo estipula que o software em questão deve ser inspecionado de acordo com as especificações de inspeção dentro do período de inspeção e verificado se as especificações do sistema e o software em questão correspondem.
O segundo parágrafo obriga o fornecedor a corrigir e entregar a versão corrigida ao usuário se for determinado que o software em questão não está em conformidade com as especificações do sistema.
O terceiro parágrafo é para prevenir a extensão da aceitação devido à conveniência do usuário, estabelecendo uma disposição de aceitação presumida.
O quarto parágrafo especifica claramente que a aceitação do software em questão é concluída com a aprovação da inspeção.

(Responsabilidade pela Garantia de Defeitos)
Artigo X Após a conclusão da inspeção do artigo anterior, se for descoberta uma discrepância (incluindo bugs, doravante referida neste artigo como “defeito”) entre os produtos entregáveis e as especificações do sistema, o primeiro partido pode solicitar ao segundo partido a correção do referido defeito, e o segundo partido deve corrigir o referido defeito. No entanto, o segundo partido só será responsável pela correção se o pedido for feito pelo primeiro partido dentro de X meses após a conclusão da aceitação do artigo anterior.
2. Não obstante o parágrafo anterior, se o defeito for menor e a correção do produto entregável exigir um custo excessivo, o segundo partido não será responsável pela correção especificada no parágrafo anterior.
3. As disposições do primeiro parágrafo não se aplicam quando o defeito é causado por documentos fornecidos pelo primeiro partido ou instruções dadas pelo primeiro partido. No entanto, isso não se aplica se o segundo partido não informar que tais documentos ou instruções são inadequados, sabendo que são inadequados.

Como este processo é um contrato, este artigo estipula a responsabilidade pela garantia de defeitos para os produtos entregáveis. A fronteira entre a responsabilidade por não cumprimento da obrigação quando o desempenho não foi realizado (o trabalho não foi concluído) e a responsabilidade pela garantia de defeitos após a conclusão do desempenho (o trabalho foi concluído) é difícil de determinar na prática. Há um precedente judicial (Decisão do Tribunal Distrital de Tóquio, 22 de abril de 2002) que afirma que se deve julgar se o sistema foi concluído ou não com base em se o trabalho foi concluído até a última etapa planejada no contrato original. Se um defeito for descoberto após a entrega e a aprovação da inspeção do software que foi concluído até a última etapa planejada, a responsabilidade pela garantia de defeitos será aplicada em princípio.

O primeiro parágrafo define a “discrepância com as especificações do sistema” que ocorreu no desenvolvimento de software como um defeito. Para deficiências funcionais, etc., que ocorreram na fase de design externo, a responsabilidade será determinada pelas disposições sobre a responsabilidade pela garantia de defeitos na fase de design externo, etc., e não por este artigo. O período de garantia de defeitos será determinado como um período apropriado através de discussões entre as partes, levando em consideração a escala do sistema de informação e o preço, etc.

O segundo parágrafo estabelece uma disposição semelhante ao Artigo 634, Parágrafo 1, Proviso do Código Civil, mesmo que o defeito seja menor, se a correção do produto entregável exigir um custo excessivo, é cruel exigir a correção gratuita do fornecedor.

O terceiro parágrafo é uma disposição que, semelhante ao Artigo 636, Proviso do Código Civil, o fornecedor não é responsável pela garantia se o defeito for causado por instruções ou documentos fornecidos pelo usuário, mas se o fornecedor não indicar que tais documentos ou instruções são inadequados, sabendo que são inadequados, ele não será isento da responsabilidade pela garantia.

Para mais detalhes sobre quando um defeito é reconhecido e o conteúdo específico da responsabilidade quando um defeito é reconhecido, consulte o artigo abaixo.

https://monolith.law/corporate/defect-warranty-liability[ja]

Assistência na Preparação e Transição de Operação de Software

Na fase de aceitação e implementação do sistema, é comum que o utilizador tome a iniciativa. No contrato modelo do Ministério da Economia, Comércio e Indústria japonês (METI), é estipulado que o utilizador é o principal responsável, e o fornecedor apoia nesta tarefa, numa forma de subdelegação.

Decisão sobre a natureza do contrato

Para determinar a natureza de um contrato, é necessário considerar o contrato como um todo e o seu objetivo. O objetivo pode ser “fornecer um produto finalizado” ou pode ser que o fornecedor “execute o trabalho de forma razoável”. Uma indicação geral seria se o conteúdo do produto final a ser concluído foi determinado de forma concreta e se o projeto estava a progredir nessa direção. Para mais detalhes sobre quais aspectos específicos devem ser considerados, consulte o artigo abaixo.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]