Acordo de Manutenção de Software

Em linguagem simples: Identifica o provedor de serviços (desenvolvedora/empresa de software) e o cliente (empresa que recebe manutenção), incluindo estado de constituição e endereço.

Erro comum: Omitir informações de constituição legal ou fornecer endereços incompletos, dificultando notificações futuras.

Em linguagem simples: Define qual software específico é objeto de manutenção, normalmente descrito no Anexo B, vinculando-o a um contrato de licença anterior.

Erro comum: Ser vago sobre qual versão ou módulo do software está coberto, levando a disputas sobre escopo de suporte.

Em linguagem simples: Estabelece quando o contrato começa e por quanto tempo dura, definindo quando as taxas se tornam exigíveis (primeiro ciclo de faturamento após assinatura do cliente).

Erro comum: Confundir a data de assinatura com a data de início do contrato, causando conflitos sobre quando as obrigações começam.

Em linguagem simples: Permite que qualquer parte rescinda o contrato após enviar notificação por escrito com antecedência (p.ex., 30 dias), e estabelece indenizações se o cliente rescindir antes do prazo inicial.

Erro comum: Não especificar o período de aviso prévio ou deixar vago o montante da indenização, criando disputas na rescisão.

Em linguagem simples: Define uma taxa horária ou diária fixa pelo trabalho de manutenção, com pagamento devido dentro de um prazo (p.ex., 30 dias) após faturamento, opcionalmente com limite de responsabilidade máxima.

Erro comum: Não especificar a unidade de tempo (hora, dia, semana) ou deixar em aberto como se calcula o tempo despendido.

Em linguagem simples: Define um preço total do contrato, pagável em parcelas conforme plano aprovado (p.ex., valor inicial na assinatura, saldo após aprovação do plano de manutenção, resto em cronograma).

Erro comum: Deixar a estrutura de pagamento em aberto ou não vincular pagamentos a marcos claramente definidos (assinatura, aprovação, entrega).

Em linguagem simples: Descreve como o cliente relata problemas (número de telefone do Centro de Apoio), horários de operação (p.ex., segunda a sexta, horário comercial), e disponibilidade de cobertura estendida por taxa adicional.

Erro comum: Não especificar horários operacionais ou canais de contato, deixando clientes incertos sobre como relatar problemas.

Em linguagem simples: Classifica problemas em 4 níveis (Gravidade 1 a 4) conforme impacto operacional, com prazos de resposta distintos: Gravidade 1 (1 hora, resolução em 48h), Gravidade 2 (4 horas, resolução em 5 dias), Gravidade 3 (resolução na próxima atualização), Gravidade 4 (futuras atualizações).

Erro comum: Definir prazos de resposta irrealistas ou não diferenciar entre resposta (começar a trabalhar) e resolução (problema fixado).

Em linguagem simples: O provedor compromete-se a responder e diagnosticar problemas conforme os níveis de gravidade, oferecer soluções alternativas ou correções de emergência, e exercer "melhores esforços" na resolução, reduzindo a gravidade quando solução alternativa é aceita.

Erro comum: Prometer resolução garantida (não dizer "melhores esforços") ou não deixar claro que solução alternativa reduz prioridade.

Em linguagem simples: O provedor mantém o software coberto através de atualizações e melhorias oferecidas a todos os licenciados em manutenção geral, mantendo-o livre de defeitos materiais e em conformidade com desempenho aceitável conforme acordo de licença.

Erro comum: Não esclarecer se atualizações são inclusas no contrato de manutenção ou cobradas separadamente, ou se se aplicam apenas a versões futuras.

Gravidade 1 é uma emergência — o software está completamente inoperável ou falha de forma catastrófica, afectando críticas operações. O provedor promete resposta em 1 hora (ou menos) e resolução em 48 horas. Gravidade 2 é prejudicial — o desempenho degrada significativamente ou funções principais não funcionam, mas o software é ainda usável noutras áreas. A resposta é prometida em 4 horas, com resolução em 5 dias. Escolher a gravidade certa é importante: uma falha falsa (reportar Gravidade 1 quando é Gravidade 3) sobrecarrega o suporte; uma subestimativa (reportar como Gravidade 3 quando é Gravidade 1) retarda a resolução.

