Coreografia: o backlog que se tria sozinho
A IA varre um volume de tickets que o time nunca cobriria à mão e acende os suspeitos: duplicado, severidade fora da curva, time errado na fila. Você continua sendo quem confirma o ambíguo e decide a ação.
Segunda de manhã, e a fila do Jira amanheceu com 340 tickets novos, entre bug, pedido de feature e reclamação de cliente reencaminhada pelo suporte. No meio deles, dois tickets abertos por canais diferentes descrevem o mesmo erro de checkout com palavras diferentes, um deles marcado como "baixa" porque quem abriu não sabia o tamanho do estrago. Ninguém vai ler as 340 descrições linha a linha antes do daily das 9h. A pergunta desta aula é: quem varre esse volume por você, e quem confirma o que aparecer antes de virar prioridade da semana?
O escritório recebe notificações e intimações de fontes diferentes toda semana, cada uma com prazo próprio. A IA agrupa as que parecem do mesmo processo, sugere severidade pelo tipo de peça e roteia pro advogado responsável. Ela marca como prazo "confortável" uma intimação cujo texto é denso e formal, sem perceber que o prazo processual real, contado a partir da data de publicação, vence em dois dias, não em duas semanas como o texto sugeria à primeira leitura. Confiar na severidade sugerida sem checar a data de publicação quase custou um prazo perdido.
A cada final de ciclo de avaliação, o RH recebe dezenas de solicitações: pedido de promoção, reclamação de clima, dúvida sobre benefício. A IA agrupa os pedidos parecidos, sugere prioridade pra cada um e roteia pro analista certo. Ela marca como "prioridade normal" uma reclamação de clima que menciona, de passagem, um comportamento de um gestor específico, porque o texto é educado e não usa palavra como "assédio" ou "abuso". Só que esse tipo de menção discreta é exatamente o que costuma anteceder uma denúncia formal semanas depois. Tratar como prioridade normal e deixar na fila comum quase deixou passar um sinal que devia ter ido direto pro time de compliance de pessoas.
O board de feedback de produto recebe centenas de pedidos por mês, vindos de suporte, de vendas e de pesquisa. A IA agrupa os pedidos parecidos, sugere qual dor é mais recorrente e propõe prioridade pro roadmap. Ela marca como baixa prioridade um pedido que aparece só três vezes no texto, porque volume baixo normalmente significa pouco impacto. Só que essas três menções vêm dos três maiores clientes da base, cada um valendo mais que cem clientes pequenos somados. A prioridade sugerida pela IA, olhando só volume de menção, quase escondeu o pedido que mais valia dinheiro.
Toda semana chegam dezenas de objeções e pedidos de desconto do time comercial pro time de pricing. A IA agrupa os pedidos parecidos, sugere qual objeção é padrão de mercado e qual foge da política, e roteia o que foge pra aprovação do gestor. Ela marca como "dentro da política" um pedido de desconto que, somado a uma cláusula escondida no contrato anterior do mesmo cliente, na verdade estoura o teto combinado no board. O texto do pedido, isolado, parecia normal; só cruzando com o histórico do cliente é que o problema aparece. A rota sugerida quase deixou passar um desconto que feria o acordo do trimestre.
O painel de incidentes operacionais recebe queixas de várias praças ao mesmo tempo: atraso de entrega, avaria, reclamação de motorista. A IA agrupa as queixas parecidas, sugere severidade e roteia pra praça responsável. Ela marca como severidade baixa um conjunto de queixas de atraso numa praça específica, porque cada queixa isolada parece um caso pontual de trânsito. Só que juntas, essas queixas apontam pra um problema estrutural no centro de distribuição daquela praça, que vai piorar se ninguém agir esta semana. Tratar cada queixa isolada como caso pontual quase escondeu um problema estrutural atrás do ruído do dia a dia.
O canal de denúncia interno recebe relatos de diferentes áreas o tempo todo, a maioria são dúvidas de processo, mas alguns são sérios. A IA agrupa os relatos parecidos, sugere severidade e roteia pro responsável certo. Ela marca como severidade baixa um relato que usa linguagem cautelosa e indireta, porque o texto não contém palavra de alarme. Só que relatos sérios de compliance costumam vir exatamente assim, cautelosos, porque quem denuncia tem medo de represália. A severidade sugerida pela IA, calibrada só pelo tom do texto, quase classificou como rotina o tipo de relato que mais precisa de atenção rápida.
A pesquisa de usabilidade gera dezenas de relatos de fricção toda semana, vindos de sessão gravada, de NPS e de ticket de suporte. A IA agrupa os relatos parecidos, sugere qual fricção é mais recorrente e roteia pro time de design responsável pela tela. Ela marca como baixa prioridade um conjunto de reclamações sobre o fluxo de cadastro, porque o volume absoluto é pequeno perto de outras filas. Só que esse fluxo específico é o primeiro contato de todo cliente novo, e cada abandono ali custa um cliente que nunca chega a conhecer o produto. A prioridade sugerida, olhando só volume, quase escondeu a fricção que mais custava receita.
Toda semana chegam dezenas de pedidos e sinais de mercado pro comitê de estratégia: um pedido de parceria aqui, uma menção de concorrente ali, um insight de analista acolá. A IA varre tudo, agrupa os pedidos parecidos, sugere qual merece atenção do board esta semana e qual pode esperar o próximo ciclo. Ela marca como "baixa urgência" um sinal de que um concorrente pequeno começou a copiar o seu posicionamento, porque o texto soa como ruído de mercado comum. Só que esse concorrente específico já converteu dois clientes seus no trimestre passado, um dado que só quem acompanha o funil de perto sabe cruzar. A rota sugerida pela IA quase enterrou o sinal certo debaixo do ruído.
Putz, quem já foi dono de uma fila de tickets sabe a sensação: a caixa de entrada nunca esvazia, e todo dia chega mais rápido do que qualquer time consegue ler. Então, na prática, o time faz o que dá: olha os tickets mais recentes, os que gritam mais alto, os que alguém cobrou no corredor. O resto fica na fila, esperando. Pensa comigo: e se desse pra varrer a fila inteira, e o time só precisasse olhar de perto os casos que realmente pedem julgamento? É exatamente essa a coreografia desta aula.
A ideia central desta aula. A IA não é quem decide o que importa no seu backlog. Ela é a primeira triagem: agrupa o que é duplicado, sugere a severidade e aponta pra qual time aquilo deveria ir, num volume que nenhum time cobriria lendo ticket por ticket. Mas confirmar a severidade real, resolver a disputa de quem é o dono do problema, e decidir a ação, isso continua sendo do time. E existe um custo real quando a sugestão erra: severidade errada vira prioridade errada, e rota errada vira confiança perdida entre times.
01O que a IA faz bem: dedupe, severidade sugerida, roteamento
Vamos chamar o boi pelo nome. O gargalo de qualquer backlog nunca foi falta de inteligência, foi volume. Ninguém tem tempo de ler 340 tickets linha a linha toda segunda, então sobra triagem por amostragem: os mais recentes, os mais barulhentos, os que alguém lembrou de cobrar.
A IA inverte essa conta. Você aponta ela pra fila inteira e pede pra fazer três coisas ao mesmo tempo:
- Dedupe. Achar os tickets que descrevem o mesmo problema, mesmo vindos de canais diferentes (um do Jira, um do Zendesk, um encaminhado do WhatsApp de suporte) e com palavras diferentes.
- Severidade sugerida. A partir do texto e do sistema mencionado, propor se aquilo parece crítico, alto, médio ou baixo, e explicar o porquê da sugestão.
- Roteamento. Apontar pra qual time aquele ticket deveria ir, pelo componente ou sistema que ele menciona.
O ganho real aqui é de alcance. Você sai de "olhamos os vinte tickets mais recentes" pra "passamos pelos 340, e temos uma lista curta de casos que precisam de olho humano". Beleza?
Como a triagem funciona, na prática:
02O que continua sendo do time: confirmar, resolver e decidir
Aqui está a parte que a IA não faz, e que é o coração da triagem. Ela agrupou, sugeriu severidade e apontou rota. E agora? Agora começa o trabalho do time, e ele é todo de julgamento.
- Confirmar o dedupe. Dois tickets podem parecer o mesmo problema no texto e serem, na prática, dois bugs diferentes que só aconteceram na mesma tela. Juntar errado esconde o segundo problema atrás do primeiro. Alguém do time precisa olhar de perto antes de fechar como duplicado.
- Confirmar a severidade real. A IA lê o texto e o sistema mencionado; ela não sabe o impacto de negócio por trás. Um relato educado e sem palavra de alarme pode ser o mais sério de todos, como o relato de segurança que "soa parecido com casos anteriores" e na verdade expõe dado de outro cliente. Só quem conhece o sistema e o cliente sabe pesar isso.
- Resolver a disputa de dono. Um ticket que menciona autenticação e pagamento ao mesmo tempo pode ser roteado pela IA pro time errado, porque o texto pesa mais pra um lado. Decidir de quem é o problema, quando dois times têm razão parcial, é conversa entre pessoas, não sugestão automática.
- Decidir a ação. Confirmado o caso, alguém escala, prioriza no próximo sprint, ou explica pro cliente. A IA não fecha ticket, não muda prioridade de produção sozinha. Quem decide, e responde pela decisão, é o time.
Repara no desenho: a IA reduz o seu campo de busca, ela não substitui o julgamento de quem conhece o sistema. Ela transforma "ler tudo" em "confirmar o que importa".
03O custo a nomear: severidade ou rota errada
Agora a parte que eu não posso deixar passar batido, porque é onde essa coreografia dá errado se aceita sem checar. A IA sugere, e nem toda sugestão está certa. Isso tem custo, e o custo tem duas caras.
A primeira cara é o ticket crítico rotulado como baixa prioridade. Aconteceu no exemplo da vulnerabilidade: uma severidade sugerida "média", aceita sem checar, deixa uma falha grave esperando na fila comum por dias, enquanto o problema real segue exposto. A segunda cara é o oposto: um alarme tratado como urgente que na verdade não era, consumindo o time errado às custas de uma prioridade real que ficou esperando.
Nenhuma das duas é culpa da ferramenta. É o custo de tratar a sugestão como veredito. Por isso a regra desta coreografia: o time confirma antes de qualquer severidade ou rota virar ação. A sugestão acende o candidato; confirmar é o que transforma candidato em prioridade de verdade.
Saiba mais: por que a severidade "soa" errada com mais frequência do que parece
A IA calibra severidade principalmente pelo tom e pelo vocabulário do texto: palavra de urgência, menção a sistema crítico, repetição de termo. O problema é que gente que abre ticket sério nem sempre escreve com urgência, às vezes escreve com cautela, principalmente quando o assunto é delicado (segurança, dado de cliente, um relato que a pessoa mesma não tem certeza do tamanho). E gente que abre ticket pequeno às vezes escreve em caixa alta. O resultado é que o texto engana em ambas as direções, pra cima e pra baixo. Isso não é motivo pra descartar a sugestão, é motivo pra saber onde ela costuma errar: severidade calibrada só por tom precisa de uma segunda leitura sempre que o assunto for sensível por natureza (segurança, dado pessoal, cliente grande), porque é ali que o texto cauteloso mais se parece com rotina.
04A coreografia, passo a passo
Junta tudo e vira um sistema simples, que roda toda virada de sprint ou até todo dia, dependendo do volume da sua fila.
- A IA tria. Você joga a fila inteira e pede dedupe, severidade sugerida com o motivo escrito, e rota sugerida pelo componente mencionado. Saída: uma lista curta de casos que precisam de olho humano, os outros seguem o fluxo padrão.
- O time confirma os ambíguos. Pega a lista curta e olha caso a caso: o dedupe está certo, a severidade bate com o impacto real, a rota é do time certo.
- O time decide a ação. Confirmado, o ticket vira prioridade de sprint, escalação, ou resposta pro cliente. A IA não fecha nada sozinha.
- O time registra o padrão. Toda vez que a sugestão errou (juntou o que não devia, subestimou severidade, rotou errado), isso vira uma nota pra calibrar a próxima triagem, o mesmo tipo de fonte da dívida técnica visível que você vai ver na próxima aula.
Repara que a IA aparece num passo só, no começo. Ela amplia o alcance de quem tria, ela não decide no lugar de quem conhece o sistema. Vamos?
05Onde isso se encaixa
Essa coreografia é a mesma lógica de portão de qualidade que você já viu na aula 6.1, só que aplicada à entrada do backlog, não à saída do código. Lá, o portão decidia o que passava antes do deploy; aqui, a confirmação humana decide o que vira prioridade antes de entrar no sprint. Mesmo princípio: a IA opera a esteira, o critério que decide continua sendo seu.
Faça agora
Pegue um lote real de tickets do seu backlog, a sua tarefa real ou os últimos 30 abertos na sua fila. Peça pra IA fazer a primeira varredura:
- Aponte possíveis duplicados entre eles.
- Sugira a severidade de cada um, com o motivo em uma linha.
- Sugira o time ou componente responsável por cada um.
Agora faça a sua parte, que é a que importa: pegue os cinco primeiros itens da lista e classifique cada um em rota certa, severidade certa, ou precisou de correção humana. Conte quantos precisaram de correção. Esse número é a sua calibragem: ele te mostra o quanto a triagem automática acerta de primeira, e por que a confirmação do time não é opcional.
Pratique
1. Na coreografia de triagem de backlog com IA, qual é o papel correto da IA?
2. A IA sugeriu severidade 'média' para um relato técnico de vulnerabilidade, mas ao investigar o time descobre que ela expõe dado de outro cliente. O que isso mostra?
3. Por que a coreografia de triagem de backlog se parece com o portão de qualidade da aula 6.1?
Para o quadro
Sobre a filasem varredura o time olha o que chegou por último e o que gritou mais alto. O resto espera no escuro.
Sobre o papel da IAela passa por toda a fila e devolve lista curta com sugestão e motivo, pronta para confirmação.
Sobre severidadecalibrada por tom de texto ela engana nas duas direções. Assunto sensível pede sempre segunda leitura.
Valeu pelo feedback. Isso ajuda a afiar a próxima aula.