Fechar o ciclo de feedback pelo changelog

Um ciclo de feedback do cliente é fechado quando a pessoa que deu o feedback recebe a informação do que aconteceu com ele. Não quando é registrado. Não quando é priorizado. Nem quando é lançado. Quando é dito a ela. A maioria das equipes faz bem os três primeiros passos e o último nem um pouco, e depois se pergunta por que as pessoas que mandam feedback param de mandar.

Este artigo trata desse último passo, e de uma afirmação concreta: o changelog é o lugar certo para fechar o ciclo, porque é o único artefato que já existe exatamente no momento em que o ciclo pode ser fechado.

O que é um ciclo de feedback do cliente?

Um ciclo de feedback do cliente é o caminho de uma usuária dizendo algo a vocês até essa usuária descobrir o que vocês fizeram a respeito. Tem quatro passos: coletar o feedback, decidir o que fazer com ele, lançar o resultado, e avisar a pessoa que pediu. O ciclo está aberto até o quarto passo acontecer. Uma equipe que coleta feedback e lança correções mas nunca avisa ninguém tem uma caixa de entrada, não um ciclo.

A quarta linha é sobre o que este artigo trata. Ela quebra por uma razão estrutural, não cultural: no momento em que um recurso é lançado, o pedido que o causou vive em um sistema diferente da coisa lançada, e não é trabalho de ninguém conectá-los. O ciclo começa antes, com a forma como o pedido é feito logo de início; como pedir feedback aos clientes trata da redação e do momento certo.

Por que ciclos de feedback ficam abertos?

Ciclos de feedback ficam abertos porque o pedido e a mudança lançada vivem em lugares diferentes e o link entre os dois é feito manualmente, quando é feito. O pedido está em uma ferramenta de feedback, uma caixa de suporte ou uma planilha. A mudança está em um pull request. O anúncio está em um changelog ou um e-mail. Três sistemas, três donos, e o link do terceiro de volta ao primeiro é uma pessoa se lembrando, meses depois, quem pediu.

Há uma segunda razão. O passo de avisar geralmente é enquadrado como uma tarefa de marketing (“anunciar o recurso”) em vez de uma tarefa de suporte (“responder à pessoa”). Anúncios vão para todo mundo e não alcançam ninguém em particular. A pessoa que pediu o recurso em março lê o anúncio em junho, se ler, como notícia, não como resposta. O ciclo só fecha se a mensagem for direcionada a ela.

Por que fechar o ciclo pelo changelog?

Porque a entrada de changelog é o único artefato que existe exatamente no momento certo, contém exatamente as palavras certas, e é escrita exatamente pela pessoa certa. Ela existe quando a mudança está no ar e não antes. Ela diz o que mudou nos termos da leitora, que é a mensagem de que a pessoa que pediu precisa. E é escrita por alguém que acabou de ler o pull request, que é o único momento em que o link para o pedido original ainda está visível.

Compare as alternativas. Fechar o ciclo pela ferramenta de feedback significa que a ferramenta de feedback precisa saber quando o recurso foi lançado, o que significa que alguém atualiza um status manualmente. Fechá-lo pelo pull request significa avisar a cliente no merge, antes que a mudança esteja no ar, uma promessa quebrada com carimbo de tempo assim que o deploy atrasa. Fechá-lo pelo anúncio de marketing significa esperar por um, e a maioria das mudanças lançadas nunca recebe um.

O changelog fica no meio: depois do merge, no momento do lançamento, com a formulação pronta.

Como o ciclo fecha, passo a passo

Este é o mecanismo que rodamos. É descrito aqui como uma especificação em vez de um tour de produto, porque cada passo pode ser feito manualmente ou com outras ferramentas; o que importa é a ordem.

1. O feedback vira uma issue no repositório que vai corrigi-lo. Um envio de widget é registrado como uma issue etiquetada no GitHub (feature-request ou bug, uma prioridade, e from-widget), com o endereço de e-mail de quem enviou mantido fora do corpo da issue. A issue vive junto do código, para que o passo três possa encontrá-la. Uma issue aberta manualmente, por exemplo a partir de um template de solicitação de recurso, fica fora desse caminho: o passo cinco não comenta nela, então feche esse ciclo você mesmo.
2. A correção referencia a issue. O pull request diz Fixes #142, a própria palavra-chave de fechamento do GitHub. Nada novo para aprender, e é a mesma frase que desenvolvedores já escrevem.
3. A entrada de changelog é redigida a partir do pull request mergeado e carrega o link. No merge, o rascunho é criado e #142 é lido do corpo da PR e anexado ao rascunho. O link é criado enquanto ainda é barato, por uma máquina, a partir de dados que já estão lá.
4. Uma pessoa revisa a entrada. Formulação, público, se deveria ser publicada. Um rascunho descartado não fecha nada, o que é correto: um refactor interno que por acaso referenciou uma issue não é notícia.
5. Na aprovação, quem pediu é avisado. Um comentário é publicado na issue em que o feedback dessa pessoa se transformou, “Shipped —” seguido do título da entrada e um link para a entrada publicada, e o widget mostra a quem enviou a mesma entrada lançada. Uma vez, nunca duas, e só depois que uma pessoa publicou a entrada. A mesma entrada sai por feed e widget para todo mundo que não pediu.

