Toda equipe de sustentação de ERP conhece a cena: uma fila com dezenas de chamados, cada solicitante convencido de que o seu é o mais urgente, e o time apagando incêndios sem conseguir avançar em nada estrutural. No fim do mês, a sensação é de muito esforço e pouco resultado visível.
O problema raramente é falta de trabalho duro. É falta de critério. Este artigo propõe uma forma simples de organizar o backlog de sustentação para que a fila seja previsível, defensável e alinhada ao que o negócio realmente precisa.
Separe o que é sustentação do que não é
O primeiro passo é parar de tratar tudo como “chamado”. Itens de natureza diferente competem pelo mesmo time, mas não podem ser priorizados da mesma forma.
| Tipo | O que é | Exemplo |
|---|---|---|
| Incidente | Algo que funcionava e parou ou está errado | Rotina de faturamento travando na geração da nota |
| Dúvida / suporte | O sistema funciona, o usuário precisa de orientação | Como emitir um relatório com outro filtro |
| Melhoria | Mudança pequena em algo que já existe | Novo campo em uma tela, ajuste de validação |
| Projeto | Demanda nova, com escopo, esforço e risco maiores | Integração com um sistema novo, novo processo |
Essa classificação muda tudo. Incidentes seguem um fluxo de resposta rápida. Dúvidas viram base de conhecimento e treinamento. Melhorias entram no backlog priorizado. Projetos saem do backlog de sustentação e vão para o portfólio, com patrocinador e aprovação própria.
Se um “chamado” leva mais de alguns dias de esforço ou envolve mais de uma área, provavelmente é um projeto disfarçado de melhoria. Tratá-lo como sustentação é o caminho mais curto para atrasar todo o resto.
Defina critérios de prioridade que o negócio entenda
Prioridade não pode depender de quem grita mais alto ou de quem tem o cargo mais alto. Ela precisa de critérios claros, conhecidos por todos.
Para incidentes, uma matriz de impacto e urgência costuma ser suficiente:
| Urgência alta | Urgência baixa | |
|---|---|---|
| Impacto alto (parada de processo, muitos usuários, risco fiscal ou financeiro) | P1 — tratar imediatamente | P2 — tratar no mesmo dia |
| Impacto baixo (um usuário, existe contorno) | P3 — tratar na semana | P4 — tratar quando houver janela |
Para melhorias, use uma pontuação simples que combine valor e esforço. Um modelo prático:
- Valor (1 a 5): economia de tempo, redução de erro, exigência legal, impacto em cliente.
- Abrangência (1 a 5): quantas pessoas ou processos são beneficiados.
- Esforço (1 a 5): horas estimadas, complexidade técnica, risco de efeito colateral.
Pontuação = (Valor × Abrangência) ÷ Esforço. Não é uma fórmula perfeita — e não precisa ser. O ganho está em tornar a conversa objetiva: em vez de “o meu é mais importante”, discute-se por que um item tem valor 4 e não 2.
Reserve capacidade por tipo de trabalho
Um erro comum é deixar que incidentes consumam toda a capacidade do time. Quando isso acontece, as melhorias nunca andam, os mesmos problemas continuam gerando novos incidentes, e o ciclo se repete.
Uma alternativa é dividir a capacidade da equipe de forma explícita, por exemplo:
- 50% para incidentes e suporte — com esse percentual revisado a cada mês, conforme o histórico.
- 30% para melhorias priorizadas do backlog.
- 20% para dívida técnica e prevenção — corrigir causas-raiz, revisar customizações frágeis, documentar.
Os percentuais exatos dependem do ambiente. O importante é que existam, sejam conhecidos e sejam acompanhados. Se os incidentes passarem do limite com frequência, isso é um dado para a gestão — não algo a ser absorvido em silêncio pelo time.
Faça um ritual curto e regular de priorização
Critério sem ritual vira planilha esquecida. Uma rotina simples funciona bem:
- Triagem diária (15 minutos): classificar o que entrou, definir prioridade de incidentes, devolver pedidos incompletos.
- Priorização quinzenal ou mensal (1 hora): com os key users ou responsáveis de cada área, revisar a pontuação das melhorias e decidir o que entra no próximo ciclo.
- Revisão mensal de indicadores: volume por tipo, tempo de atendimento, itens mais recorrentes.
A presença das áreas de negócio na priorização é o ponto mais importante. Quando quem pede participa da decisão, a TI deixa de ser a “dona da fila” e passa a ser parceira na escolha do que traz mais resultado.
Exija um mínimo de informação para entrar na fila
Muito tempo de sustentação é perdido tentando entender o que foi pedido. Defina um padrão mínimo para qualquer solicitação:
- Qual processo e qual rotina estão envolvidos.
- O que acontece hoje e o que deveria acontecer.
- Passos para reproduzir, com exemplo real (documento, pedido, produto).
- Impacto: quantas pessoas, que prazo, que risco.
Solicitações incompletas voltam ao solicitante antes de entrar no backlog. Parece burocrático, mas reduz drasticamente o vai-e-vem e acelera o atendimento de todos.
Ataque as causas, não só os sintomas
O backlog também é uma fonte de diagnóstico. Uma vez por mês, olhe para os incidentes resolvidos e pergunte:
- Quais rotinas ou integrações geram mais chamados?
- Quais incidentes são, na verdade, falta de treinamento?
- Que customizações quebram a cada atualização?
Os três ou quatro itens que mais se repetem merecem virar melhorias ou ações de prevenção prioritárias. É assim que a fila diminui de verdade ao longo do tempo — e é exatamente para isso que serve a capacidade reservada para dívida técnica.
Indicadores para acompanhar
Poucos indicadores, bem escolhidos, bastam para mostrar a evolução:
| Indicador | O que mostra |
|---|---|
| Volume de entrada por tipo | Se a demanda está crescendo e de que natureza |
| Tempo médio de atendimento por prioridade | Se o time está cumprindo o combinado |
| Idade média do backlog de melhorias | Se as melhorias estão andando ou só acumulando |
| Incidentes recorrentes | Se as causas-raiz estão sendo tratadas |
| Distribuição real da capacidade | Se a divisão planejada está sendo respeitada |
Checklist para começar na próxima semana
- Classificar o backlog atual em incidente, dúvida, melhoria e projeto
- Retirar os projetos do backlog de sustentação e levá-los para aprovação própria
- Publicar a matriz de prioridade de incidentes
- Pontuar as melhorias com valor, abrangência e esforço
- Definir a divisão de capacidade do time
- Agendar a primeira reunião de priorização com as áreas
- Definir o padrão mínimo de informação para novas solicitações
Um backlog bem organizado não elimina a pressão do dia a dia, mas transforma a conversa: em vez de justificar atrasos, a sustentação passa a mostrar escolhas, critérios e resultados. É isso que dá previsibilidade ao time e confiança ao negócio.
