Mapeamento de Dores: o ponto de partida da estratégia com IA
Antes de qualquer ferramenta de IA, tem uma pergunta que quase ninguém responde direito: onde dói de verdade, e quanto isso custa? Esta aula ensina o workshop de mapeamento de dores, em três blocos, com métrica de resultado em quatro categorias, para você abrir a trilha de Estratégia com dado, não com achismo.
Você senta para fazer o seu mapeamento de dores e a primeira ideia que vem é "quero um dashboard". Pare. Antes de qualquer solução, a pergunta certa é outra: qual atividade te consome tempo demais, com que frequência, e quanto custaria medir essa melhora daqui a seis meses? É aí que o mapeamento começa de verdade.
Você lista rapidinho três dores do RH numa reunião de planejamento: "processo lento", "muita coisa manual", "gente reclama". Nenhuma tem número, e por isso nenhuma vira prioridade quando o orçamento é disputado. O mapeamento de verdade pede outra coisa: qual processo exatamente, quantas horas ele consome por ciclo de contratação, com que frequência se repete, e o que aconteceria se você cortasse esse tempo pela metade. Só depois desse número a dor vira algo defensável numa reunião, não mais um desabafo de corredor.
Você escreve "priorização confusa" como dor do produto e já quer pular direto para a solução: "preciso de uma IA que prioriza pra mim". Segura essa ideia um instante. Primeiro mede: quantas horas o time gasta em reunião decidindo o que entra no próximo sprint, e com que frequência essa decisão muda de ideia no meio do caminho, obrigando a redesenhar o board inteiro. Sem esse número, você troca uma dor real por uma ferramenta bonita que talvez nem resolva o que trava de fato.
Você aponta "perco muito lead" como dor comercial, sem número nenhum atrás. O mapeamento pede o dado: quantos leads esfriam por semana esperando resposta no CRM, e quanto isso, em oportunidade perdida, já custou de faturamento no último trimestre. Só com esse número na mão o problema sai da conversa de corredor e entra na pauta que o board decide priorizar.
Você escreve "SLA estoura direto" no quadro e já passa pra próxima linha, sem detalhar nada. Mas o mapeamento de dores exige o número atrás da frase: com que frequência o SLA estoura por mês, quantas horas o time gasta apagando incêndio depois de cada estouro, e qual o custo real disso em retrabalho ou multa contratual. Sem esse dado, "estoura direto" é desabafo, não prioridade.
Você anota "auditoria é sofrida" e segue em frente sem detalhar. O mapeamento certo pergunta: quantos controles você revisa manualmente por ciclo, quanto tempo isso consome do seu mês, e qual risco fica sem cobertura hoje simplesmente porque não sobra tempo para checar tudo. É esse risco descoberto, nomeado e medido, que justifica investir em automatizar a revisão.
Você escreve "muito código repetitivo" e já pensa direto em ferramenta nova. Antes disso, o mapeamento pede o número: quantas horas por sprint viram esse tipo de tarefa mecânica, e qual a taxa de retrabalho quando alguém erra a mão nesse trecho de código. Só com esse número fica claro se vale automatizar ou se o tempo perdido nem era tão grande quanto parecia da cadeira.
Você anota "pesquisa demora muito para virar insight" sem detalhar mais nada. O mapeamento exige: quantas horas leva hoje da entrevista até o relatório pronto, e quantas decisões de design ficam paradas nesse meio tempo esperando esse relatório sair. É essa fila de decisão parada que mostra o custo real do atraso, não a sensação vaga de que demora muito.
Putz, deixa eu te fazer uma pergunta antes de qualquer conversa sobre ferramenta de IA: onde dói, exatamente, e quanto isso custa? Parece óbvio, mas quase ninguém responde direito. A resposta que a maioria dá é vaga: "a gente perde tempo", "é meio manual", "podia ser mais rápido". Isso não é uma dor mapeada, é um desabafo. E desabafo não vira prioridade, não vira orçamento, não vira projeto. Esta aula é o primeiro passo da trilha de Estratégia: o workshop que transforma desabafo em dado.
A ideia central desta aula. Antes de escolher onde a IA entra, você mapeia a dor com precisão: em três blocos (as suas, as da sua área, e a mais chata e operacional), cada uma com uma métrica de resultado numa de quatro categorias, tempo, custo, qualidade ou risco evitado. Sem número, a dor não é mapeada, é opinião. E é esse mapa, com número, que vira o ponto de partida de tudo que a trilha de Estratégia ensina depois.
01Por que mapear a dor antes de pensar solução
Tem um reflexo quase automático quando alguém fala em IA: pular direto para a solução. "Quero um agente que...", "preciso de um dashboard que...", "dava para ter uma IA que...". O problema é que solução sem dor mapeada é aposta às cegas. Você pode acabar construindo algo bonito para um problema que não é, nem de longe, o que mais dói na sua rotina ou na sua área.
Mapear antes de idear resolve dois problemas de uma vez. Primeiro, te obriga a nomear a dor real, não a primeira ideia de ferramenta que passou pela cabeça. Segundo, te dá uma linha de base: se você não sabe quanto tempo, dinheiro ou risco a dor custa hoje, você nunca vai conseguir provar, depois, que a solução funcionou. Sem número no início, não tem "antes e depois" para mostrar no fim.
02Os três blocos
O mapeamento se organiza em três blocos, cada um com uma pergunta diferente por trás.
Bloco A, as suas. Três dores das suas próprias atividades: o que consome tempo demais, o que te frustra com frequência, o que você vive adiando. Comece por aqui porque é o terreno que você conhece melhor, e é onde fica mais fácil ser honesto sobre o número.
Bloco B, as da sua área. Três dores de quem trabalha com você ou depende de você, sem repetir nada que já entrou no Bloco A. Se a dor da área é literalmente a mesma dor pessoal, procure outra: o objetivo é mapear o problema, não preencher linha.
Bloco C, a mais chata. Uma atividade só, a mais mecânica e operacional que você faz hoje, repetitiva, sem nenhuma decisão real envolvida. E a pergunta que acompanha essa: por que ela ainda existe do jeito que está? Às vezes a resposta é "porque ninguém parou para questionar", e isso já é um sinal valioso.
03As 4 categorias de métrica
Toda dor mapeada precisa de uma métrica de resultado, algo que você conseguiria medir de novo daqui a seis meses para provar que melhorou. Só existem quatro categorias aceitas, e isso é de propósito: evita que a métrica vire enrolação.
- Tempo. Quantas horas por ciclo (dia, semana, mês) essa dor consome hoje, e quanto isso poderia cair. Exemplo de formato: "44 horas por mês reduzidas para 12 horas por mês".
- Custo. Quanto dinheiro se recupera ou deixa de se perder por mês, se a dor for resolvida. Exemplo de formato: "R$ X recuperados por mês".
- Qualidade ou erro. A taxa de retrabalho, de erro ou de reclamação hoje, e para onde ela poderia cair. Exemplo de formato: "5% de retrabalho caindo para menos de 1%".
- Risco evitado. Para dores de compliance, LGPD, segurança da informação ou regulação. Não force a conversão em reais quando o risco é difuso, meça o risco como risco mesmo. Áreas como jurídico e dados costumam ter mais dores desse tipo do que das outras três.
Saiba mais: os anti-padrões que fazem o mapeamento não valer nada
Quatro erros comuns invalidam um mapeamento de dores, mesmo quando ele parece completo no papel.
O primeiro é listar três dores em menos de dois minutos, sem nenhum detalhe. Isso costuma ser a primeira coisa que vem à cabeça, não a dor real. Se aconteceu com você, tente outra pergunta: em que dia da semana você abre o computador e pensa "que saco"?
O segundo é derrapar direto para a solução, tipo "queria um dashboard" ou "precisava de uma IA que...". Anote a ideia, mas volte: antes da solução, qual é a dor por trás dela?
O terceiro é usar métrica vaga, "mais rápido", "mais ágil", "melhor". Isso não é métrica, é adjetivo. Exija um número, mesmo que seja uma estimativa honesta.
O quarto é listar uma dor que você não teria como medir de novo daqui a seis meses. Se não dá para provar depois que melhorou, a dor não está pronta para entrar no mapa, precisa de mais uma pergunta antes.
04O que vem depois deste mapa
Este mapa não é o fim, é a porta de entrada. Com as dores nomeadas e cada uma com sua métrica, você tem o material bruto que as próximas aulas desta trilha vão usar para decidir onde a IA de fato ajuda, o que é só uma automação simples disfarçada de projeto de IA, e por onde começar quando várias dores competem pela sua atenção ao mesmo tempo. Sem esse mapa, cada decisão seguinte vira palpite. Com ele, vira leitura de dado.
Faça agora
Pegue uma folha, ou abra um documento novo, e faça o seu mapeamento de dores agora, a sua tarefa real ou qualquer outro contexto real do seu dia.
- Bloco A, 3 dores pessoais: liste as três atividades que mais te consomem tempo, te frustram ou você mais adia. Para cada uma, escreva a métrica de resultado (tempo, custo, qualidade ou risco) que você conseguiria medir de novo em seis meses.
- Bloco B, 3 dores da sua área: mesma estrutura, sem repetir nada do Bloco A. Pense em quem depende do seu trabalho e onde a dor dessa pessoa aparece.
- Bloco C, 1 atividade mais chata: a mais mecânica, repetitiva e sem decisão que você faz hoje. Escreva por que ela ainda existe desse jeito.
- Para cada uma das sete dores, escreva uma primeira ideia de solução, e seja honesto na natureza dela: é classificação, geração de texto, cálculo, ou automação de sistema? E, o mais importante, diga em voz alta se isso é realmente um problema de IA generativa, ou se é ETL, regra de negócio ou automação simples. As duas respostas são válidas, o que não vale é fingir que é IA quando não é.
Quando você termina esse mapa com número em cada linha, você sai de "a gente perde tempo com isso" para "isso custa 20 horas por mês, e dá para medir de novo em seis meses". É essa virada que abre a trilha de Estratégia.
Pratique
1. Por que o mapeamento de dores pede que você nomeie e meça a dor antes de pensar em solução?
2. Qual das opções abaixo é uma métrica de resultado válida, das quatro categorias aceitas no mapeamento?
3. Uma dor de compliance é difícil de converter em reais, porque o risco é difuso. O que o mapeamento recomenda nesse caso?
Para o quadro
Sobre o desabafoa gente perde tempo não é dor mapeada. Desabafo não vira prioridade, nem orçamento, nem projeto.
Sobre a ordemnomear e medir antes de pensar solução. Sem linha de base não existe antes e depois.
Sobre o que não se forçarisco difuso de compliance não vira reais no chute. Existe categoria própria de métrica para isso.
Valeu pelo feedback. Isso ajuda a afiar a próxima aula.