Como rastrear pedidos de funcionalidades sem perdê-los
6 min de leitura
O rastreamento de pedidos de funcionalidades falha quase sempre de uma de duas formas. Ou os pedidos não têm para onde ir, então vivem em caixas de entrada e threads do Slack onde são esquecidos um por um, ou têm um lugar para ir que ninguém revisita, então são esquecidos todos de uma vez. Um sistema que funciona precisa resistir às duas falhas: precisa de um único lugar onde cada pedido pousa, e de um motivo para abrir esse lugar de novo no mês que vem.
De onde os pedidos de funcionalidades realmente vêm?
De mais canais do que a maioria dos sistemas de rastreamento contempla. Um ticket de suporte que inclui um “seria legal se”. Um comentário em um roadmap público. Uma ligação de vendas em que uma cliente em potencial nomeia a única coisa que está bloqueando o negócio. Um widget dentro do produto. Cada canal tem sua própria dona e suas próprias ferramentas, e é exatamente por isso que os pedidos se espalham: a fila de tickets de suporte e o backlog do time de produto raramente são o mesmo sistema, e um pedido que chega a apenas um dos dois, na prática, só chegou a um departamento.
| Origem | Dona típica | Onde mais costuma sumir |
|---|---|---|
| Tickets de suporte | Time de suporte | Fechado como resolvido, nunca mais revisitado |
| Ligações de vendas | Vendas / gestão de contas | Um campo do CRM que ninguém no produto lê |
| Widget no produto | Produto | Um formulário enviado sem follow-up |
| Comentários no roadmap | Quem quer que tenha construído o roadmap | A própria thread de comentários |
| Redes sociais / reviews | Marketing ou ninguém | Capturado uma vez em print, depois some |
Um único formulário de entrada para cada canal não funciona, porque ninguém vai adotá-lo. O que funciona é um destino para onde cada canal converge, mesmo que o roteamento no início sejam cinco minutos por dia de copiar e colar até ser automatizado.
O que realmente quebra o rastreamento de pedidos de funcionalidades?
Quase sempre duas coisas. A primeira é a falta de um destino: os pedidos recebem resposta no canal em que chegaram e nunca são registrados de forma durável em lugar nenhum, então o mesmo pedido vindo de três clientes diferentes parece três respostas isoladas e sem relação, em vez de um único sinal. A segunda, mais comum, é um destino que enche e para de ser lido. Uma planilha com 400 linhas sem filtro não é mais um sistema de rastreamento; é um arquivo que por acaso pode ser editado.
A segunda falha é a mais perigosa, porque parece que o rastreamento está funcionando. Os pedidos são registrados. Nada parece quebrado até alguém perguntar “quantas pessoas pediram X” e a resposta honesta ser “teríamos que ler todas as 400 linhas para saber”.
O que um pedido de funcionalidade deveria realmente registrar?
O suficiente para responder três perguntas depois sem reler a mensagem original: o que foi pedido, se possível nas próprias palavras de quem pediu; quem pediu, e como contatá-la se a resposta acabar sendo “nós construímos”; e o que seria preciso para saber se é um pedido comum ou um caso isolado. Uma citação literal vale mais que uma paráfrase, porque uma paráfrase escrita por quem triou o pedido já carrega sua própria leitura, e é exatamente essa leitura que uma segunda pessoa não consegue verificar seis meses depois.
Quais etiquetas valem a pena?
Duas, e respondem perguntas diferentes. Uma etiqueta de tipo separa um pedido de funcionalidade de um relatório de bug, porque os dois precisam de donas e prazos diferentes, e misturá-los em uma única fila deixa as reclamações mais barulhentas passarem na frente dos pedidos. Uma etiqueta de prioridade, mantida em um conjunto pequeno como low, medium e high, separa “está bloqueando alguém de usar o produto” de “seria legal ter”, porque as duas merecem tempos de resposta bem diferentes e nenhuma deveria herdar o ritmo da outra. Colocar certo a etiqueta de tipo assume que o pedido é o que ele diz ser; quando um pedido de funcionalidade é na verdade um bug cobre o caso em que as próprias palavras de uma cliente apontam essa etiqueta na direção errada.
A triagem automatizada pode aplicar as duas no momento em que o pedido chega. No changeloop, um
envio pelo widget recebe a etiqueta feature-request ou bug e uma etiqueta
priority:low|medium|high no mesmo passo, mais uma tag from-widget para que a origem fique
visível sem abrir o item. Isso já basta para filtrar o backlog em um minuto em vez de uma tarde:
me mostre cada pedido de funcionalidade de alta prioridade vindo do widget este mês.
Uma terceira etiqueta vale a pena assim que existe um roadmap público: um status que quem pediu consegue conferir sozinha. Roadmap público cobre por completo os status planned, building e shipped; resumindo, essa etiqueta transforma uma fila privada em algo que quem pediu pode consultar sem perguntar de novo.
Como se decide o que construir a seguir?
Agrupe antes de contar. Dez pedidos formulados de formas diferentes para a mesma capacidade subjacente se leem como dez linhas espalhadas em uma planilha, e como um sinal forte assim que agrupados, e esse agrupamento geralmente é o passo que falta, não a contagem. Um número bruto sem agrupamento tende a premiar a funcionalidade com o nome mais chamativo, não a que tem a maior demanda real por trás.
Pese por quem pede, não só por quantos pedem. Um pedido vindo de uma conta perto da renovação carrega uma urgência diferente do mesmo pedido vindo de um cadastro de teste, e um sistema de rastreamento que descarta esse contexto em favor de uma contagem nua está otimizando pelo número mais fácil de calcular, não pelo mais útil.
Cada decisão aqui também produz pedidos que perdem, e eles também merecem uma resposta; como recusar um pedido de funcionalidade cobre o que dizer a quem fez um pedido que não vingou. Agrupar e ponderar é só metade de “o que construir a seguir”; priorizar pedidos de funcionalidades cobre os frameworks de verdade, RICE, ponderação por receita e contagens brutas, e onde cada um falha.
Como se fecha o ciclo quando algo é lançado?
Esse é o passo que os sistemas de rastreamento mais deixam passar, e o que quem pediu realmente percebe. Fechando o ciclo de feedback com o cliente cobre a mecânica por completo; o que se aplica aqui é que fechar o ciclo só funciona se o pedido original continuar ligado a quem o fez. Um template de pedido de funcionalidade construído a partir de uma issue do GitHub, com a identidade de quem pediu presa à issue em vez de enterrada em um comentário, é o que torna possível uma notificação automática de “lançado” em vez de uma que alguém precisa se lembrar de enviar. Template de pedido de funcionalidade mostra o template concreto e para que serve cada campo.
FAQ
Qual ferramenta devo usar para rastrear pedidos de funcionalidades? O que o time já confere diariamente vence qualquer ferramenta dedicada que ninguém abre. Um tracker de issues do GitHub funciona bem se a engenharia já vive lá; um quadro leve funciona bem se o produto vive lá. A ferramenta importa menos do que se ela é reaberta.
Como evito que pedidos de funcionalidades se dupliquem? Agrupe por capacidade subjacente antes de triar por redação. Uma busca entre os pedidos existentes antes de criar um novo pega a maioria das duplicatas; uma passada mensal de agrupamento pega o resto. Mesclar duplicatas sem perder a voz original cobre o que fazer com a redação assim que o agrupamento em si estiver pronto, para que a mesclagem não estreite silenciosamente o pedido para o que quer que a submissão que chegou primeiro tenha pedido.
Todo pedido de funcionalidade deveria receber uma resposta? Todo pedido deveria receber uma confirmação, mesmo curta, mas nem todo precisa de uma decisão na hora. Um status visível, como uma etiqueta de roadmap que quem pediu pode conferir sozinha, substitui a maioria das respostas individuais que um time teria que dar de outra forma.
Qual é a diferença entre rastreamento de pedidos e um roadmap público? Rastreamento é o registro interno de todo pedido, incluindo os que nunca serão lançados. Um roadmap público é o subconjunto ao qual um time se compromete publicamente, com um status que quem pediu pode ver sem perguntar de novo.
As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.