Pedidos duplicados: mesclar sem perder a voz original
6 min de leitura
Três clientas pedem a mesma capacidade em três semanas diferentes, redigida de três jeitos diferentes, e um processo de triagem construído para pegar duplicatas faz o trabalho dele: agrupa elas, conta como um pedido só com três votos, e o backlog fica limpo. Essa é a parte fácil. Quais etiquetas valem a pena cobre agrupar por capacidade subjacente antes de triar por redação como o conserto mecânico para duplicatas; o que não cobre é o que acontece com as palavras em si quando três pedidos viram uma linha só, e essa perda geralmente é maior do que o problema de contagem de duplicatas que ela resolveu.
O que realmente se perde quando duplicatas são mescladas?
A redação específica que cada solicitante usou, que costuma ser mais informativa do que a contagem de votos na qual ela colapsa. Uma clienta pode pedir “uma forma de exportar resultados filtrados”, outra “exportação CSV que respeite meus filtros salvos”, e uma terceira “exportação que não inclua colunas ocultas”. As três são o mesmo pedido subjacente, corretamente agrupado, mas cada redação carrega uma ênfase levemente diferente sobre o que importa para aquela pessoa, e uma mesclagem que mantém só a redação da primeira submissão descarta as outras duas por completo. A contagem sobrevive; a textura que ajudaria alguém a construir a versão certa da funcionalidade, não.
Por que a textura importa se a contagem de votos já diz que existe demanda?
Porque demanda e design são perguntas diferentes, e só a redação específica responde a segunda. Dez votos em “exportação” diz a um time que vale a pena construir a funcionalidade; não diz nada sobre se “exportação” significa CSV, PDF, um email agendado ou um endpoint de API, e uma mesclagem que descarta nove das dez submissões originais em favor da redação da primeira pode estreitar silenciosamente a especificação para o que quer que a primeira solicitante tenha pedido por acaso, mesmo que as outras nove quisessem algo sutilmente diferente. O que um pedido de funcionalidade deveria realmente registrar cobre exatamente essa lacuna do lado da recepção; mesclar duplicatas é onde ela reaparece depois da recepção, exatamente no ponto onde um time mais precisa do alcance do que foi realmente pedido.
Como é um processo de mesclagem que mantém a redação em vez de descartá-la?
Adicionar em vez de substituir. O item canônico mantém um título único para a visão do backlog, mas a redação original de cada submissão mesclada continua anexada a ele, seja como uma lista de citações ou como tickets de origem linkados, para que qualquer um que revise o item depois consiga ver o alcance real do que as pessoas pediram em vez do resumo de uma pessoa do time. Isso custa quase nada para construir, um campo no ticket em vez de um sistema novo, e é a diferença entre uma mesclagem que comprime informação e uma que só comprime a exibição dela.
Funcionalidade: Exportação CSV filtrada
Votos: 12
Pedidos mesclados:
- "uma forma de exportar resultados filtrados" (acct_4421)
- "exportação CSV que respeite meus filtros salvos" (acct_8832)
- "exportação que não inclua colunas ocultas" (acct_1097)
...Toda duplicata merece ser mesclada, ou existem correspondências falsas?
Algumas são correspondências falsas, e tratar “soa parecido” como “é o mesmo pedido” é seu próprio modo de falha. “Me deixem exportar meus dados” e “me deixem exportar só a visão filtrada” podem ser agrupados por uma correspondência de palavra-chave em “exportar” enquanto na verdade descrevem dois escopos diferentes da mesma capacidade geral; mesclar eles ou infla a contagem de votos para a coisa errada ou, pior, lança a versão mais estreita porque ela chegou primeiro por acaso. Uma passada humana sobre o agrupamento, mesmo rápida, pega isso antes de acumular; uma correspondência automática de similaridade sozinha vai mesclar demais por vocabulário e mesclar de menos por intenção.
Quando a checagem de duplicatas deveria realmente rodar, na recepção ou depois?
As duas, por razões diferentes. Checar na recepção pega o caso óbvio, um pedido novo que reafirma algo que já está aberto, antes que ele vire um item não rastreado com vida própria; uma busca por similaridade contra os pedidos abertos no momento do envio resolve a maioria desses casos sem ninguém do time envolvido. Uma segunda passada depois, num ritmo mais lento, pega o caso que a recepção não vê: dois pedidos que usaram uma linguagem diferente o suficiente para escapar de uma correspondência por palavra-chave ou embedding na hora, mas que, depois que o time já viu uma dúzia de variações, se revelam a mesma capacidade de fundo. Pular a segunda passada deixa quase-duplicatas espalhadas sob títulos separados indefinidamente, cada uma com a própria contagem pequena de votos que nunca soma o número que teria feito a funcionalidade ser construída.
A solicitante deveria saber que a submissão dela foi mesclada em um item existente?
Sim, e essa é a mesma disciplina de fechar o loop de feedback do cliente aplicada um passo antes do normal: uma solicitante que enviou algo e nunca mais ouve nada conclui que o pedido dela não foi a lugar nenhum, mesmo que tenha sido corretamente mesclado em um item com outros onze votos que acabou sendo lançado. Uma confirmação curta, “combinamos isso com um pedido existente que outras pessoas também fizeram”, custa uma mensagem e evita que uma clienta reenvie o mesmo pedido a cada poucos meses porque não tem visibilidade se ele foi de fato rastreado alguma vez.
Mesclar muda quem recebe crédito quando a funcionalidade é lançada?
Deveria incluir todo mundo, não só quem enviou primeiro. Fechar o loop de feedback cobre avisar solicitantes quando o pedido delas é lançado; para um item mesclado isso significa cada conta anexada à mesclagem, não só aquela cuja redação virou o título canônico, porque do ponto de vista de cada solicitante ela pediu isso e foi lançado, não importa a redação de quem um processo de triagem por acaso manteve. Com o Changeloop, isso significa que o pull request nomeia cada issue vinculada (Fixes #142, fixes #187); uma issue que ele não nomeia não recebe comentário.
FAQ
Quanta redação vale a pena manter por pedido mesclado, uma citação ou um link completo do ticket? Uma citação curta geralmente basta para o caso comum, já que o propósito dela é deixar uma revisora ver o alcance das redações de relance; mantenham o link completo do ticket também quando o original tinha contexto extra significativo, como uma captura de tela ou uma descrição detalhada de fluxo de trabalho que uma citação de uma linha achataria.
Manter a redação de cada duplicata torna o backlog mais difícil de escanear? Não, se estiver recolhida por padrão. O título canônico é o que uma revisora escaneando rapidamente vê; a redação mesclada está a um clique ou uma expansão de distância, presente para quem faz pesquisa mais profunda mas sem sobrecarregar a visão de quem só está contando votos.
E se dois pedidos parecem idênticos mas acabam querendo coisas diferentes depois de construídos? Separem eles de novo assim que isso ficar claro, e tratem a mesclagem original como uma decisão razoável tomada com a informação disponível na época, não como um erro cuja repetição deve ser evitada. Um sistema de agrupamento que nunca desfaz mesclagens vai acabar tendo algumas mesclagens erradas permanentemente cozidas.
Existe um limite de votos a partir do qual um pedido mesclado deveria receber uma revisão humana da redação subjacente? Não um número fixo, mas qualquer pedido chegando perto de uma decisão de construção merece isso independente da contagem de votos, porque esse é o ponto onde a diferença entre “exportação” e “exportação como CSV com filtros salvos” para de ser uma nuance e começa a ser a especificação.
As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.