A parte mais cara de qualquer projeto de software não é o desenvolvimento. São os anos seguintes, quando o sistema precisa de ser mantido vivo — atualizado, protegido, monitorizado, adaptado a dependências em mudança — e o fornecedor original já não aparece.
O suporte de TI gerido é o trabalho aborrecido e pouco glamoroso que faz a diferença entre um sistema que se mantém operacional e outro que se degrada silenciosamente durante dezoito meses antes de falhar de forma espetacular. É também a parte do serviço que a maioria dos fornecedores vende de forma casual e entrega pior do que prometeu.
As três perguntas
Antes de assinar qualquer contrato de suporte — incluindo um connosco — faça estas três perguntas.
1. Quem responde exatamente quando abro um ticket às 16h de uma sexta-feira?
A resposta certa identifica uma equipa específica, num fuso horário específico, com um SLA específico. A resposta errada é um link para um portal de suporte e garantias vagas. Qualquer oferta de suporte que não consiga identificar as pessoas que vão realmente responder, e os seus horários de trabalho, está mais próxima do marketing do que do serviço.
2. O que é que o "suporte" cobre — e, tão importante quanto isso, o que não cobre?
Os contratos de suporte reais são específicos: correções de segurança, atualizações de dependências, adaptação a alterações incompatíveis, monitorização, resposta a incidentes, análise da causa raiz. Contratos vagos permitem ao fornecedor faturar trabalho "adicional" sempre que acontece algo interessante.
Peça a lista de exclusões. A lista de exclusões diz-lhe o que o contrato de suporte realmente é. Se a lista de exclusões estiver em falta ou for evasiva, o contrato de suporte é uma licença para caçar — o fornecedor pode faturar à hora na primeira vez que algo fora do normal acontecer.
3. Qual é o caminho de escalonamento quando a primeira linha de resposta não consegue resolver?
Toda a organização de suporte tem uma boa equipa e uma excelente equipa. A excelente equipa custa mais e é usada menos vezes. Se o caminho de escalonamento entre a triagem de tickets e o engenheiro sénior não for claro, os incidentes que precisam do engenheiro sénior vão ficar dias na triagem.
A resposta certa identifica um gatilho de escalonamento específico e um sénior específico. A resposta errada é dizer que "a equipa trata disso de forma colaborativa" — que é uma forma educada de dizer que ninguém é responsável.
O que cobrimos
O suporte de TI gerido na KIMISUITE é o serviço contínuo que decorre depois de termos desenvolvido ou migrado um sistema para si. Tem um âmbito específico:
- Monitorização de disponibilidade — todos os sistemas que operamos têm monitorização ativa com alertas para engenheiros de prevenção, não apenas para um painel que ninguém consulta.
- Aplicação de correções de segurança — atualizações de dependências numa cadência definida, além de correções de emergência para CVEs que afetem a stack.
- Monitorização de desvios de conformidade — o enquadramento regulatório está sempre a mudar. O nosso serviço de suporte inclui sinalizar as alterações que afetam os seus sistemas antes de se tornarem problemas de auditoria.
- Resposta a incidentes — com SLA para a primeira resposta, SLA para a resolução e um relatório pós-incidente escrito após cada incidente significativo.
- Adaptação a alterações de terceiros — quando o fornecedor de pagamentos altera a API, quando o sistema operativo lança uma atualização que quebra uma integração, quando o navegador descontinua algo de que dependia. A categoria de trabalho que ninguém vê até não ser feita.
Não cobrimos: desenvolvimento de novas funcionalidades (é um serviço separado), alterações significativas ao âmbito de funcionamento do sistema (também separado) ou formação de utilizadores (podemos fornecer, mas como trabalho com âmbito definido).
Perguntas frequentes
Isto é uma subscrição ou um avençado?
Um plano mensal definido, associado a uma cobertura específica. Não é um avençado em que as horas são gastas em trabalho ambíguo — dizemos-lhe exatamente o que o plano inclui.
Dão suporte a sistemas que não desenvolveram?
Caso a caso. Podemos assumir o suporte de sistemas desenvolvidos por outros fornecedores se o código e a infraestrutura estiverem num estado ao qual possamos comprometer-nos de forma responsável. Se o sistema não estiver documentado e for frágil, podemos recomendar primeiro um projeto de estabilização antes de iniciar o suporte.
E quanto ao piquete para emergências?
Todos os planos incluem um número de prevenção para emergências reais em produção. Os SLAs de resposta variam consoante o nível.
Tratam de suporte de TI ao utilizador final — portáteis, email, impressoras?
Normalmente não. O nosso âmbito de suporte centra-se nos sistemas e aplicações que nós ou outros desenvolvemos — não em TI geral de escritório. Para TI geral, podemos recomendar parceiros locais.
Conclusão
Desenvolver software é a parte pequena. Mantê-lo vivo durante a próxima década é a parte grande — e é a parte que os fornecedores adoram encurtar. Faça as três perguntas acima a qualquer oferta de suporte, incluindo a nossa. Se as respostas não forem específicas, a cobertura não é real.