IIIDo Direito
1. Uma vez que o âmbito objectivo dos recursos é delimitado pelas conclusões apresentadas pelos recorrentes (arts. 635º, nº 4, e 639º, do NCPC), apreciaremos, apenas, as questões que ali foram enunciadas.
Nesta conformidade, a única questão a resolver é a seguinte.
- -Alteração da matéria de facto.
- -Cumprimento/Incumprimento do contrato.
2. A recorrente impugna a decisão da matéria de facto, invocando que: a matéria dos factos provados 7. e 8. deve ser dada por provada, segundo a redacção que propõe, retirando-se a a) dos factos não provados; que o facto provado 2. deve ficar provado, mas com alteração e vários aditamentos; e, ainda, os factos provados 17. e 18., que devem ser fundidos, com modificação da sua redacção, que indica. Tudo de acordo com os meios probatórios que menciona (cfr. conclusões de recurso 1. a 22.).
Por sua vez, a recorrida opõe-se, conforme as conclusões (as B a M) das suas contra-alegações de recurso.
Na motivação da decisão da matéria de facto escreveu-se que:
“O tribunal formou a sua convicção mobilizando os documentos juntos aos autos, concatenados com o teor das declarações de parte do representante legal da autora e do representante legal da ré e dos depoimentos das testemunhas ouvidas em sede de audiência de julgamento, e ainda em conjugação com as regras da experiência comum, levando em consideração as regras legais de repartição do ónus da prova, nos termos que abaixo se consignam.
Quanto à prova documental, foi apreciado e valorado o teor dos seguintes elementos documentais juntos aos autos:
(…)
- -Apresentação da C... (documento 2 junto com a oposição);
- -Proposta para a C... apresentada pela A... (documento 3 junto com a oposição);
- -Contrato de prestação de serviços celebrado entre as partes (documento 4 junto com a oposição);
(…)
Foram valoradas as declarações de parte do representante legal da autora DD (administrador da A..., S.A. desde 2017) que referiu que a ré encomendou software para e-commerce, que incluía site e app móveis de IOS e Android. Foi explicado que o desenvolvimento de software seguiu um método flexível – modelo Scrum – fracionado em sprints de 2 semanas. Durante os vários sprints, segundo o representante legal da autora, as partes iam acordando nos próximos passos e nos ajustes a fazer ao projeto inicialmente definido. Reiterou por diversas vezes o representante legal da autora que o produto que foi inicialmente contratualizado poderia, no final dos sprints, não coincidir com o produto alcançado, uma vez que o backlog (uma espécie de caderno de encargos) ia sendo alterado por acordo de ambas as partes. Segundo o representante legal da autora, aquilo que se obrigaram, que no seu entender foi um “pacote” de tempo da equipa a fim de desenvolver o produto pretendido pela ré, estava concluído. Ainda que genericamente, referiu igualmente a existência de instabilidade de serviços da ré, nomeadamente o ORCA.
Confrontado com o documento 7 junto com a oposição referiu o representante legal que os serviços nele elencados não estão completos porque nada dizem sobre a lógica do negócio a implementar, ponto essencial para desenvolver as aplicações que a ré pretendia.
Perante o consumo de sprints sem que o projeto se encontrasse a ser desenvolvido como inicialmente projetado, a autora sugeriu que se parasse o projeto a fim de a ré definir o objeto do negócio, o que foi recusado.
Quanto ao produto entregue a final, o representante legal da autora referiu que foi entregue uma versão em pré-produção (versão beta) que seria gerida pela ré, sendo que estava utilizável.
Quanto ao funcionário EE, foi referido que o mesmo trabalhava na vertente de lógica de negócio, tendo saído da empresa da autora em março de 2020, num momento em que os sprints contratados já se haviam consumido.
O objetivo inicialmente delineado, referiu o representante legal da autora, foi a conceção de 2 aplicações móveis, BackOffice e uma aplicação de gestão. Quanto à aplicação IOS, a mesma nunca foi entregue, admitiu, afirmando que tal se deveu, na realidade, ao facto de a ré nunca ter entregado o código da app store para que pudesse ser a aplicação publicada. No entanto, entregaram a versão Android da aplicação. Quanto à entrega da aplicação de BackOffice, o representante legal da autora mostrou-se menos seguro quanto à sua efetiva entrega.
Questionado sobre o motivo do atraso na entrega das aplicações que tinham ficado definidas, o representante legal da autora atribui à falta de definições do plano apresentado pela ré a culpa pelo atraso. O representante legal da autora afirmou que o Shopify não foi integrado na aplicação, tendo o representante legal da ré, nas respetivas declarações de parte, e em complemento, referido que abdicou da tal integração por causa dos atrasos.
Declarações de parte do representante legal da ré FF (sócio gerente da sociedade ré desde 2019) apresentou uma versão diversa daquela que havia sido apresentada pelo representante legal da autora, porquanto foi insistindo variadas vezes que o objeto contratado consistia no desenvolvimento de um produto, negando perentoriamente que não foi adquirido tempo e que não foi celebrado um contrato de prestação de serviços.
Referiu BB que o modelo adotado consistir numa “parceria” da qual resultavam obrigações para ambas as partes: tudo o que consistia em lógica de negócio incumbia à autora de desenvolver.
De forma coincidente, o representante legal da ré identificou igualmente um atraso no desenvolvimento do projeto, pelo que negou, não só perante o tribunal, como também perante a autora, segundo disse, que tal atraso se devesse à falta de colaboração da ré no desenvolvimento de integrações que estavam dependentes da ré. Aquando da reunião que existiu a fim de ser proposto, pela autora a pausa do projeto, as aplicações móveis, segundo o representante legal da ré, ainda não estavam desenvolvidas e faltam cerca de 2 sprints para terminar o tempo contratado.
Aquando da entrega da versão-teste da app Android, referiu os que os funcionários da ré verificaram a existência de problemas bloqueantes que foram de imediato reportados à autora (cfr. documento 12 junto com a contestação). Relatou o representante legal da ré alguns dos problemas identificados: a aplicação não mostrava o estado do envio, não permitia o pagamento através do paypal, a referência multibanco não era gerada e a fatura só era gerada na primeira utilização. Algumas versões-teste enviadas pela autora, segundo o representante legal da ré, não permitiam fazer o seu respetivo download. Os problemas reportados, segundo o representante legal da ré, não foram totalmente resolvidos. A ré sanou sozinha e sem auxílio da autora o problema de integração da Paypal.
Assumindo que a ré não pagou a última tranche do pagamento, referiu o representante legal da ré que não procedeu ao pagamento porque não tinham o MVP (minimum viable product) sendo que a não apresentação de um produto a funcionar e viável não era imputável à ré. Referiu que sempre deu acesso a todos os serviços que a autora precisou para fazer as devidas integrações.
Explicou, por fim, o representante legal da ré que os dois blocos macro contratados consistiam no BackOffice: que consistia no algoritmo necessário para a encomenda, desta a criação do envio até à faturação, pelo que este interface seria posteriormente ligado às aplicações móveis.
Foram valorados os depoimentos das seguintes testemunhas:
- CC (gestor de projetos na A... há 10 anos) referiu, quando confrontado com o documento 16 junto com a oposição, que a ré demorava a responder às solicitações da autora o que para além de traduzir um juízo subjetivo, é contrariado pelos sucessivos emails juntos aos autos cujas respostas são tendencialmente enviadas no dia do email ou no dia seguinte. Explicou a testemunha que o documento 5 junto com a oposição foi entregue no primeiro sprint e consistia num plano genérico, sendo que o acordado, segundo a testemunha, foi que a ré que se responsabilizou pelos interfaces dos CTT e DHL, mas no decurso do projeto percebeu-se que tinha de ser a autora a fazer, tendo integrado a DPD. Não foram feitas todas as integrações de transportadores por falta de tempo, segundo a testemunha CC.
(…)
- AA (fornecedor do projeto da ré) participou no projeto da ré, e em sede de inquirição referiu que atenta a falta de capacidade técnica da ré para efetuar as aplicações que pretendiam fizeram um caderno de encargos a fim de contratar uma empresa especializada e competente tecnicamente. Foi a testemunha AA o responsável pela elaboração da proposta constante do documento 2 junto com a oposição. Percorrendo o documento 2 junto com a oposição, a testemunha AA referiu que as lojas Pick me nunca foram integradas no produto apresentado pela autora, pelo que só o DPD foi integrado. Da inquirição da testemunha resultou que foi apresentado um “bolo de ideias” (nas suas palavras) com o projeto que pretendiam que fosse feito, sendo que a autora apresentou um período de tempo (conjunto de sprints) no qual executariam as tarefas que tinham sido pedidas, tendo referido que “deixaram abertura” para durante a execução do projeto incluírem ou excluírem funcionalidades ou lojas.
Era nas reuniões ao início de cada sprint, segundo a testemunha, que se definiam as funcionalidades a integrar aquele sprint. De forma espontânea referiu que a proposta da A... correspondia à expectativa do projeto que a ré pretendia alcançar, sendo que o contratado não era específico em todos os pontos. Referiu a testemunha que foram pedidas 2 aplicações de loja e uma aplicação parceiro esta (até então nunca referida) que foi abdicada por não haver mais tempo. O tempo fixado para o cumprimento do projeto apresentado pela ré foi fixado pela autora atendendo ao trabalho a executar e que a autora considerou ser necessário para o executar.
Ao longo da sua inquirição, a testemunha reforçou que durante a execução do projeto houve cedências quanto às funcionalidades e integrações que iam sendo feitas. Para além da Shopify, segundo a testemunha, nenhuma plataforma e-commerce foi integrada, nem foi integrado o sistema de subscrições. Mais uma vez, à semelhança do que fora dito pelo representante legal da ré, mencionou a testemunha que o processo de envio da aplicação entregue nunca chegou ao fim. Explicou a testemunha, à semelhança do que foi dito pelo representante legal da ré, foi GG quem fez os testes das versões que iam sendo enviadas pela autora à ré, sendo que depois dos testes eram pedidas à autora correções.
-Patrícia HH, cônjuge do representante legal da ré, pertence ao grupo que a ré integra e participou na fase final do desenvolvimento do projeto a fim de testar as versões enviadas pela autora. Segundo a testemunha, a sua área de intervenção foi sempre o frontend, e não o programa em si, pelo que reportava diretamente com a autora os problemas que encontrava. Os problemas que encontrou estavam identificados nos documentos 12, 16 e 20 juntos com a oposição, tendo a testemunha se recordado de alguns problemas neles identificados. Segundo a testemunha, não foi apresentada uma versão “aceitável”, isto é, uma versão que, nas suas palavras, conferisse credibilidade ao cliente, pelo que segundo disse não estava a aplicação entregue pela autora pronta para entrar no mercado. Por fim, referiu a testemunha que depois do envio à autora do relatório do documento 20 junto com a oposição, não foi enviada por esta mais nenhuma versão melhorada.
(…)
Foram as partes igualmente unânimes no que respeita ao teor do documento 2 junto com a contestação, elaborado pela aqui testemunha AA: tratava-se de uma apresentação do produto que a ré pretendia (ainda que em traços genéricos e sem concretizações dos vários elementos a elaborar) a fim de permitir que as empresas competentes apresentassem as respetivas propostas, como efetivamente a autora fez (documento 3 junto com a contestação). No entanto, o representante legal da autora, em sede de declarações de parte, referiu que aquando da proposta encontrava-se ainda a faltar a costumer journey, isto é, o a descrição detalhada do que o cliente pretende fazer com determinada funcionalidade.
Quanto à aplicação Moloni, respeitante à emissão de faturas, o representante legal da autora referiu que tal funcionalidade era controlada pela ré e que a faturação estava a funcionar o que foi negado pela testemunha GG. Por sua vez, o representante legal da ré referiu que a ré, que tinha a aplicação Moloni, entregou o API à autora para que aquela integrasse o Moloni no software de faturação que estavam a criar. BB referiu que as API internas foram entregues logo no início do contrato à autora e que a mesma não as integrou no produto final.
A pedra de toque no presente caso é compreender o que foi efetivamente contratado: porquanto segundo a autora, adotando o modelo scrum, ficaram inicialmente definidos os vetores custo e preço, ao passo que segundo a ré o que ficou definido foi o preço e o âmbito.
Porém, o próprio representante legal da ré foi referindo que o âmbito do negócio ia sendo concretizado ao longo do desenvolvimento do projeto. Questionado acerca do que havia sido inicialmente contratado o representante legal da ré disse, num primeiro momento, que foi um produto definido, no entanto admitiu, posteriormente, que o âmbito do negócio seria concretizado à medida que era desenvolvido, tendo em momento posterior referido que tais ajustes, apesar de possíveis e efetivamente realizados, não eram queridos por parte da ré, o que se estranhou atendendo ao modelo adotado.
Os representantes legais de ambas as partes disseram que foram feitos sprints adicionais, o que levanta a questão de saber efetivamente se o que foi acordado foi um período de tempo, ou por sua vez, um produto final. Porque sendo a primeira a solução correta, não se compreende como forneceu a autora, sem contrapartida, mais sprints de 2 semanas.
A testemunha CC reiterou que foi adotado o modelo scrum e que foram fixados os vetores custo e tempo, sendo que diretamente inquirido sobre a contradição perante a realização de mais sprints do que os contratados, referiu a testemunha que se deveu a “boa vontade”.
Ora, da proposta constante do documento 3 junto com a oposição resulta que findo o período piloto, a implementação será considerada como definitivamente aceite, sendo implementadas as alterações solicitadas num prazo máximo adicional de 2 sprints. Quer isto dizer que à ré foram dadas 4 semanas para identificar erros e alterações ao produto apresentado, o que parece justificar que o desenvolvimento do projeto tivesse durado para além das 12 semanas.
Apesar de não ser desconhecido ao tribunal que o nomen iuris dado pelas partes ao contrato celebrado não vincula o tribunal, a verdade é que do contrato celebrado constante do documento 4 junto com a oposição resulta que as partes celebraram um contrato de prestação de serviços de desenvolvimento de software descritos na proposta comercial com as características e horizonte temporal aí indicados.
Em síntese, os factos provados elencados nos pontos 1 a 6, … resultaram do acordo tácito entre as partes, por falta de impugnação dos mesmos (artigo 574.º, do CPC). Para além disso, foram ainda apurados através do teor do contrato celebrado entre as partes e junto aos autos. Daí resulta que o objeto do contrato seria o desenvolvimento de software, sendo que o pagamento faseado do preço final resulta igualmente das faturas emitidas pela autora e juntas aos autos. Na realidade, nunca a ré colocou em causa o não pagamento da última fatura emitida pela autora, referente à última tranche devida pelo serviço prestado, faltando, deste modo, 5.250€ relativos à fatura n.º 165.
O conteúdo do contrato, na adoção do modelo scrum, era definido por sprints. Isto é, se inicialmente foi pedido à autora, de forma parcamente detalhada, o que era pretendido (com indicações genéricas das funcionalidades pretendidas no produto final e descritas no documento 2 junto com a oposição), a verdade é que os serviços a desenvolver e a prestar iam sendo definidos à medida que o contrato ia sendo executado. Isso resultou claro da prova produzida em audiência de julgamento, porquanto todos os intervenientes referiram que quer na apresentação do que era pretendido por parte da ré, como ao longo da execução do contrato foram feitos ajustes nos serviços, operações e funcionalidades que iam sendo realizadas e integradas. Deste modo, conforme foi afirmado pela testemunha AA, pessoa que esteve à frente da apresentação do projeto pretendido, a ré tinha conhecimento que inevitavelmente o modelo apresentado seria o método scrum, um modelo dinâmico para um projeto que foi apelidado igualmente de dinâmico, sabendo a ré ab initio que nem todas as funcionalidades elencadas na fls. 23v. dos autos podiam ou tinham que estar no produto final apresentado. A ré pretendia necessariamente uma aplicação que funcionasse. E se isso não é colocado em momento algum em crise, isto é, que a vontade da ré se traduzia na obtenção de um produto final que funcionasse, que iria para além do produto mínimo viável, a testemunha explicou que eram fixados objetivos parciais, o que dava flexibilidade quanto ao produto final que ia ser entregue. O desenvolvimento das interligações entre as demais funcionalidades pretendidas pela ré ia sendo definido ao longo do contrato.
O método de execução do contrato celebrado foi o cerne da discussão ocorrida nos autos e sobre a qual menos consenso houve. Se é verdade que todos os intervenientes processuais referiram a utilização do modelo scrum, baseado num programa flexível de desenvolvimento de software, foram já díspares as versões sobre a concreta efetivação daquele modelo no caso concreto. Assente em objetivos gerais que a ré pretendia ver definidos e implementados no produto contratado e vertidos no documento 5 junto com a oposição (as denominadas user stories indicadas no facto provado sob o ponto 11), foram duas as versões tendencialmente apresentadas. Como acima vimos, se por um lado, o representante legal da autora e as testemunhas por si arroladas referiram que os serviços informáticos prestados pela autora eram e foram definidos em função do tempo despendido e delineado à partida para o desenvolvimento do produto que a ré pretendia, por outro lado, o representante legal da ré tentou contrariar tal versão, afirmando e reiterando veementemente que o que havia sido contratada a construção de 2 aplicações móveis e um aplicação de backend. No entanto, se por um lado a testemunha AA tentou secundar este entendimento, a verdade é que ao longo do seu depoimento demonstrou que o produto final não foi concretamente fixado, o que se encaixa com o modelo scrum, e que o mesmo ia sendo, por acordo ou necessidade, ajustado durante o decurso do tempo, com a retirada ou inserção de novas funcionalidades (facto provado sob o ponto 41, com resulta evidente, para além do mais, dos documentos junto na audiência realizada a 16.06.2023).
(…)
Os factos sob os pontos … 17 foram julgados como provados em virtude de análise dos elementos documentais juntos autos, nomeadamente o documento 7 e bem ainda das declarações de parte dos representantes legais das partes, …. Tendo ainda sido mencionada por aqueles a proposta de adiamento do projeto fundada no atraso do desenvolvimento do projeto por falta de definição da lógica de negócio, assim como a sua não aceitação.
O facto vertido no ponto 18 resultou provado pelo confronto com as notas das reuniões entregues na audiência de julgamento realizada a 16.06.2023, sendo que os representantes legais referiram igualmente o prolongamento do desenvolvimento da aplicação em virtude das dificuldades sentidas (ainda que a “culpa” desses atrasos tenha criado divergência).
(…)
No que concerne à matéria vertida nos pontos 6.º a 8.º da oposição, importa em primeiro lugar sanar aquele que parece ser um evidente lapso de escrita da oposição, porquanto na oposição apresentada consta que foi a autora quem procurou no mercado empresas especializadas na criação e desenvolvimento de software. Essa procura no mercado, como foi explanado pela testemunha AA, foi realizada por parte da ré, B..., que contactou com três empresas que conheciam a área de intervenção da E... e que tinham competências para “interpretar as necessidades e juntar as valências” pretendidas pela B... no projeto C.... Segundo a testemunha AA, à data do período negocial em causa, era gerente da sociedade ré tendo por esse motivo conhecimento do iter negocial. Segundo o mesmo foram por si recebidas duas propostas: a da A..., aqui autora, e a da empresa F... (facto provado sob o ponto 9). Ora, se o tribunal, do depoimento da testemunha, ficou convencido que a ré procurou junto do mercado quem pudesse realizar o projeto que pretendiam, o tribunal desconhece quais as demais empresas contactadas, desconhecendo ainda a sua especialização (facto não provado sob a alínea a. e facto provado sob o ponto 7).
Quanto à informação prestada pela ré à autora em momento prévio à celebração do contrato, com o objetivo de a ré obter para si propostas contratuais a fim de celebrar o contrato, conforme resultou amplamente discutido nas sessões de julgamento realizadas, o objetivo pretendido pela ré encontrava respaldo na apresentação constante do documento 2 junto com a oposição. Ora, foi este o documento que serviu de base à proposta apresentada pela A..., para a qual, na realidade a A... remete em determinados pontos no documento 3 junto com a oposição. A apresentação do “produto” pretendido pela ré foi realizada pela testemunha AA, com base no documento 2 junto com a oposição. E é deste documento que se retira o “modelo de negócio a implementar e bem assim os requisitos tecnológicos que pretendia que fossem desenvolvidos”. Como referiu a testemunha AA na sua primeira inquirição, foi apresentado à autora um “bolo de ideias” constante naquela apresentação. Foi o mesmo que havia sido dito pelo representante legal da autora que referiu que o que fora encomendado foi o software para e-commerce com funcionalidades de entrega de serviços e interação com clientes, sendo que o produto final iria ser definido a cada sprint.
Ora, resultou comprovado da conjugação da prova documental com a prova testemunhal, mormente da testemunha AA, que foi explicado à autora o que se pretendia: a interligação das funcionalidades previstas na fls. 23v. dos autos (orçamento, lojas pick me, plano de subscrição, tracking, integrações com parceiros, CRM particulares, CRM lojas, integração marketing digital, integrações com lojas, faturação, modelos de pagamento, my C..., app gestão de loja, app particular e app parceiro), num modelo de negócio dirigido tendencialmente aos consumidores, totalmente informatizado e sem personalização – facto provado sob o ponto 8.
Como explicou também a testemunha AA, as diferentes cores constantes do diapositivo de fls. 23v. dos autos têm diferentes significados: as funcionalidades a vermelho eram urgentes e obrigatórias, as brancas, apesar de serem importantes não eram prioritárias e podiam não ser desenvolvidas logo, mas sim ao longo do tempo e a funcionalidade a verde (a faturação) tinha ainda de ser trabalhada em conjunto, estando à data da apresentação do que a B... pretendia ainda indefinida quanto à sua contratação. Ou seja, retira-se da prova produzida e da explicação detalhada da testemunha AA, que esteve encarregue da apresentação do produto pretendido, que não existia definido e delimitado qual o produto final que a ré pretendia comprar, mas sim foi apresentado um conjunto de funcionalidades, suscetíveis de serem, ao longo do tempo, excluídas ou alteradas cuja integração se pretendia, sendo que não existia completamente definido o que deveria ser entregue, tal ia sendo definido em conjunto.
Assim, antes da apresentação da proposta por parte da autora, o que foi apresentado foram os elementos negociais constantes do documento 2 junto com a oposição, sendo a tais elementos a que se reporta o facto provado sob o ponto 8. No entanto, é apodítica a latitude de tal apresentação, sendo ambígua e deixando claramente abertura para ser definida pela ré.”.
2.1. Relativamente à alteração da redacção do facto provado 2., como defendido pela recorrente, temos por boa a sua sugestão, independentemente dos depoimentos das testemunhas CC e AA, convocadas pela recorrida nas suas contra-alegações de recurso, atendendo ao que consta conjugadamente do teor do Ponto 1. do contrato de prestação de serviços celebrado por escrito entre as partes (Doc. 4 junto com a oposição, a fls. 41 v./52 v.) que remete para os serviços de desenvolvimento de software descritos na proposta comercial (Doc. 3 junto com a oposição, a fls. 32/41).
Importa, pois, fazer reflectir tal alteração no aludido facto 2. (a negrito, ficando a anterior redacção em letra minúscula), que assim ficará redigido:
2. No âmbito da sua atividade comercial, as partes celebraram, em 20.09.2019, um acordo escrito através do qual a autora obrigou-se a prestar serviços de desenvolvimento do software denominado C... e a fornecê-lo a ré, nos termos enunciados na Proposta Comercial junta como Documento 4 da oposição, e a ré obrigou-se a pagar à autora o preço total de €52.500 em prestações mensais, da seguinte forma:
- a.Na data de celebração do presente contrato: 21.000,00€ + IVA;
- b.A 27/09/2019: 5.250,00€ + IVA;
- c.A 28/10/2019: 5.250,00€ + IVA:
- d.A 28/11/2019: 5.250,00€ + IVA;
- e.A 27/12/2019: 5.250,00€ + IVA;
- f.A 28/01/2020: 5.250,00€ + IVA;
- g.Após aceitação final pelo Cliente: 5.250,00€ + IVA.
2.2. Respeitante aos aditamentos ao facto provado 2., como propostos pela apelante, também os temos por pertinentes, independentemente das declarações de parte de DD, invocadas pela apelante nas suas alegações de recurso, atendendo ao que consta do teor da referida proposta comercial seu Ponto 2., que está anexa ao mencionado contrato de prestação de serviços celebrado entre as partes.
Importa, assim, adicionar tal matéria aos factos provados, sob 2-A. (a negrito), nos seguintes termos:
2-A. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a integrar, através de interfaces de programação de aplicações (API’s - Application Programming Interface), com os sistemas da E... então em utilização, encapsulando toda a lógica de negócio do C..., incluindo ligação a gateways de pagamento, mecanismo de notificações, etc.;
2-B. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a facilitar a integração do C... em lojas online através de kits de desenvolvimento de software (SDK - Software Development Kit);
2-C. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a integrar com plataformas de eCommerce de terceiros, a selecionar de acordo com as prioridades definidas pelo Cliente;
2-D. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a integrar aplicações para acompanhamento de encomendas e gestão de processos dos utilizadores;
2-E. A autora obrigou-se ao desenvolvimento e fornecimento do referido software com o objetivo de assegurar que os utilizadores dos diversos canais de eCommerce possam solicitar e gerir os seus envios, efetuar pagamentos, acompanhar envios em trânsito, entre outros que venham a ser identificados e que se enquadrem no âmbito descrito;
2-F. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a assegurar funcionalidades direcionadas para os integradores, de modo a que possam de forma simples subscrever os serviços da E... e disponibilizá-los aos seus clientes;
2-G. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a assegurar, de forma autónoma o pedido de cotação, suportado pelo sistema ORCA, a confirmação de serviço, a gestão do envio, suportado pelo sistema GESREC, o tracking e a facturação;
2-H. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a receber pagamentos através dos sistemas MB MULTIBANCO, MB WAY, PAYPAL, MASTERCARD, VISA e BITCOIN;
2-I. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a suportar, desde a sua fase inicial (e sem prejuízo de posterior evolução ao longo do tempo de modo a suportar um número crescente de plataformas de eComerce de destino), bibliotecas, plug-ins ou extensões para suportar as seguintes integrações Websites HTML/CSS/JavaScript, Shopify, WooCommerce / WordPress / Magento;
2-J. A autora obrigou-se ao desenvolvimento e fornecimento do referido software por forma a seja possível aos integradores optar entre três cenários distintos:
1.º - Utilização simples do serviço de transporte C..., cobrando ao cliente e entregando à E... os custos de transporte;
2.º - Delegação no C... não só do serviço de transporte, mas também da cobrança, recebendo posteriormente o valor dos artigos vendidos em si;
3.º - Delegação completa no C... de todo o “carrinho de compras”, ficando a E... encarregue do levantamento, transporte, recolha e cobrança dos artigos comercializados;
2-K. A autora obrigou-se ainda, no contexto do desenvolvimento e fornecimento do referido software, a desenvolver uma aplicação web para disponibilizar todas as funcionalidades implementadas pelo “backend”, e que incluiria todas as gateways de pagamento e integrações atrás descritas, garantindo consistência da linguagem gráfica em dispositivos desktop ou mobile.
2-L. Para implementação dos requisitos gerais enunciados, a autora obrigou-se a alocar todos os recursos necessários, incluindo programadores, QA e testes, acompanhamento de um Arquiteto de Software, DevOps e a infraestrutura necessária ao ambiente de testes.
2.3. Quanto aos factos provados 7. e 8. cuja redacção a recorrente propõe, retirando-se a a) dos factos não provados, essa matéria reporta-se à alegação facual produzida nos art. 6º e 7º da oposição, a saber:
- “6.No decorrer desse ano de 2019, a Autora procurou no mercado empresas especializadas na criação e desenvolvimento de um “software à medida” que procedesse à automatização do processo do negócio de transporte de mercadorias no contexto do comércio electrónico online desde o pedido do cliente até à entrega e envio da factura – Projeto C....
- 7.Para tanto, forneceu às empresas então contactadas – entre elas a Autora – informação sobre o modelo de negócio a implementar e bem assim os requisitos tecnológicos que pretendia fossem desenvolvidos – Doc. 2, cujo conteúdo aqui se dá por integralmente reproduzido para todos os legais efeitos.”.
O indicado Doc. 2 (junto com a oposição, a fls. 14 v/31) corresponde ao modelo de negócio a implementar bem como os requisitos tecnológicos que a apelante pretendia que fossem implementados. Este modelo foi confirmado nas declarações de parte da recorrente pelo seu sócio-gerente, engenheiro informático BB (na sessão gravada da audiência de julgamento de 1.6.2023).
AA, ex sócio-gerente da recorrente, e mentor do projecto, explicou isso mesmo, que foi ele o autor do projecto tendo contactado empresas para os efeitos pretendidos, designadamente a autora e outra, a F... (na sessão gravada de 30.6.2023), e que reconfirmou explicitamente (na sessão gravada de 11.3.2024), nos seguintes termos, que a recorrente transcreveu e cuja transcrição aproveitamos:
“[00:06:38] Mandatário da Ré: Pronto. E aqui quando diz que procuraram no mercado soluções tecnológicas para isso, está a falar de quê? De um problema informático, de um...?
[00:06:45] AA: Não, nós sabíamos que não havia um programa que nós fossemos ao mercado comprar e utilizar, sabia que não existiam, mas sabíamos que muitas das possibilidades que nós queríamos, elas já existiam no mercado. [impercetível] já existia mercado, situações de gestão de modelos de pagamento, modelos de subscrição, [impercetível] informática [impercetível], portanto, todas estas pequenas ferramentas já existiam no mercado uma parte delas, as próprias lojas de distribuição, a gestão de loja, a chamada [impercetível], todo esse tipo de coisas já existia. Agora, juntar isto tudo e criar um programa que juntasse isto tudo, nós sabíamos que não existia, nós queríamos ser os primeiros a ter esse programa, desenvolver o programa, sabíamos que imediatamente todo o investimento [impercetível] e ficar [impercetível] este trabalho.
[00:07:41] Mandatário da Ré: Para fornecer-vos esse programa?
[00:07:44] AA: E fornecer-nos este programa.
(…)»
[00:07:53] Meritíssima Juiz: Consegue o Documento 2 da Oposição, [impercetível]. Diga-me só uma coisa: a Oposição faz menção a uma expressão e eu quero perceber essa expressão que é “à procura de software à medida”. Este software à medida então é as empresas que têm estas várias funcionalidades serem eles a juntar o próprio programa, é isso? Era isso que vocês queriam?
[00:08:22] AA: Não. As empresas [impercetível].
[00:08:27] Meritíssima Juiz: OK, as pessoas a quem vocês pediram propostas?
[00:08:29] AA: Sim, nós pedimos propostas a 3 empresas, acho eu, 3 empresas e nós já fomos criteriosos porque há empresas que achávamos que já conheciam a nossa loja, já conheciam o nosso modelo de negócio, já não fomos ao mercado de forma aberta, já fomos de uma forma mais ou menos selecionada. E aquilo que nós queríamos era que esses parceiros [impercetível] estas nossas necessidades e construíssem uma solução que juntasse todas estas valências.
[00:09:03] Meritíssima Juiz: Ou seja, o que queriam é que eles criassem um produto especificamente para as vossas necessidades, é isso?
[00:09:08] AA: Sim, sim Meritíssima Juiz.
(…)»
Como a recorrente realça, acertadamente, aqui, com clareza, a testemunha explica que o programa informático que a recorrente pretendia não existia no mercado em formato standard. Teria de ser desenvolvido, de forma personalizada, à medida da pretensão da recorrente, por forma a juntar ferramentas informáticas já existentes no mercado num único produto, precisamente o programa informático pretendido pela recorrente.
De modo que a impugnação à decisão de facto deduzida pela apelante deve ser deferida e consequentemente alterada a redacção dos factos provados 7. e 8., nos termos propostos pela mesma, e eliminada a a) dos factos não provados (ficando em letra minúscula e a nova redacção a negrito), como segue:
- 7.Em 2019, a ré procurou no mercado empresas especializadas na criação e desenvolvimento de “um software à medida” que procedessem à automatização do processo do negócio de transporte de mercadorias no contexto do comércio eletrónico online desde o pedido do cliente até à entrega e envio da fatura – Projeto C....
- 8.Nessa procura, a ré forneceu às empreses então contactadas – entre elas a autora - informação sobre o modelo de negócio a implementar e bem assim os requisitos tecnológicos/funcionalidades que pretendia que fossem desenvolvidos, sob a denominação C....
2.4. Relativamente à pretendida fusão/modificação/eliminação atinente aos factos provados 17. e 18., verificamos que o ano apontado no facto 17. está errado, bem como a menção às partes, que está trocada, por lapso do tribunal a quo, levando em consideração o que a recorrente alegou nos arts. 25. a 33. da sua oposição, erro e troca que não merecem da recorrida, nas suas contra-alegações, qualquer discordância. Desta sorte, há que fazer a devida correcção (a negrito, ficando a anterior redacção em letra minúscula). Eliminar tal facto como a recorrente pretende é que não se vê motivo justificado para isso. Consequentemente o facto 18. permanecerá como está.
Aquele facto 17. ficará, pois, como segue:
- 17.A autora, em novembro de 2019, alegou que a ré não tinha facultado à autora toda a documentação necessária sobre as interligações.
- 3.Na sentença recorrida escreveu-se que:
“Nos presentes autos, a autora peticiona a condenação da ré no pagamento de 6457,50€ a título de responsabilidade civil contratual pelo não cumprimento, por parte da ré, da obrigação de pagamento do preço a que se encontrava adstrita em virtude do contrato de prestação de serviços de desenvolvimento de software celebrado.
Em sede de oposição, a ré invocou a exceção de não cumprimento e de cumprimento defeituoso para justificar o não pagamento da última tranche. Por sua vez, retorquiu a autora que o contrato celebrado consistiu na definição de um período de tempo no decurso do qual a autora disponibilizaria os seus serviços de desenvolvimento de software consoante as necessidades da ré.
Independentemente do nomen iuris que as partes dão aos contratos, na interpretação e na qualificação destes, o que releva na definição do mesmo é a vontade expressa nas respetivas declarações negociais, entendidas estas com o sentido captável pelo declaratário normal, colocado no real circunstancialismo negocial. Assim, o tribunal não se encontra adstrito à qualificação jurídica que as partes atribuem ao acordo entre si celebrado, devendo qualificar o contrato de acordo com a “interpretação da atividade negocial das partes, tendo por elementos de trabalho o texto contratual, as negociações que o antecederam e a vivência da relação negocial estabelecida” (cfr. Acórdão do TRC de 7/2/2006, relator: Cura Mariano, disponível em <dgsi.pt>).
Importa, portanto, perceber qual o contrato celebrado entre as partes e quais as obrigações a que se vincularam.
Em primeiro lugar, suscita-se a questão de saber se o acordo celebrado entre as partes consubstancia um contrato de empreitada.
O contrato de empreitada, definido no artigo 1207.º, do CC, implica que uma das partes se obrigue a realizar uma obra, obra essa que se deve materializar numa coisa concreta com utilidade própria para o seu beneficiário e que seja alcançado em conformidade com um projeto (PRATA, Ana, Código Civil anotado, vol. I, p. 1546).
Tem sido amplamente discutida a possibilidade de aplicar o regime do contrato de empreitada a obras intelectuais e incorpóreas como a que se encontra em discussão. O principal argumento contra esta possibilidade centra-se na não transferência típica da propriedade dos direitos de autor ou propriedade intelectual, ficando o empreiteiro com a propriedade dos mesmos. No caso em concreto, apesar de o contrato celebrado entre as partes prever a transferência da propriedade intelectual que tenha sido desenvolvida exclusivamente para a ré, a verdade é que a propriedade intelectual neste caso se encontra abrangida pelo Código de Direitos de Autor e dos Direitos Conexos que prevê como regra supletiva no seu artigo 14.º que o direito de autor pertence ao prestador de serviços, não se podendo falar com total retidão, nestes casos, em contrato de empreitada, mas antes um contrato de prestação de serviços, no qual se poderão aplicar algumas das regras aplicáveis ao contrato de empreitada. Do contrato junto aos autos resulta que a propriedade intelectual antes pertencente à autora se mantém na propriedade daquela, o que afasta a definição do contrato celebrado enquanto contrato de empreitada.
O conceito restrito de obra não permite incluir no âmbito da celebração de um contrato de empreitada criações intelectuais que, apesar do suporte material no qual se encontram exaradas, assumem um carácter incorpóreo, como é o caso do software (MARIANO, João Cura, Responsabilidade Contratual do Empreiteiro pelos Defeitos da Obra, 7.ª edição, Almedina, p. 47).
Neste sentido, afirma Luís Menezes Leitão que, onde se salienta: “A posição que nos parece preferível é a de que a obra intelectual não pode ser objecto de contrato de empreitada, que se restringe às coisa corpóreas, (…). Efectivamente, a noção de obra constante do artigo 1207º do Código Civil, ao contrário do que normalmente acontece nos Códigos Civis estrangeiros, é restringida às coisas corpóreas, dado que o regime de fiscalização (artigo 1209º), da transferência da propriedade (artigo 1212º), das alterações (artigos 1214º e seguintes) e dos defeitos da obra (artigo 1218º e seguintes), é dificilmente compatível com a criação de obras intelectuais, uma vez que nestas tem que ser assegurada uma maior liberdade ao criador e a questão principal prende-se com a atribuição do direito de autor sobre a obra, questão que o regime da empreitada não resolve. Por último, se viesse a abranger as obras intelectuais, o contrato de empreitada passaria a ser uma figura demasiado ampla, esgotando quase completamente o regime da prestação de serviços” (in Direito das Obrigações, vol. III, Almedina, 7.ª edição, p. 518 e ss. No mesmo sentido, vide LIMA, Pires de, VARELA, Antunes, Código Civil Anotado, vol. II, Coimbra Editora, 1986, 3.ª edição, p. 787 e ss.
(…)
Resulta claro da factualidade provada que a autora se vinculou a executar o contrato celebrado de acordo com as regras da arte e regras técnicas com a diligência média de um bom pai de família. As partes estavam vinculadas aos deveres da boa fé e de colaboração, deveres esses que pautaram a relação negocial das partes.
A qualificação jurídica atribuída pelas partes ao contrato celebrado identifica-se com um contrato de prestação de serviços, definido como aquele em que uma das partes se obriga a proporcionar à outra certo resultado do seu trabalho intelectual ou manual, com ou sem retribuição (artigo 1154.º, do CC).
Como modalidades típicas da prestação de serviços prevê-se na lei mandato, o depósito e a empreitada que não esgotam, todavia, as modalidades de prestação de serviços (artigo 1155.º, do CC), como, de resto, esclarece Luís Manuel Teles de Menezes, (in Direito das Obrigações, vol. III, 10ª edição, p. 383) estas três modalidades não esgotam o conteúdo da prestação da prestação de serviços, que constitui uma figura muito ampla. Precisamente por esse motivo, o artigo 1156.º, do CC vem determinar a extensão das disposições sobre o mandato, com as devidas adaptações, aos contratos de prestação de serviços que a lei não regule expressamente. Há assim que reconhecer que o contrato de prestação de serviços é um contrato atípico, que possui três modalidades típicas, as quais estão longe de esgotar o seu campo de aplicação.
Da factualidade julgada como provada resulta que a autora se obrigou a desenvolver software pelo período fixado, em contrapartida da obrigação da ré de pagar o preço. Tal contrato reveste a natureza jurídica de um contrato de prestação de serviços atípico e inominado, sujeito às regras constantes dos artigos 1156.º, do CC, mas a que se poderão eventualmente aplicar por analogia o regime do contrato de empreitada, sempre que tal analogia se justificar.
No âmbito deste contrato, ficou provado que cabia à autora elaborar software aplicacional, no sentido de serem disponibilizadas aplicações à medida das necessidades da ré. Resultou, contudo, igualmente comprovado que a ré não forneceu todas as especificações de negócio necessárias ao desenvolvimento e manutenção da aplicação, tendo apresentado ab initio uma proposta genérica e vaga, que ia sendo concretizada e ajustada com o decurso do tempo. Não existia, deste modo, um produto final especificamente definido aquando da efetuação do convite para contratar, mas tão-só uma ideia genérica das aplicações pretendidas e das funcionalidades que a ré pretendia, sem, contudo, concretizá-las na íntegra e sem que as mesmas fossem todas vinculativas.
No decurso da execução do contrato, atendendo às necessidades específicas da ré e ao resultado de cada reunião de início de sprint, a autora elaborou uma aplicação Android com determinadas características técnicas e qualidades funcionais, cuja utilização cedeu à ré, tendo reservado para si a propriedade desse programa na parte que não fora desenvolvido propositadamente para o sistema aplicacional solicitado pela ré.
Estamos, assim, perante um contrato de desenvolvimento de software «à medida» - Acórdão do TRL 08.09.2015, relatado por Maria do Rosário Morgado, disponível em <dgsi.pt>.
No nosso ordenamento jurídico, a qualificação jurídica de contratos de desenvolvimento de software é alvo de divergência na doutrina e a jurisprudência, sendo considerado por uns como contrato de empreitada, enquanto outros entendem tratar-se de um contrato inominado de prestação de serviços. Como acima se menciona e fundamenta, o contrato dos autos é de qualificar como contrato de prestação de serviços atípico ou inominado, qualificação jurídica que nem sequer é objeto de controvérsia entre as partes.
Chegados aqui, resta referir, de forma sumária, que a pedra de toque do presente aresto reside no facto de saber se a autora se vinculou a fornecer à ré determinados meios para realizar os seus objetivos, ou se encontrava adstrita a produzir certo resultado.
A doutrina debruçou-se já sobre esta distinção, sendo que alguns Autores distinguem as obrigações de meios como aquelas “que respeitam a prestações destinadas a resultados com carácter aleatório, e de resultado aquelas cujo efeito não apresenta tal característica” (veja-se SILVA, Manuel Gomes da, O dever de prestar e o dever de indemnizar, vol. I, Imprensa FDUL, p. 237). Na obrigação de resultado para além do dever de prestar, existe uma garantia de resultado. Em suma e sem pretensões de exaustão, nas obrigações de meios o devedor compromete-se a desenvolver prudente e diligentemente certa atividade para a obtenção de determinado efeitos, mas sem assegurar que o mesmo se produza, enquanto nas obrigações de resulta o devedor compromete-se a conseguir com a sua atividade um determinado efeito útil (MARIANO, João Cura, Responsabilidade Contratual do Empreiteiro pelos Defeitos da Obra, 7.ª edição, Almedina, p. 44).
Deste modo, e no que tange ao incumprimento, nas obrigações de meios não é suficiente a não verificação do resultado para responsabilizar o devedor, havendo que demonstrar que a sua conduta não correspondeu à diligência a que se tinha vinculado. Cabe ao devedor o ónus de provar de que realizou a prestação (artigo 342.º, n.º 2, do CC) ou de que a falta de cumprimento não procede de culpa sua (artigo 799.º, do CC) a fim de não lhe ser imputada uma obrigação de indemnizar.
Se é verdade que o contrato celebrado entre as partes teve um objetivo muito específico, que consistia na criação de aplicações móveis que permitissem a utilização profissional por parte da ré, sendo tal conhecido da autora, no entanto, a convicção do tribunal é que aquilo a que a ré verdadeiramente se comprometeu foi a desenvolver durante um determinado e acordado período de tempo o software necessário à criação das aplicações pretendidas com as funcionalidades que foram sendo concretizadas, a fim de a autora retirar da criação intelectual da autora toda a sua utilidade.
Importa referir que apesar de constar dos pontos 7 a 9 dos factos provados que a ré instou junto da autora para que esta apresentasse uma proposta de desenvolvimento de software que servisse as pretensões da ré, isto é que permitisse uma plataforma dirigida a consumidores com vista ao transporte de mercadorias, a proposta apresentada pela A... foi ela também vaga e genérica tal como a apresentação constante do documento 2 junto com a oposição. Em momento algum, na fase pré-contratual, por parte da ré, foi indicado especificadamente o produto final que se pretendia. Se é certo que a ré pretendia um produto final funcional, com determinadas funcionalidades, essas funcionalidades e interligações foram definidas ao longo do projeto, no decorrer dos sprints e através da dinâmica usual da criação de software através do modelo scrum. Como a própria testemunha AA terminou por concluir, “o todo não estava definido”, por isso não podia existir, em primeiro lugar, uma proposta da autora concreta com todos os serviços concretos a prestar, nem tão-pouco um produto rígido, definido e detalhado que a autora tivesse que entregar. A ré contratou a autora para prestar os mencionados serviços de desenvolvimento de software consistentes na interligação das funcionalidades já existentes no mercado, que iam sendo definidos entre as partes, necessitando para tal o tempo estipulado.
Neste sentido, diga-se ainda, que as duas aplicações iniciais e a aplicação de gestão discutidas nos autos e referidas pelo representante legal da autora não encontram respaldo nem na apresentação que serviu de suporte à apresentação do que era pretendido pela ré, nem na proposta contratual apresentada pela autora, o que é demonstrativo do que acima se afirma quando ao objeto negocial em causa.
Resultou da prova dos autos que não ficou definido um resultado final operativo específico e concretizável logo ao início, mas sim que durante um período de tempo a autora tudo iria fazer a com vista a conceber uma plataforma informática tendente a obter determinados resultados (que poderiam ser alcançados ou não, como não foram alguns por mútuo acordo das partes).
A prestação que satisfaria o interesse contratual da ré dirigia-se à atividade técnica a desenvolver pela sociedade autora, não tendo sido fixado um resultado final operativo detalhado e concretizado, mas sim uma ideia genérica, pelo que não pode a obrigação da autora deixar de consubstanciar uma obrigação de meios.
In casu, se é verdade que teste após teste, se verificaram invariavelmente falhas bloqueantes na aplicação Android entregue pela autora que impediam que a Ré não era afinal capaz de levar a um sistema informático minimamente idóneo à concretização do fim contratual firmado, não se produzindo o “resultado” almejado pela ré, não podemos deixar de afirmar que o contrato de prestação dos serviços de desenvolvimento de software foi cumprido, porquanto a autora com diligência e ultrapassando até o período contratualmente fixado para a prestação dos serviços.
Conforme refere Antunes Varela: “O cumprimento da obrigação é a realização voluntária da prestação debitória. É a actuação da relação obrigacional, no que toca ao dever de prestar. (...) Na obrigação de resultado, o cumprimento envolve já a produção do efeito a que tende a prestação ou do seu sucedâneo, havendo assim perfeita consciência entre a realização da prestação debitória e a plena satisfação do interesse do credor” (in Código Civil Anotado, Volume II, Almedina 1990, 4.ª edição, p. 7 e ss).
Resultou assim comprovado que a autora cumpriu diligentemente a prestação a que estava adstrita: isto é, não obstante ter resultado comprovado que a aplicação criada pela autora apresentava problemas que a tornavam inapta a ser utilizada pelos clientes da ré, como pretendia a ré, a verdade é que tal não constitui, na ótica do tribunal, incumprimento ou cumprimento defeituoso do contrato, uma vez que a obrigação a que se vinculou a autora foi uma obrigação de meios. Desta forma, cumprida que está a obrigação que vinculava a autora de disponibilizar períodos de tempo (em sprints) para desenvolver software, aplicações e funcionalidades que iam sendo requisitadas, definidas e ajustadas em colaboração entre as partes, resultou igualmente comprovado que a ré não procedeu à sua contraprestação, que consistia no pagamento do preço acordado.
Não colhe, de igual forma, a exceção de não cumprimento do contrato prevista no artigo 428.º, do CC, uma vez que, tratando-se de um contrato sinalagmático verificou-se que a autora cumpriu a sua obrigação, tendo a ré sido interpelada para proceder ao pagamento da última tranche do preço.”.
A recorrente discorda pelas razões constantes das suas conclusões de recurso (as 23. a 33.), enquanto a recorrida pugna pela justeza da posição jurídica expressa na decisão apelada (cfr. conclusões das suas contra-alegações N. a T.).
Á priori, conexionado com o facto provado 2. importava saber se a recorrente não comprou tempo à recorrida, como esta defende, se antes comprou um produto – um programa informático, o qual nunca lhe chegou a ser entregue com os requisitos mínimos para ser lançado ao mercado como aplicação informática, como defende ao invés a recorrente. E se, independentemente da qualificação jurídica a atribuir ao contrato – empreitada ou contrato inominado de prestação de serviços – sempre esteve no propósito das partes a entrega de um produto final. A saber, uma aplicação informática que procedesse à automatização do processo do negócio de transporte de mercadorias no contexto do comércio electrónico online desde o pedido do cliente até à entrega e envio da factura – Projeto C... (facto provado 7.). Perante este último facto era muito duvidoso aceitar a tese da recorrida, de mera compra de tempo, pois se a aplicação informática a criar visava a automatização do processo de negócio de transporte de mercadorias no contexto do comércio electrónico online desde o pedido do cliente até à entrega e envio da factura, o mais crível, obviamente, era que se pretendia alcançar um resultado, não uma mera actividade, pois nas obrigações de resultado o devedor compromete-se a conseguir com a sua atividade um determinado efeito útil, e era justamente esse efeito útil o que a recorrente pretendia.
Perante os factos agora comprovados – os 2., 2-A. a 2-L., 7., sobretudo este, e 8. -, não temos dúvidas em afirmar que a recorrente visou e contratou com a recorrida um determinado resultado, um produto informático determinado.
No caso, “um software à medida” da pretensão e necessidades da apelante – sobre esta figura pode ver-se Alexandre L. Dias Pereira, Direitos de Autor e Liberdade de Informação, Teses, 2008, págs. 206/211, que refere que em termos de enquadramento jurídico, a licença de software feito à medida obtém-se no quadro de um contrato de encomenda de obra intelectual. E que no direito português, a questão da qualificação jurídica de contratos de software “feito à medida” (ou adaptado) dividiu a doutrina e a jurisprudência, com vários autores a considerarem estarmos perante um contrato de empreitada, enquanto outros entendiam tratar-se de um contrato inominado de prestação de serviços.
Ora, atenta a referida factualidade provada, o contrato dos autos é de qualificar como contrato de prestação de serviços atípico ou inominado, um contrato de desenvolvimento de software «à medida», e não uma empreitada, como a 1ª instância qualificou e bem fundamentou, merecendo, por isso, a nossa adesão.
Acontece que a apelada não logrou conseguir inteiramente tal desiderato, como decorre dos factos provados 24. a 26., 28. a 37. O que quer dizer que a prestação da A. não foi a devida, na óptica da boa fé, pontualidade e integralidade do cumprimento.
Estamos, pois, perante um cumprimento defeituoso, que se traduz na execução de prestações qualitativas e quantitativas diversas das estipuladas (ou na inobservância de deveres laterais). Trata-se de um cumprimento imperfeito, com vícios materiais ou jurídicos, com prestação de menor qualidade ou quantidade superior ou inferior, imprópria para o fim desejado (vide A. Menezes Cordeiro, Tratado, D. Obrigações, Tomo IV, 2010, págs. 200/201, e J. C. Brandão Proença, Lições de Cumprimento e Não Cumprimento das Obrigações, 1ª Ed., 2011, págs. 354/359).
Perante tal situação, a primeira e mais natural atitude do credor será de recusar a prestação defeituosa e de esperar/reclamar por um cumprimento regular, sustendo, com a excepção do cumprimento defeituoso, o cumprimento da sua contraprestação.
A apelante fez acionar a excepção de não cumprimento do contrato (art. 428º, nº 1, do CC), pois a A. só podia reclamar o pagamento da última prestação (facto 2.g.), após a aceitação final pelo cliente, a R./recorrente. Ora, não está demonstrado nos autos essa aceitação final pela R./recorrente.
A excepção do contrato não cumprido deve ser sempre usada nos limites da boa fé (vide Menezes Cordeiro, ob. cit., pág. 141). E vale tanto para o caso de falta integral do cumprimento, como para o cumprimento parcial ou defeituoso, desde que a sua invocação não contrarie o princípio geral da boa fé (vide A. Varela, CC Anotado, Vol. I, 3ª Ed., nota 3. ao art. 428º, pág. 381). Trata-se de uma excepção material dilatória que invocada com sucesso, como no nosso caso concreto, leva a que o contrato entre numa suspensão de eficácia até que se processe o cumprimento, ou eventualmente, seja resolvido com base na definitividade/impossibilidade do cumprimento. Podendo ser invocada fora da simultaneidade temporal, pelo contraente que deva cumprir em segundo lugar, como no nosso caso, por ex: o serviço deve estar concluído antes do seu pagamento. E pressupondo a sua invocação a existência de um incumprimento minimamente grave, mas não ínfimo ou insignificante. E nos cumprimentos parciais ou defeituosos a ser invocada proporcionalmente à quantidade/qualidade do incumprimento (vide J. C. Brandão Proença, ob. cit., págs. 143/151).
Concluindo. Na nossa situação, perante a factualidade apurada, o recorrente invocou a exceptio nos limites da boa fé, num caso de cumprimento defeituoso, como contraente que devia cumprir em segundo lugar, perante a existência de um incumprimento da recorrida não ínfimo ou insignificante que invoca proporcionalmente face à qualidade do incumprimento, podendo, por isso, recusar a última parcela do pagamento, correspondente a 10% do preço (a recorrida recorda na sua conclusão de recurso R o Ac. desta Rel. de 21.2.2018, mas o mesmo incide sobre um contrato de empreitada e o seu regime jurídico concreto diversamente da situação em apreço nos autos incidente sobre um contrato de prestação de serviços).
Procede, pois, a apelação.
(…)