A ordem no passo cinco é todo o design. Avisar quem pediu no merge seria mais cedo e mais fácil, e estaria errado aproximadamente tão frequentemente quanto deploys atrasam. Um feature flag quebra até essa ordem, porque aprovado e publicado pode acontecer enquanto a funcionalidade ainda está invisível para a conta de quem pediu; feature flags e pedidos de funcionalidades cobre a verificação extra que esse passo precisa assim que um flag entra em cena.

Como um ciclo fechado parece para a cliente?

Parece uma resposta. A cliente mandou um pedido por um widget, e um dia o widget o mostra como lançado, com link para uma entrada que o descreve nos termos dela; no GitHub, a issue recebe a mesma notícia como comentário. Ela não assinou uma newsletter, não checou um roadmap, não procurou no changelog. Foi dito a ela.

Essa é a experiência que faz o próximo pedaço de feedback acontecer. Pessoas mandam feedback para produtos que respondem. A página exemplos de changelog inclui entradas de equipes cujos usuários visivelmente continuam voltando com pedidos, e o fio comum não é a ferramenta; é que as entradas se leem como respostas.

Como se mede um ciclo de feedback?

Meça a fração de mudanças lançadas que avisaram pelo menos uma pessoa que pediu, e o tempo entre o lançamento e o aviso. Dois números, ambos fáceis assim que o link existe e impossíveis antes.

• Taxa de fechamento: das entradas de changelog publicadas neste mês, quantas linkaram pelo menos um pedido, e dessas, quantas avisaram quem pediu. Se o segundo número for muito menor que o primeiro, notificações estão falhando; se o primeiro for baixo, pedidos não estão sendo referenciados a partir de pull requests, e a correção é uma frase no template de PR.
• Tempo de lançamento até aviso: quanto tempo entre a entrada ir ao ar e o aviso a quem pediu. Com o mecanismo acima são segundos. Manualmente são tipicamente semanas, ou nunca, e “nunca” é o número que importa.

Não meça o ciclo pelo volume de feedback coletado. Coletar é o passo fácil, e uma equipe que o mede vai otimizá-lo, o que produz mais ciclos abertos.

Onde o roadmap se encaixa?

Um roadmap público é uma forma de fechar o ciclo cedo: diz a quem pediu que o pedido foi ouvido, antes de ser lançado. É útil, e não substitui o último passo. “Planejado” é uma promessa sobre o futuro; “Lançado” é um fato sobre o presente. Rode o roadmap público a partir das mesmas issues, com uma etiqueta por coluna, para que o mesmo pedido se mova de planejado para lançado sem ser reinserido em lugar nenhum. A mudança para lançado é uma troca de etiqueta (roadmap:shipped) que ninguém faz por você quando a entrada é aprovada, então faça isso na mesma revisão.

FAQ

Quais são os quatro passos de um ciclo de feedback do cliente? Coletar, decidir, lançar, avisar. O ciclo está aberto até o quarto passo acontecer. A maioria dos frameworks adiciona passos de análise e priorização no meio; são refinamentos de “decidir”, e nenhum deles fecha nada.

Deveria-se avisar clientes quando um pedido é rejeitado? Sim, e é a mensagem mais negligenciada do ciclo. Um claro “não vamos fazer isso, e aqui está o motivo” encerra a espera. Silêncio deixa o ciclo aberto para sempre e a cliente conferindo.

Como fechar o ciclo difere de anunciar um recurso? Um anúncio vai para todo mundo. Fechar o ciclo é uma resposta às pessoas que pediram, no canal por onde pediram. Faça ambos; são mensagens diferentes para leitoras diferentes.

E se quem pediu não está no GitHub? A maioria não está, e tudo bem. O widget continua mostrando a essas pessoas o status do que enviaram, incluindo a entrada lançada e o link dela, então elas não precisam de nada além da página de onde escreveram. O comentário na issue é para quem consegue ver o repositório.

Esse ciclo funciona no GitLab ou no Bitbucket em vez do GitHub? O widget e o changelog funcionam; o comentário automático do quinto passo não, hoje. Um time no GitLab ou no Bitbucket ainda recebe cada envio, ainda o registra como uma issue, e ainda mostra à pessoa que pediu um status no widget, mas fechar esse ciclo específico de volta na própria issue é um passo que se faz manualmente até essa integração existir.

As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.

Relacionado na changeloop: Documentação para desenvolvedores, Exemplos de changelog