|
|
| {{subiu_orn | }} |
{{subiu_num | }} |
{{subiu_orn | }} |
{{subiu_caps | }}
{{subiu_linha | }}
|
|
O registro de mudanças que a IA cita antes do seu anúncio
Para a pergunta sobre o que mudou na versão nova, o motor de resposta prefere a página de notas de versão sempre atualizada ao post de lançamento.
|
A lista que nunca sai do ar
|
| ▼ |
| |
|
Em 1997, Jakob Nielsen e John Morkes, do Nielsen Norman Group, reescreveram a mesma página de turismo em cinco versões e mediram cada uma com usuários reais. A versão concisa e varrível ficou 58% mais usável que o texto promocional de origem, e a combinação de concisão com escrita objetiva chegou a 124%.
O teste tinha gente na cadeira. Hoje quem passa primeiro pela sua página de produto é um programa montando resposta, e ele reage à mesma característica com apetite ainda maior: texto enxuto, item por item, com o dado onde o dado deveria estar.
Existe uma página assim dentro de quase toda empresa de software brasileira, e quase ninguém cuida dela. É a página de notas de versão, também chamada de changelog (registro de mudanças): a lista corrida de tudo que entrou, saiu e quebrou em cada número de versão, escrita sem adjetivo, com data ao lado de cada linha.
Ao lado dela vive o concorrente interno, o post de lançamento no blog. Ele nasce bonito, tem imagem, tem frase de efeito, tem citação do diretor de produto. Uma semana depois some do topo do feed (a lista cronológica de publicações do site), e um mês depois descreve um produto que já mudou duas vezes.
Quando o leitor pergunta a um assistente o que mudou na versão nova, as duas páginas entram na disputa. Uma responde com quinze linhas datadas e ainda válidas. A outra responde com trezentas palavras de comemoração e um estado de produto vencido.
A escolha do motor de resposta não tem nada de misteriosa. Ele precisa de uma afirmação curta, atribuível a uma fonte e conferível no momento em que a pergunta chega. Entre duas páginas do mesmo domínio, a que carrega lista, número de versão e carimbo de dia ganha da que carrega adjetivo, e ganha todos os dias, não apenas na semana do anúncio.
A seguir, por que o registro de mudanças ganha essa disputa, o caso de uma empresa de Florianópolis que passou onze meses vendo assistente descrever um recurso extinto, e as cinco correções que colocam a sua página de notas na resposta.
Continue lendo ↓
|
|
|
|
I Sinal da Semana
Por que a lista datada ganha do anúncio
|
|
O motor de resposta não procura o texto mais bonito sobre a versão nova, procura o texto mais verificável.
Uma página de notas de versão entrega quatro coisas que o post de lançamento raramente entrega juntas: o número da versão, o dia em que cada entrega saiu, o verbo do que aconteceu com cada item e a ausência de promessa. Nada ali precisa ser interpretado.
O post de lançamento inverte a proporção. Ele gasta o primeiro terço em contexto de mercado, o segundo em benefício, e só no último parágrafo diz qual recurso foi ligado. Um programa que precisa extrair uma afirmação curta e citável passa direito.
Existe um segundo motivo, mais decisivo, e ele é de manutenção. O registro de mudanças cresce por acréscimo: a linha nova entra no topo, a antiga fica logo abaixo, e a página continua na mesma URL desde o primeiro dia. Quem lê a página lê o estado atual do produto, sem precisar checar quantos anúncios vieram depois.
O que a permanência de endereço faz pela citação
Endereço estável acumula sinal. Cada menção em fórum, cada resposta de suporte, cada issue no repositório aponta para a mesma página, e o motor de resposta encontra um documento com histórico longo, e não uma coleção de posts concorrentes que se contradizem quanto ao estado do produto.
O post de lançamento faz o contrário: cria um endereço novo a cada versão. Três lançamentos por ano viram três páginas rivais sobre o mesmo produto, cada uma correta na semana em que nasceu e errada depois. Quando o assistente escolhe uma delas, costuma escolher a mais citada, que é a mais antiga.
|
"Plan to throw one away; you will, anyway." (Faça o plano contando que a primeira versão será jogada fora, porque será.)
Fred Brooks, The Mythical Man-Month, 1975
|
As três formas de estragar a própria página de notas
A primeira é esconder o texto atrás de código que só executa no navegador. Página de notas montada por aplicativo de página única, que carrega a lista por chamada de dados depois da abertura, chega ao coletor como moldura vazia. O time vê a lista, o programa vê nada.
A segunda é escrever a nota como anúncio. Linha do tipo "melhoramos a experiência de importação" não diz o que mudou. Linha do tipo "importação de CSV passou a aceitar arquivos até 200 MB, antes 25 MB" diz, e é ela que aparece citada com o nome do produto ao lado.
A terceira é deixar a página fora do caminho. Registro de mudanças trancado atrás de login, escondido em subdomínio de documentação sem link no site principal ou publicado apenas dentro do aplicativo não entra na resposta, porque não existe para quem coleta.
|
|
|
|
|
II Case Brasileiro
Onze meses citando um recurso extinto em Florianópolis
|
|
Trezentas e dezoito notas de versão dentro do painel, nenhuma delas na web aberta.
|
Rafael Cordeiro, gerente de produto de uma empresa de gestão de estoque de Florianópolis com 1.200 clientes pagantes, descobriu o problema por um ticket de suporte. Um cliente novo escreveu pedindo ajuda para configurar a integração com uma transportadora que havia saído do produto em 2024.
O cliente anexou o que tinha lido. Era a resposta de um assistente, que descrevia a integração em detalhe, citava o post de lançamento de junho de 2023 no blog da empresa e afirmava que o recurso estava disponível no plano intermediário.
Rafael levou dez perguntas de produto a três assistentes de resposta, sempre na mesma redação, e anotou qual página cada resposta citava.
Notas de versão publicadas dentro do painel: 318
Notas de versão acessíveis na web aberta: 0
Posts de lançamento no blog, desde 2021: 27
Respostas que citavam post de lançamento vencido: 7 de 10
Respostas que descreviam recurso já retirado: 4 de 10
Respostas que citavam a nova página pública, cinco meses depois: 6 de 10
A empresa mantinha um registro de mudanças exemplar, atualizado a cada entrega pelo próprio time de engenharia, com 318 notas escritas desde 2021. Ele morava dentro do painel do cliente, atrás de login, num endereço que nenhum coletor jamais abriu.
Na web aberta existiam apenas os 27 posts de lançamento. O de junho de 2023 falava da transportadora, tinha três anos de links apontando para ele e continuava sendo a página mais citada da empresa sobre integrações, mesmo depois da retirada do recurso.
Rafael mediu o estrago pelo suporte antes de mexer em qualquer coisa. Entre agosto de 2025 e junho de 2026, o time de atendimento registrou 43 tickets abertos por cliente que esperava um recurso inexistente, e dois contratos anuais cancelados na primeira semana com a mesma justificativa escrita.
A correção não envolveu escrever texto novo. A equipe publicou o registro de mudanças existente numa página aberta, em endereço fixo, com as 318 notas em ordem inversa, cada uma com número de versão, data e verbo explícito. A lista foi ligada no rodapé de todas as páginas do site e no topo da documentação.
Os sete posts de lançamento que descreviam recursos retirados receberam, no primeiro parágrafo, uma linha dizendo que aquele recurso saiu, com a data da retirada e o link para a nota correspondente. Nenhum post foi apagado, para não perder o histórico de links apontando para eles.
Cinco meses depois, as mesmas dez perguntas voltaram aos mesmos três assistentes. Seis respostas citavam a nova página pública, nenhuma descrevia o recurso extinto como disponível, e o suporte registrou três tickets do tipo antigo no período, contra os 43 anteriores.
|
| |
|