Devo começar pelo processo que mais incomoda?

Nem sempre. Incômodo é sinal de atenção, não de retorno. Uma tarefa irritante executada duas vezes por mês economiza pouco, enquanto uma tarefa monótona repetida centenas de vezes costuma render muito mais.

Como estimo o esforço sem ser desenvolvedor?

Use proxies observáveis: quantos sistemas diferentes a tarefa toca, quantas regras de exceção existem, se depende de integração externa e se o dado de entrada é estruturado. Cada um desses fatores aumenta o esforço de forma previsível.

Vale automatizar algo que ainda vai mudar?

Em geral não. Regra instável gera manutenção contínua e o ganho é consumido pelo custo de acompanhar a mudança. Estabilize a regra primeiro; automatize depois.

Como priorizar o que automatizar primeiro

Você prioriza automação com uma conta simples: frequência × tempo economizado por execução, dividido pelo esforço de construir e manter. É essa razão, e não o nível de irritação que a tarefa provoca, que decide o que entra primeiro.

O erro mais comum de priorização é escolher pelo incômodo. A tarefa que todo mundo odeia costuma ser rara e complexa; a que ninguém menciona costuma ser repetitiva e simples, e é ela que paga o projeto.

A conta que define a fila

Para cada candidato, levante quatro números:

Fator	Como levantar	Cuidado
Frequência	Execuções por mês, contadas em registro real	Estimativa de memória erra por fator de dois
Tempo por execução	Cronometrado, incluindo idas e voltas	Some interrupções e conferências
Taxa de erro	Casos que voltam ou geram correção	Erro custa mais que tempo, considere separado
Esforço	Faixa: baixo, médio, alto	Inclua manutenção, não só construção

O ganho mensal bruto é frequência × tempo × custo da hora. A esse número, some o custo do erro evitado, que em processos com multa, retrabalho de cliente ou perda de venda costuma ser maior que o tempo.

Um exemplo que ilustra a inversão de intuição:

Tarefa A: conciliação manual complexa, 4 horas, 1 vez por mês → 4 h/mês
Tarefa B: copiar dados de um sistema para outro, 6 minutos, 120 vezes por mês → 12 h/mês

A tarefa A é a que todos citam na reunião. A B rende o triplo e costuma exigir menos esforço técnico.

A matriz esforço × impacto, usada com honestidade

A matriz clássica separa quatro quadrantes:

	Esforço baixo	Esforço alto
Impacto alto	Fazer primeiro	Planejar e quebrar em partes
Impacto baixo	Fazer se sobrar tempo	Não fazer

Ela só funciona se os dois eixos vierem de dado, não de opinião. Duas correções que a tornam útil:

Impacto medido em horas e reais, não em percepção. "Impacto alto" precisa de número: quantas horas por mês, quanto de retrabalho evitado, quanto de prazo reduzido.

Esforço com manutenção incluída. Uma automação que depende de integração com sistema de terceiro tem custo recorrente: cada mudança na outra ponta quebra a sua. Esse custo entra no eixo de esforço.

O quadrante mais perigoso é o de alto impacto e alto esforço. Ele atrai porque a promessa é grande, e consome o projeto inteiro antes de entregar qualquer resultado. A saída é quebrá-lo: existe um pedaço de 20% do esforço que entrega 50% do impacto? Quase sempre existe.

Os critérios de desempate que mais valem

Quando dois candidatos empatam na conta, quatro critérios decidem:

Estabilidade da regra. Regra que mudou duas vezes no último ano vai mudar de novo. Automatizar instabilidade é comprar manutenção.
Estrutura do dado de entrada. Dado que já chega em formato previsível é barato de automatizar. Dado que chega em PDF escaneado, e-mail livre ou foto de WhatsApp multiplica o esforço.
Posição no fluxo. Automatizar antes do gargalo aumenta a fila e não muda a saída. Prefira o que está no gargalo ou o que reduz a entrada de erro nele.
Reversibilidade. Se der errado, dá para voltar ao método anterior sem parar a operação? Comece pelos reversíveis.

O terceiro critério vem direto da teoria das restrições e é o mais esquecido em backlog de automação. Antes de aprovar um item, pergunte quantos casos a mais saem por dia se aquela etapa ficar duas vezes mais rápida. Se a resposta for "nenhum", o item pode esperar.

O que não automatizar

Alguns candidatos parecem bons e não são:

Tarefa que deveria deixar de existir. Conferência que só existe porque a etapa anterior falha: corrija a etapa anterior.
Processo que ninguém entende inteiro. Automação sobre processo obscuro esconde o problema em código.
Volume baixo com muita exceção. Cinco casos por mês, cada um diferente. O tempo de manter as regras supera o tempo economizado.
Julgamento especializado. Onde o valor está na avaliação humana, automatize o entorno, coleta, registro, notificação, e deixe a decisão com a pessoa.

Um roteiro de meia hora para montar a fila

Com o processo já mapeado, a priorização é rápida:

Liste as tarefas repetitivas do fluxo, uma por linha
Anote frequência mensal e tempo médio, com dado de pelo menos dez execuções
Calcule horas por mês e ordene de forma decrescente
Classifique o esforço em três faixas, com base nos sistemas envolvidos e nas exceções
Marque quais estão no gargalo
Escolha entre as três primeiras da lista uma que seja de esforço baixo e esteja no gargalo

A sexta linha é a decisão. Se nenhuma atender aos três critérios, prefira esforço baixo com ganho médio a esforço alto com ganho alto, o primeiro resultado precisa chegar rápido para sustentar o resto do projeto.

É a lógica que usamos na Retti Tech para definir a primeira entrega de qualquer sistema: pequena, no gargalo, com ganho mensurável em semanas. O projeto grande continua existindo, mas ele passa a ser financiado por resultado, não por expectativa.

O primeiro item certo importa mais do que a lista completa

Não gaste um mês construindo backlog perfeito. Levante dez candidatos, calcule a conta para todos e escolha um. O que a primeira automação ensina sobre a operação vai reordenar a lista de qualquer jeito.