Por que o primeiro projeto de IA deve resolver uma dor só

A armadilha começa na reunião de escopo

A conversa costuma ir assim: a empresa decide que chegou a hora de levar IA a sério, convoca as áreas, e cada gestor traz uma dor. Atendimento lento. Relatórios que dependem de uma pessoa. Estoque que sempre surpreende. Proposta comercial que demora três dias.

Tudo real. Tudo legítimo.

O resultado é um projeto que quer resolver os quatro problemas ao mesmo tempo, com seis meses de prazo e um orçamento que parece alto até o dia em que acaba. Quando o prazo estoura, o que foi entregue raramente resolve qualquer dor por inteiro.

Escopo grande é o que torna projeto caro e lento. Essa frase parece óbvia, mas na maioria das conversas que temos com gestores de empresas médias, o erro já está feito antes de a primeira linha de código existir.

Uma dor resolvida por inteiro vale mais do que quatro dores tocadas pela metade

Pense numa tarefa concreta: a equipe de logística consolida relatórios de entrega todo dia de manhã. Duas pessoas, quarenta minutos cada, cinco dias por semana. São mais de seis horas de trabalho por semana dedicadas a juntar planilhas e conferir status em sistemas diferentes.

Esse número não precisa de pesquisa. Você refaz a conta com os seus dados em dois minutos.

Resolver essa dor por inteiro significa que, na segunda-feira seguinte à implantação, ninguém mais faz esse trabalho manualmente. O relatório aparece pronto, no horário, sem intervenção. As duas pessoas passam a manhã fazendo outra coisa.

Isso é valor que o time sente no primeiro dia. Não é promessa de resultado em seis meses.

Quando o projeto tenta resolver ao mesmo tempo o atendimento, o estoque e os relatórios, nenhuma das três frentes chega a esse ponto de conclusão. O time vive em piloto, validando, ajustando, e ninguém consegue dizer se alguma coisa funcionou de verdade.

Por que a empresa média cai nessa armadilha

Existe uma lógica por trás do escopo inflado, e ela não é burrice. É defesa.

Quando a empresa investe num projeto de tecnologia, há uma pressão natural para justificar o orçamento mostrando que muita coisa vai mudar. Um projeto pequeno parece pouco ambicioso. Parece que o valor não é proporcional ao esforço de aprovar o investimento.

O raciocínio inverte a causa e o efeito. O projeto que entrega uma coisa por inteiro gera confiança real. É com essa confiança que o próximo ciclo começa mais rápido, com menos resistência interna e com o aprendizado do ciclo anterior embutido.

O projeto que tenta fazer tudo não cria esse ativo. Ele cria reunião de revisão.

Como escolher a dor certa

A dor certa tem três características, e todas são práticas de identificar.

Primeira: ela é repetitiva. Acontece todo dia, toda semana, todo mês, com a mesma estrutura. Quanto mais previsível o trabalho, mais direto fica transformá-lo em algo que roda sozinho.

Segunda: o custo dela é visível. Horas de equipe, prazo que escorrega, cliente que espera. Se você consegue colocar a dor numa frase do tipo "isso consome X horas de Y pessoas Z vezes por semana", ela tem custo mensurável. Custo mensurável vira argumento de aprovação e, depois, prova de resultado.

Terceira: ela está contida. Significa que resolver essa dor não depende de reformar o processo inteiro da empresa. A dor tem entrada, processamento e saída definidos. O relatório de logística tem essa característica. A "experiência do cliente" não tem.

Na FM Solutions, quando chegamos a uma operação nova, pedimos ao gestor que liste as dez tarefas que mais tomam tempo da equipe. Depois pedimos que risque as que dependem de julgamento humano difícil de transferir. O que sobra é o ponto de partida.

O que "resolver por inteiro" significa na prática

Resolver por inteiro não é instalar uma ferramenta e torcer. É garantir que a tarefa deixou de existir no formato manual. A equipe não abre mais aquela planilha. Não manda mais aquele e-mail de cobrança de informação. Não confere mais aquele status um a um.

Isso exige três coisas: que o processo seja mapeado com honestidade, que as exceções sejam tratadas antes de ir ao ar, e que a equipe saiba exatamente o que mudou e o que ainda cabe a ela.

A terceira parte é frequentemente ignorada. Uma automação que a equipe não entende vira automação que a equipe contorna. O trabalho manual volta pela porta dos fundos.

O que fica para o próximo ciclo

Resolver uma dor por inteiro leva, na maioria dos casos, algumas semanas. Ao final, a empresa tem três coisas que não tinha antes: um processo a menos para gerenciar, uma equipe que viu a mudança funcionar de perto, e um orçamento que não foi todo embora de uma vez.

Esse é o momento de escolher a segunda dor. Com o aprendizado do primeiro ciclo, o segundo vai mais rápido. A equipe entra com menos ceticismo. O gestor entra com menos necessidade de justificar cada decisão.

A empresa que tenta construir tudo de uma vez raramente chega ao segundo projeto. Ficou travada tentando terminar o primeiro.

O que muda quando o escopo é honesto

Um projeto com escopo honesto tem prazo que o gestor consegue defender para o board. Tem critério de sucesso que qualquer pessoa da operação entende. Tem um momento claro em que dá para dizer "funcionou" ou "não funcionou".

Esse critério de sucesso é o que separa um investimento de uma aposta.

Na prática, a pergunta que fazemos antes de qualquer proposta é: qual é a tarefa que, se deixar de existir na segunda-feira de manhã, o time vai sentir no mesmo dia? Se o gestor consegue responder, temos um ponto de partida. Se a resposta for "várias coisas", o trabalho começa um passo antes: ajudar a escolher uma.