'Melhores esforços' significa que o provedor se compromete a trabalhar de forma diligente e responsável, mas não garante sucesso. A linguagem protege o provedor de responsabilidade absoluta — o cliente pode não poder processar por quebra de contrato simplesmente porque o problema não foi resolvido dentro do prazo estipulado, contanto que o provedor demonstre que tentou. Sem esta linguagem, o cliente pode reivindicar indenizações pela incapacidade de resolver, mesmo se o problema for extremamente complexo.

Não é obrigatório. O modelo cobre atualizações e melhorias oferecidas em manutenção geral (p.ex., correções de bugs, patches de segurança, pequenas melhorias dentro da mesma versão). As atualizações maiores (mudança de versão, novo módulo) podem ser cobertas, mas é mais comum cobradas como um serviço adicional ou upgrade separado. Deixe claro no Anexo B se versão 3.x está coberta, mas versão 4.x requer novo contrato ou taxa adicional.

O contrato declara que a segunda parcela (p.ex., [VALOR]) é devida após a aprovação do Cliente do Plano. Se o cliente não aprova, a segunda parcela pode não ser devida, dependendo da redação. Para evitar impasse, defina um prazo (p.ex., 14 dias) para o cliente aprovar ou fornecer comentários. Se não responder, considere o plano aprovado automaticamente. Alternativamente, deixe claro que o Cliente tem direito a um período de testes antes de aprovar.

Tecnicamente, o provedor ainda responde e diagnostica (classificar como Gravidade 3 ou 4). Mas o contrato não obriga o provedor a fornecer treinamento ou consultoria se o problema é claramente de operação do cliente. Para evitar ambiguidade, inclua uma cláusula: "Suporte está limitado a erros no Software Coberto. Consultoria sobre uso, configuração, ou dados do cliente é faturada separadamente." Assim, o provedor faz o diagnóstico (coberto), mas cobrança estendida (não coberta).

Não é sustentável sem impacto operacional. Cobertura 24/7 requer pessoal escalado fora do horário, aumentando custo. O modelo permite oferecer cobertura estendida por uma taxa adicional (p.ex., +25% sobre a manutenção base). Isso deixa claro que suporte padrão (8h–18h, seg–sex) é base, e 24/7 é opcional e mais caro. Se incluir cobertura estendida na taxa base, documente que a resposta fora do horário pode ser mais lenta (p.ex., resposta em 4h vs. 1h durante o dia).

Sim, conforme o modelo: qualquer uma das partes pode rescindir após enviar aviso prévio por escrito (p.ex., 30 dias). Porém, se o cliente rescindir antes da expiração do prazo inicial (p.ex., 2 anos), o cliente paga uma indenização ao provedor (p.ex., "montante que representa compensação razoável"). Esta indenização compensa o provedor pelos custos incorridos (setup, documentação, suporte) e pelas receitas perdidas. A indenização específica deve ser definida no contrato para evitar disputas; consulte um advogado sobre o que é razoável conforme a jurisdição.

Gravidade 3: o software funciona, mas não da forma mais conveniente; o usuário sofre impacto menor ou nenhum. Exemplo: um botão está no lugar errado da interface. Resolução: na próxima atualização de manutenção (p.ex., quando forem lançadas correções de bugs da próxima rodada). Gravidade 4: perceptível, corrigível por documentação futura ou release regular. Exemplo: a documentação está desactualizada para uma função recém-adicionada. Resolução: futuras atualizações (sem prazo urgente). Ambas ficam fila e não requerem atenção imediata, mas Gravidade 3 é ligeiramente mais prioritária.

Sim, é altamente recomendado. O modelo é genérico e aplica-se tanto ao Brasil como a Portugal, mas leis de contrato, responsabilidade civil e indenizações variam entre jurisdições. Um advogado local pode ajustar cláusulas de rescisão, indenizações, limitações de responsabilidade e garantias conforme a lei local. Isto é especialmente importante se o cliente é grande ou o software é crítico para operações do cliente.