O que o contrato de sustentação de portal deve cobrir

Sustentação não é só manter no ar

Um contrato de sustentação de portal cobre quatro atividades contínuas: atualização de segurança, correção de falhas, acompanhamento de disponibilidade e apoio a quem publica. Evolução do portal, produção de conteúdo e migração costumam ficar de fora. O resto deste texto é um checklist para conferir isso no contrato, antes de assinar ou de renovar.

Quem fiscaliza e quem gere o portal nem sempre é da área técnica. Por isso, o texto evita o jargão que dá para evitar e explica o que não dá.

A ideia de que sustentação é "deixar o portal no ar" falha por três motivos:

• Dependências envelhecem. O portal roda sobre um sistema de gestão de conteúdo (o CMS) e sobre bibliotecas de terceiros. Com o tempo, elas ganham correções que o portal precisa receber.
• Falhas aparecem. Um formulário que para de enviar, uma página que quebra depois de uma publicação, um erro que só acontece em certo navegador. Alguém precisa corrigir.
• Quem publica tem dúvida. A equipe de comunicação do órgão usa o portal todo dia. Quando a publicação trava, ela precisa de um canal para pedir ajuda.

Se o contrato não nomeia essas atividades, cada uma vira pedido avulso. E pedido avulso gera discussão sobre o que estava ou não incluído.

Checklist do que o contrato de sustentação cobre

Cada item abaixo é uma pergunta que o fiscal ou o gestor pode fazer ao contrato. Se a resposta não está escrita, falta uma cláusula.

Atualização de segurança do CMS e das dependências

CMS é o sistema em que a equipe edita e publica o conteúdo do portal. Ele e as bibliotecas que o acompanham recebem atualizações de segurança do fabricante e da comunidade. Aplicá-las é uma das tarefas centrais da sustentação.

O contrato precisa responder:

• Quem aplica as atualizações e em que ambiente elas são testadas antes de chegar ao portal em produção.
• Como o órgão fica sabendo. Aviso prévio, registro posterior ou os dois. O fiscal não deve descobrir pelo relatório do mês seguinte que o portal ficou fora do ar numa madrugada.
• O que acontece se a atualização quebra um add-on. Add-on é um módulo que acrescenta função ao CMS, como um formulário próprio ou uma integração. Quando a atualização o deixa incompatível, quem ajusta? O ajuste entra na sustentação ou é demanda à parte? Essa é a pergunta que mais costuma ficar sem resposta.

Atualizar reduz a exposição a falhas conhecidas, mas não faz do portal um sistema imune. Por isso, o contrato não deveria prometer segurança como resultado. Deve descrever a atividade e quem a executa.

Correção de falhas e canal de chamados

Falha é o portal se comportando diferente do que foi entregue e aceito. Corrigi-la é sustentação. Pedir um comportamento novo não é.

Dois pontos para conferir por escrito:

• Por onde o órgão abre um chamado (sistema, e-mail ou outro canal) e quem pode abrir.
• Como o chamado é classificado. Uma página inicial fora do ar e um erro de ortografia num rodapé não pedem a mesma urgência, e o contrato deve dizer quem decide a diferença.

Os prazos de atendimento dependem do órgão e do contrato. O que não pode faltar é que existam, com responsável, e que o fiscal consiga acompanhar cada chamado do início ao fim.

Acompanhamento de disponibilidade e resposta a queda

Aqui o contrato descreve uma atividade: alguém acompanha se o portal está respondendo e age quando ele para.

Vale perguntar:

• Como o portal é monitorado e por quem.
• Quem é avisado quando ele cai, e por qual meio.
• O que o fornecedor faz a partir do aviso, e como o órgão é informado do que aconteceu e do que foi feito.

A hospedagem pode ser do órgão, de uma nuvem contratada à parte ou do próprio fornecedor. Uma queda pode ter origem na infraestrutura e não no portal. O contrato precisa dizer de quem é cada camada, para que ninguém descubra a fronteira durante a queda.

Apoio a quem publica no dia a dia

