Ideia principal

O reflexo diante de cem tickets é reler tudo e reclassificar tudo. O trabalho é enorme e não corrige nada.

Um método mais eficaz entra pelo lado oposto. Toda semana, o suporte lista os três retornos de clientes mais frequentes ligados a defeitos. Esse top 3 vira o top 3 a tratar. Na semana seguinte, conforme o que foi tratado, o suporte propõe os próximos.

A gente avança por Pareto: o que mais volta, o que mais dói, o que mais carrega o suporte. O efeito é duplo — a dor visível do cliente cai, e o suporte desafoga. O suporte vê que seus retornos servem para alguma coisa, os desenvolvedores não se dispersam numa lista abstrata, a diretoria vê irritantes desaparecerem.

Por que isso importa

A seleção não sai do estoque, vem de um fluxo externo que se renova sozinho. Ou seja, a gente não paga a manutenção do estoque para decidir o que corrigir.

Ela também coloca a decisão com quem absorve a dor, em vez de num comitê que a reconstrói a partir de tickets.

Nuances e limites

A classificação só enxerga o que chega. Um defeito grave e silencioso — corrupção de dados, falha de segurança, cálculo errado nunca verificado — nunca vai aparecer num top 3 do suporte.

Questões em aberto

• Que segundo fluxo cobre os defeitos que o suporte nunca vê?