E se a solução que fez o cliente parar de reclamar for exatamente a que vai te explodir na cara daqui a seis meses?
Muitas decisões de produto que tomamos hoje voltam depois com outra roupa, de outro jeito — e você pode nunca perceber que aquela decisão é que virou um pesadelo mais para frente. Para ficar mais fácil de entender, vale contar a história de uma decisão pequena, óbvia, que qualquer um aprovaria em cinco minutos de reunião.
Ato 1 — a sala de reunião: o mapa de rastreio do entregador
Cena conhecida: o usuário está há 45 minutos esperando e não sabe se o pedido está chegando ou se nem saiu do restaurante. Essa ansiedade gera tickets de suporte (“cadê meu pedido?”), avaliações negativas e cancelamentos.
A queixa chega ao time como um problema para resolver — e rápido. Existe uma pressão por resultado de curto prazo; isso tem nome: short-termism, a pressão de mover o ponteiro neste trimestre. Não é privilégio da tecnologia: na medicina o incentivo também é aliviar o sintoma que o paciente sente hoje, não investigar a causa que demora.
Na ânsia de apagar o incêndio, o time não enxerga a causa real e foca no sintoma. Qual a decisão típica para baixar a ansiedade? Criar um mapinha mostrando onde está o pedido. Ver o entregador se movendo transforma incerteza em informação, e a ansiedade cai. As métricas de primeira ordem confirmam: menos contatos com o suporte, maior satisfação percebida no momento da espera. O ponteiro moveu. Comemoração no fim do trimestre.
Fim da história? Não. Se fosse, essa conversa não existiria.
Quando resolver o sintoma piora o problema
A história está cheia de soluções que pioraram aquilo que queriam resolver:
- Efeito cobra (Índia colonial): recompensa por cobra morta → as pessoas passam a criar cobras → o programa é cancelado → os criadores soltam as cobras → mais cobras do que no início.
- Mosquiteiros na África: as redes distribuídas contra a malária viram redes de pesca → colapso de estoques de peixe e inseticida na água.
O problema é ainda pior porque, quando as consequências chegam, já passou um tempo — e isso impede que as pessoas liguem o tico e o teco e percebam o que causou aquele efeito. Em pensamento sistêmico, isso tem nome: o efeito delay, o atraso entre causa e efeito.
Pense no cigarro. E se, na primeira tragada, a pessoa imediatamente precisasse de morfina? Ninguém acharia estiloso — todos veriam na hora que a decisão é pura idiotice. É justamente o atraso entre causa e efeito que faz uma decisão ruim parecer boa.
O problema de verdade não era a ansiedade
A ansiedade era sintoma. A causa real era a quebra de expectativa: foi prometido um prazo e ele não foi cumprido. O tempo de entrega fica variando — às vezes bate com o que foi prometido, às vezes não — e, muitas vezes, o aplicativo já vinha quebrando a confiança do usuário antes disso. O mapa não tocou em nada disso.
Seis meses depois de lançar o mapinha
O mapa resolveu algum desses problemas? Não. O que ele fez foi converter a ansiedade do cliente em vigilância sobre o entregador. Quem antes esperava sem informação agora assiste a cada decisão de rota, cada parada, cada desvio. A pausa no semáforo vira suspeita. A rota que o entregador conhece e o algoritmo não vira “ele está indo para o lado errado”. Sair para fazer outras entregas junto com a sua vira traição. A pressão, que antes se dissipava na tela parada, agora tem um alvo humano com nome e foto: o motoboy.
E o motoboy, submetido a uma hipervigilância que não escolheu e não controla, faz o que toda parte pressionada de um sistema faz: adapta-se pelo caminho de menor resistência.
- desliga o GPS em trechos do trajeto;
- marca “cheguei ao restaurante” antes de chegar, para ganhar folga no cronômetro;
- aceita o pedido e o deixa em espera estratégica;
- usa falsificadores de trajeto de GPS.
O mapa que existia para dar transparência passa a exibir dados encenados. O cliente percebe que o mapa não bate com a realidade, e a desconfiança volta — agora pior.
O que a teoria de sistemas já explica
Transferência de responsabilidade (Peter Senge). Havia duas escolhas: uma que atuava na causa raiz e outra que atacava só o sintoma. Atacar o sintoma é mais rápido, barato e rende no sprint review. Só que, além dos efeitos colaterais, ele gera outro problema: diminui a pressão para achar a solução do problema real. Vida que segue.
Efeito bexiga d'água. Quando você acha que resolveu um problema, mas na verdade criou outro. Você empurra a tensão num sistema, ela não desaparece — só muda de lugar. A tensão saiu do dashboard de reclamações e foi parar na rua: no trânsito, no corpo do motoboy, na relação com a plataforma. A equipe não resolveu; mudou o problema para um lugar onde ninguém está medindo.
E, por causa do delay, o dano vem depois — semanas ou meses. Enquanto isso, as métricas melhoram (caem os tickets por demora), os times comemoram e vão apagar incêndio em outra parte do produto. Quando os motoboys começam a “hackear” o sistema, ninguém lembra do mapa lançado meses antes. A leitura vira “os motoboys são picaretas”, e vem mais controle: punição por GPS desligado, detecção de falsificadores, score de confiabilidade do entregador. Aplica-se mais força, e o sistema devolve mais força — e ninguém relaciona isso com o mapa de rastreio incluído seis meses antes.
Débito técnico x débito ético
Isso é parente do débito técnico, mas se chama débito ético. No débito técnico, quem contrai a dívida é quem paga: o time toma o atalho hoje e faz o refactoring amanhã. No débito ético, quem contrai não é quem paga: a conta vai para alguém fora da empresa, que não assinou nada e não escolheu participar — o motoboy que assumiu o risco no trânsito, o cliente que virou fiscal sem pedir. E há uma diferença ainda mais séria: débito técnico se paga com refactoring; débito ético, muitas vezes, não se paga — não existe rollback de acidente, não existe hotfix de confiança destruída.
Então nunca mais podemos apagar incêndio?
Não é isso. Às vezes é necessário para ganhar tempo. Mas tem que vir acompanhado de algumas condições:
- Deixe claro que aquilo é uma saída emergencial e que a causa real é outra, que ainda precisa urgentemente de solução.
- Antes de lançar, pergunte: “se eu tirar essa tensão daqui, para onde ela vai?” No caso, a ansiedade do usuário foi parar na pressão sobre os motoboys. Toda tensão que sai de um lugar vai para outro — pergunte-se se o novo ponto aguenta.
- Tente enxergar o delay: monitore não só a métrica que o feature otimiza (optimization metric), mas também sinais de adaptação (guardrail metric: padrões anormais de GPS, tempo entre “cheguei” e a chegada real, reclamações de inconsistência do mapa). O sistema sempre avisa que alguém está pressionando de volta; o time só precisa estar medindo o lugar para onde a força foi.
- Procure antecipar efeitos perversos perguntando três vezes: e depois? e depois? e depois?
Moral da história
O mapinha que mostra o motoboy resolveu a ansiedade do cliente transferindo-a para o entregador — só que com juros. Ao mexer na tela, os times raramente eliminam a tensão ou os problemas: muitas vezes apenas mudam essa tensão de lugar. Um time de produto maduro não deixa a tensão cair em qualquer lugar por acaso — escolhe conscientemente onde ela vai morar e garante que esse lugar tenha estrutura para sustentá-la.