A equipe que publica no portal não precisa saber programar. Precisa saber a quem recorrer quando um perfil de acesso não funciona, quando uma página não aparece depois de publicada ou quando um fluxo de aprovação trava.

O contrato deve prever esse apoio: por quais canais, em que horário e para quais tipos de dúvida. Também ajuda definir quem, no órgão, faz a ponte com o fornecedor. O fluxo de publicação em portal mostra como essa rotina costuma ser organizada e onde as dúvidas tendem a aparecer.

Há uma fronteira aqui. Tirar uma dúvida de uso é apoio. Treinar uma equipe nova do zero ou redigir os textos é outra coisa, e o contrato deve dizer em qual lado cada uma cai.

Relatório e registro do que foi feito

O fiscal atesta o que recebeu. Sem registro, atesta de memória.

Ao atestar, vale pedir:

• a lista de atualizações aplicadas no período;
• os chamados abertos, o que foi feito em cada um e se foi encerrado;
• as ocorrências de indisponibilidade, com o que as causou, quando isso for conhecido;
• o que ficou pendente e quem precisa decidir.

O relatório não precisa ser extenso. Precisa permitir que outra pessoa, que não acompanhou o mês, entenda o que aconteceu com o portal.

O que costuma ficar de fora e vira aditivo

"Costuma ficar de fora" é uma leitura editorial da Evo Tech sobre o que gera atrito na execução de contratos de sustentação. Não é levantamento de contratos reais.

O padrão se repete: o que é sustentação está implícito, o que é novo também, e a fronteira só aparece quando alguém pede algo. Três demandas costumam cair nesse limbo.

Evolução do portal

Uma seção nova, um serviço on-line, uma integração com outro sistema, a mudança de aparência. Tudo isso é desenvolvimento, não sustentação. O portal continua funcionando sem essas mudanças, e elas exigem análise, construção e teste.

Quando o contrato não separa as duas coisas, o fornecedor entende que evolução é pedido extra e o órgão entende que "sustentação" incluía pequenos ajustes. O desencontro aparece no primeiro pedido.

Produção de conteúdo

Redigir notícias, diagramar páginas, subir documentos e manter o conteúdo atualizado é trabalho da equipe do órgão, ou de um contrato de comunicação. Apoiar quem publica é uma coisa. Publicar no lugar de quem deveria é outra.

Se o órgão espera que o fornecedor também alimente o portal, isso precisa estar escrito como escopo próprio, com a forma de solicitar e de aprovar.

Migração de versão e de plataforma

Atualização de segurança dentro da mesma linha do CMS é rotina. Mudar para uma versão com alterações maiores, ou trocar de plataforma, é projeto. Envolve inventário, adaptação de add-ons, testes e, quase sempre, endereços que mudam.

Nesse caso, cada endereço antigo precisa de um destino definido. O mapa de redirecionamentos na migração de portal mostra como isso é feito, linha a linha. Em portais em Plone, essa é uma das frentes de Plone para governo, e o contrato de sustentação deve dizer que ela não está incluída. Para um portal que não é Plone, a lógica é a mesma, e o trabalho de substituição está em criação de sites e portais institucionais.

Nos três casos, o jeito mais simples de evitar o aditivo surpresa é incluir no contrato uma regra de fronteira em três partes:

1. O que é sustentação: a lista de atividades acima, descrita em termos que o fiscal consiga conferir.
2. O que é demanda nova: evolução, conteúdo e migração, nomeados como tal.
3. Como a demanda nova é solicitada e orçada: quem pede, quem avalia, como o fornecedor apresenta a estimativa e quem aprova, tudo antes de começar.

O contrato não precisa trazer valores nem prazos dessa demanda futura: precisa trazer o caminho. Com ele escrito, um pedido novo vira um procedimento conhecido, e não uma negociação.

O termo de referência de um portal é o lugar natural para essa regra nascer. Se o termo já foi publicado sem ela, o contrato de sustentação ainda pode registrá-la.

Se quiser conferir o contrato do seu portal contra esta lista, conheça a frente de sustentação de portal em Plone e fale com a Evo Tech.