O básico bem feito nunca sai de moda

Dia desses caiu num grupo que eu participo uma vaga que me fez parar o scroll.

A empresa é uma das mais cobiçadas do mercado brasileiro de tecnologia. Nativa digital, engenharia forte, o tipo de lugar que aparece em palestra como exemplo do que vem depois do modelo antigo e que todo mundo quer usar de bench. A vaga era sênior, para trabalhar com gestão de serviços.

Aí eu li a descrição.

Basicamente, queriam alguém para ajudar a construir a prática de ITSM do zero. Definir e implementar o que a turma old school como eu conhece por gestão de incidentes, gestão de problemas, gestão de mudanças, gestão de requisições e gestão do conhecimento. Montar catálogo de serviços com SLAs e OLAs (curiosidade: OLA é um termo que o ITIL 4 deixou de citar, porque na prática todo mundo chama tudo de SLA e o que muda é só o lado da mesa em que você está). Estabelecer um CAB, com documentação estruturada e fluxo de aprovação. Acompanhar MTTR, aderência a SLA, resolução no primeiro contato e taxa de sucesso de mudança.

Nenhuma menção a IA. Em nenhum ponto da descrição.

Eu trabalho com isso há mais de vinte anos e já vi estes mesmos requisitos em editais, em contratos de outsourcing e em vagas de empresas pequenas, médias e grandes, de todo tipo de segmento. Ver a mesma lista em 2026, escrita como um projeto novo e não como um legado a ser mantido, é o tipo de coisa que reforça a minha tese:

O que envelhece é a interface do básico, não o básico.

A palavra que estava na vaga era expectativa

Repare num requisito da vaga sobre catálogo de serviços: SLAs e OLAs alinhados à expectativa dos stakeholders internos.

Expectativa. Não é uma palavra que eu esperava encontrar do lado de OLA numa descrição de 2026, porque nos últimos anos ela foi sequestrada por outro acrônimo.

Você já ouviu falar do XLA, o Experience Level Agreement. A tese é conhecida: o SLA mede se o chamado fechou no prazo, o XLA mede se a pessoa ficou satisfeita, e por isso o SLA estaria superado (sei que estou simplificando, mas você entendeu o ponto).

O detalhe é que nem quem vive disso defende a troca. A HappySignals, que é uma plataforma dedicada a medir experiência de TI, afirma no próprio guia sobre o tema que XLA não é substituto de SLA, e sim uma mudança do que se mede: de entrega para resultado.

E tem uma segunda camada, que é a que me interessa mais.

Entender o que é cada serviço, quem é o cliente de cada serviço e o que esse cliente espera dele não é uma descoberta recente. É literalmente o assunto original da nossa disciplina, o bom e velho ITSM. O antecessor do ITIL, o GITMM publicado pelo governo britânico em 1988, era focado justamente em service level management, e o primeiro livro publicado já com o nome ITIL, em 1989, tratava exatamente disso. Antes de existir help desk como capítulo, antes de existir gerenciamento de mudança como processo, o que estava escrito era: combine o nível de serviço com quem usa o serviço.

Trinta e sete anos depois, tem gente vendendo isso de novo como ruptura.

Não me entenda mal. Medir esforço, sentimento e satisfação é bom, e a maioria dos relatórios de SLA que eu já vi na vida realmente não dizia nada sobre se o cliente estava bem servido. O problema não é a medição nova. O problema é a promessa que vem junto: a de que você pode pular a parte chata de mapear serviço, definir cliente e acordar expectativa, e ir direto para o dashboard de sentimento.

O XLA sem catálogo é uma pesquisa de humor.

Nenhuma onda quebra na camada nova

O XLA não é caso isolado. É o exemplo mais recente de um padrão que se repete há pelo menos quinze anos, e o padrão é sempre o mesmo: a onda nova não quebra na camada nova. Ela quebra no andar de baixo.

Olha o DevOps. Eu não vou dizer que DevOps não vingou, porque isso é falso e temos estatísticas cristalinas sobre isso: entrega mais frequente, lead time menor, feedback mais curto, tudo isso aconteceu e está medido. O que não vingou foi a segunda metade da frase. O “you build it, you run it” virou, na prática, “you build it, and someone still runs it”. Muito time que adotou o modelo continua com o foco inteiro no build, e o run vira questão de baixa prioridade.

Olha o AIOps. A promessa é ótima, e eu compro a promessa. Só que ela depende de um insumo que quase ninguém tem em ordem: dado de qualidade.

A Gartner pesquisou 248 líderes de gestão de dados e encontrou 63% de organizações que não têm, ou não sabem se têm, as práticas de gestão de dados adequadas para IA, e projeta que até 2026 as empresas abandonem 60% dos projetos de IA não sustentados por dados preparados. Não é o modelo que falha. É o CMDB desatualizado, o inventário incompleto e o registro de incidente preenchido de qualquer jeito.

Olha a gestão preditiva. Prever incidente antes que ele aconteça é o sonho de quem já ficou de plantão e de quem deseja uma gestão de TI do futuro. Só que predição funciona sobre sinal, e o que a maioria das operações tem é ruído. Uma pesquisa da OpsRamp citada pela Ennetix aponta 78% dos times de NOC relatando fadiga de alerta, com média acima de dez mil alertas por dia e menos de 5% deles exigindo ação humana imediata. Se você joga isso num algoritmo, o que sai do outro lado é ruído com carimbo de inteligência.

Três ondas, três promessas legítimas, um único ponto de falha. Falta gerenciamento de evento, falta qualidade de dado, falta responsabilidade operacional definida. Nada disso é camada nova. É tudo andar de baixo, o arroz com feijão e o bife no prato (bem temperado, claro).

