Essa semana apareceu um post interessante no LinkedIn. Um sujeito se muda para Chicago. Antes de escolher o bairro, ele não abre portal de imóveis nem tabela de criminalidade da prefeitura. Abre o Strava. (caso você não faça ideia do que se trata por ser sedentário, como o autor deste artigo, trata-se de um app de corrida, ciclismo e trilha).
O aplicativo tem um mapa de calor global que mostra, em linhas brilhantes, onde as pessoas correm e pedalam. O mapa de Chicago viralizou depois que um usuário disse que aquilo era um proxy gigante de classe e riqueza. Na sequência, alguém apontou o uso óbvio: dá para usar como critério de onde morar.
Nas redes, virou “mapa de criminalidade invertido”. Você sabe que o bairro é seguro quando vê gente correndo nele.
Um estudo de Boston publicado em 2023 cruzou justamente o heatmap do Strava com as características das ruas da cidade.
A conclusão: corredores preferem ruas acessíveis, abertas, limpas e seguras, com atrativos naturais. E ruas cheias de interrupções e distrações tendem a inibir a corrida.
A percepção de segurança e menor densidade de crime aparecem com impacto positivo sobre a intensidade de corrida.
Ninguém no Strava sentou para construir um índice de qualidade urbana. Eles queriam ajudar corredor a achar uma rota.
O dado foi coletado para uma pergunta e acabou respondendo outra, que ninguém tinha feito.
O insight: todo dado operacional carrega também um dado comportamental
Você abre chamado para restabelecer serviço. Registra mudança para ter rastreabilidade. Preenche causa raiz para fechar o ciclo do incidente. Cada um desses dados nasceu com uma finalidade operacional clara, e cumpre essa finalidade.
Mas nenhum dado registra só o que ele foi feito para registrar. Ele também registra como as pessoas se comportaram enquanto o produziam. O horário. A demora. Quem acionou quem. O que ficou em branco.
Esse segundo dado está lá, de graça, e quase ninguém lê.
E aí a gente cai nesse ciclo vicioso. Fazemos as mesmas perguntas aos dados: quantos incidentes tivemos, qual a taxa de sucesso das mudanças, qual o tempo médio de atendimento, quais foram as áreas com maior número de incidentes e requisições?
E, previsivelmente, chegamos à mesma conclusão. Aplicamos a mesma ação. E esperamos, com uma fé admirável, um resultado diferente.
O problema não é que falta dado. Dado tem de sobra. O que falta é pergunta.
Um dashboard mede o que você programou nele para medir. Se você programou “volume de chamados por categoria”, ele vai te dizer o volume de chamados por categoria até o fim dos tempos. E vai continuar em silêncio sobre tudo o mais que aqueles registros sabem.
Três perguntas que sua base já responde (e talvez você ainda não tenha feito)
Nada aqui exige projeto novo, ferramenta nova ou verba. Exige olhar o que já está na base com uma pergunta diferente na cabeça.
Com uma ressalva: duas dessas perguntas se respondem com o que está registrado. A primeira se responde com o que deveria estar registrado e não está. São coisas diferentes, e a diferença importa.
1. O que as pessoas usam quando não estão usando a sua ferramenta?
A planilha paralela. O grupo de WhatsApp onde o problema é resolvido antes de virar chamado. O formulário que alguém montou porque o fluxo oficial demorava demais.
Esse é o dado mais desconfortável de todos, porque ele não está no seu ITSM. Está na ausência de registro no seu ITSM. E é o retrato mais honesto que existe da diferença entre o processo desenhado e o processo praticado.
O detalhe é que ausência só vira dado quando você sabe o tamanho do vazio. Uma área com volume implausivelmente baixo, uma categoria que secou de um mês para o outro, uma etapa do fluxo que ninguém preenche há um ano: isso a sua base te entrega. O que aconteceu no lugar, não. Essa parte exige levantar da cadeira e ir perguntar.
Se o caminho oficial fosse melhor, ninguém teria inventado atalho.
2. Onde os incidentes não acontecem?
A gente olha o topo da curva ABC, porque é onde dói. Mas a cauda também informa.
Se você tem duas aplicações com complexidade e criticidade comparáveis, e uma delas quase não gera incidente, isso não é sorte nem falta de registro. É prática. Vale uma conversa de uma hora com esse time tanto quanto uma análise de causa raiz do time que está pegando fogo.
3. Quanto tempo uma mudança demora para ser aprovada — e por quem?
O dado de change enablement existe para rastreabilidade e controle de risco. Mas o tempo de aprovação, quem aprova o quê e para quem, e onde as RDMs emperram desenham a topologia real de confiança da organização.
Você vai descobrir que existem times cuja mudança passa em quatro horas e times cuja mudança idêntica leva quatro dias. Isso não está no organograma. Está no seu log de aprovação.
Quem gerou esse dado?
Voltemos ao Strava. Aquele mapa não é um censo. É um mapa de onde um grupo bem específico escolhe passar o tempo livre. E a base de usuários do aplicativo é reconhecidamente enviesada para homens mais ricos, jovens e de meia-idade, praticantes de corrida e ciclismo.
Ou seja: o mapa não mede segurança. Mede quem registra corrida no aplicativo. A segurança é uma inferência em cima disso, e uma inferência que passa por renda, calçada e tempo livre antes de chegar em qualquer coisa parecida com criminalidade.
Traduz para a nossa casa e o efeito é imediato.
Sua base de tickets não mede problema. Mede quem abre chamado.
A área/cliente que reclama muito pode ser a que tem mais problema ou a que tem mais gente disponível para preencher formulário. A área/cliente silenciosa pode estar saudável ou pode ter desistido de você faz tempo.
Quando você reaproveita um dado fora da finalidade original, o viés que era irrelevante na leitura original vira o centro da nova leitura. E não há nada de errado em reaproveitar. Só não dá para reaproveitar sem perguntar quem gerou aquilo e quem ficou de fora.
E quem mais está lendo?
Tem um segundo ponto, e esse custa mais caro.
Em janeiro de 2018, um estudante australiano chamado Nathan Ruser abriu o mesmo mapa de calor global e olhou para o Oriente Médio. Ele percebeu que o mapa expunha localização e rotina de corrida de militares em bases em zonas de conflito. Onde quase ninguém usa rastreador de atividade física, qualquer luz acesa vira endereço.
O resultado foi o Departamento de Defesa americano revisando as regras de uso de dispositivos e aplicativos pelo próprio pessoal.
Mesmo mapa. Mesmo dado. Mesma empresa. Uma leitura ajuda alguém a escolher um bairro. A outra entrega perímetro militar.
Esse é o contraponto necessário: dado reaproveitado é dado saindo do contexto em que foi consentido, protegido e classificado.
Aquele relatório de tempo de aprovação de mudança, olhado com outros olhos, é um ranking informal de quem é lento. Aquele mapa de causa raiz por equipe, na mão errada, vira lista de culpados. O dado não muda, muda quem lê e para quê.
Não é motivo para não fazer. É motivo para decidir antes quem tem acesso, com qual granularidade e para responder qual pergunta. Se a resposta a “para que serve isso” for “para descobrir de quem é a culpa”, o problema não está no dado.
Para refletir
A próxima resposta que você precisa provavelmente não está num dado que você ainda não coleta. Está num dado que você já coleta há anos, esperando alguém fazer a pergunta certa.
O Strava levou uma década de gente correndo para virar critério de escolha de bairro — e virou por acidente, porque alguém olhou o mapa com uma intenção que não era a de quem construiu o mapa.
E você, já teve algum dado do seu ITSM te contando uma coisa que ninguém tinha pedido para ele contar? Um relatório de mudança que virou diagnóstico de time, uma categoria vazia que explicava um processo abandonado, um indicador que respondeu a pergunta errada e acertou outra? Me conta nos comentários. Esse tipo de história raramente sai em case, e é onde mora o aprendizado de verdade.
Se você quiser receber os próximos textos por e-mail, assine a newsletter do blog. Sem cadência prometida, só quando tem coisa que vale.
Assine minha Newsletter
Receba meus novos artigos, pensamentos e opiniões diretamente no seu email.