Tem até uma versão desse mesmo achado dentro da pesquisa mais respeitada de engenharia que existe. O relatório DORA de 2025 concluiu que a IA não melhora a entrega de software automaticamente: ela age como multiplicador das condições que já existem, reforçando quem tem processo bom e expondo quem tem processo fragmentado. E o relatório de 2024 já tinha mostrado algo parecido com plataformas internas, que sobem a produtividade individual e ao mesmo tempo derrubam estabilidade de mudança e throughput quando são implantadas sem cuidado.

A ferramenta amplifica o que já está lá. Se o que está lá é bagunça, você acabou de comprar bagunça em escala.

O engraçado é que a resposta para tudo o que eu escrevi até aqui não é opinião minha. É um princípio orientador do ITIL 4, e a ordem das palavras faz parte do enunciado: otimize e automatize, nessa ordem.

E continua sendo o passo que todo mundo pula.

Mas convenhamos, o formulário de 300 campos precisa morrer

Existe um tipo de profissional de governança que lê tudo o que eu escrevi acima e conclui que está tudo certo do jeito que está. Que o formulário de abertura de mudança com trinta campos obrigatórios é rigor. Que exigir do usuário a classificação do próprio incidente entre catorze categorias é disciplina. Que se o cliente não sabe preencher, o problema é do cliente.

Esse profissional está perdendo a discussão, e está perdendo com razão.

Ninguém mais tem paciência para preencher formulário. A experiência precisa ser conversacional, no canal que a pessoa já usa, no dispositivo que ela já tem na mão, sem que ela precise aprender o vocabulário interno da TI para pedir ajuda. E hoje dá para fazer isso: o modelo entende o que a pessoa escreveu, classifica, enriquece, roteia e devolve para ela em linguagem de gente.

Note o que mudou nesse parágrafo e o que não mudou. A classificação continua existindo. A categoria continua existindo. O impacto e a urgência continuam existindo. O que morreu foi a obrigação de o usuário digitar tudo isso num formulário.

Quem confunde o básico com a interface do básico joga as duas coisas fora juntas. Aí tira o formulário, tira junto a categorização, e seis meses depois descobre que não consegue mais responder quantos incidentes de rede aconteceram no trimestre.

O CAB que a pesquisa condena não é o CAB que eu defendo

Aqui eu preciso admitir uma coisa antes de seguir: a pesquisa não está do meu lado.

Organizações com processo formal de aprovação por instância externa ao time, vulgo CAB, têm 2,6 vezes mais chance de estar no grupo de baixo desempenho, segundo o relatório da DORA de 2019, que também não encontrou evidência de que esse rito reduza a taxa de falha de mudança. Ou seja: o comitê que aprova o que não entende não protege ninguém. Ele só cobra pedágio.

E não é só a DORA. O próprio ITIL 4 andou nessa direção. “Change control” era como a prática aparecia na edição de fundamentos de 2019, e a comunidade reagiu tão mal ao termo que, quando saiu o guia completo em 2020, ela já se chamava change enablement, ou habilitação de mudanças. Junto veio a substituição do modelo de CAB pelo papel de autoridade de mudança e pelo conceito de autoridade delegada, com revisão por pares e automação fazendo o trabalho pesado.

Então alguém pode ler sobre a vaga que abre este texto e dizer que aquilo não é o básico, é saudade da v3.

Não é. E é aqui que a coisa fica interessante.

A DORA, na página sobre simplificação de aprovação de mudanças, descreve o papel que sobra depois que a revisão detalhada vai para os pares e para a automação: coordenar times, apoiar melhoria de processo e decidir os trade-offs de negócio que exigem alguém com autoridade para escolher entre prazo e risco. Eles chamam esse papel de estratégico, com todas as letras. É a mesma coisa que o ITIL 4 chama de autoridade de mudança.

Ninguém está dizendo que a instância de decisão desaparece. Estão dizendo que ela para de carimbar tudo e passa a decidir o que só gente pode decidir. Num ambiente regulado, com evidência estruturada de controle operacional, ela não é nostalgia: é requisito de auditoria.

É exatamente esse CAB que eu defendo.

E é aqui que a tecnologia entra pelo lado certo. A IA prepara o palco para o julgamento: correlaciona a mudança com incidentes anteriores parecidos, mostra o histórico do serviço afetado, sinaliza a janela de risco, monta a curadoria de dado que manualmente levaria dois dias e que ninguém faz. O julgamento continua humano, porque a pergunta que importa naquela sala não é técnica.

A pergunta é se vale a pena correr esse risco, neste trimestre, com esse cliente. Dificilmente um modelo responde isso por você.

Dito isso…

A próxima onda já está sendo escrita agora, em alguma apresentação com fundo gradiente. Vai ter um acrônimo de três letras, vai ter um gráfico de quadrantes e vai vir com a promessa de sempre: que desta vez você não vai precisar arrumar o que está embaixo.

Vai quebrar no mesmo lugar. Falta de dado confiável, falta de dono, falta de acordo sobre o que é o serviço.

Então a pergunta que eu faria antes de adotar qualquer nova novidade é: o que eu preciso pavimentar para que isso funcione aqui?

Se você já viu uma iniciativa moderna quebrar por causa de um fundamento velho, me conta qual foi. Eu coleciono esses casos, e desconfio que o seu se parece com o meu.

E se quiser receber os próximos textos direto no e-mail, é só assinar a newsletter aqui do blog. =)