Brag Document: como venho documentando minhas entregas e o agente que estou criando

No dia 7 de outubro, às 19h21, recebi um pedido para levantar o que eu já tinha feito com IA no trabalho. O material serviria para uma reunião da diretoria no dia seguinte. Prazo: 11h da manhã.

Era uma oportunidade de mostrar minhas contribuições. Só que, para aproveitar, eu precisava recuperar meses de trabalho, organizar as iniciativas e conferir o que podia afirmar. Tentar lembrar de tudo naquela hora seria trabalhoso.

Eu já vinha guardando notas que tomei em reuniões e registros das minhas entregas. Foi esse histórico que usei para preparar a resposta. E esse episódio ajuda a explicar por que venho dando mais atenção ao Brag Document, a ponto de estar criando um agente dedicado a isso para colocar no meu projeto Anvilore.

O que é um Brag Document e o que outras pessoas dizem sobre ele

Um brag document é um registro das suas realizações, com contexto sobre sua contribuição e seus resultados. Você o mantém ao longo do tempo para consultar quando precisa falar do próprio trabalho. O nome vem do inglês brag, algo como se gabar. Eu prefiro pensar no documento como uma forma de conseguir explicar o que fiz, com evidência.

Uma referência conhecida é o artigo Get your work recognized: write a brag document, publicado por Julia Evans em 2019. Ela aponta uma dificuldade familiar: você esquece parte do que fez, e sua liderança também. O registro ajuda nas avaliações e permite refletir sobre a direção da carreira. Julia recomenda incluir contribuições difíceis de quantificar, como mentoria e melhorias na qualidade do código.

Há relatos de uso que ajudam a dar contexto. Kate Travers publicou seu próprio documento e contou que a prática foi útil na avaliação de fim de ano e na reflexão sobre seu trabalho. André Seiji relata reservar meia hora por semana para atualizar o dele, incluindo entregas e feedbacks. Ele também diz que rever as conquistas teve valor mesmo quando não recebeu aumento ou promoção.

São experiências de quem usa. Elas ajudam a entender a proposta; não demonstram que manter um documento vai garantir reconhecimento ou reajuste.

O relatório pedido no fim do dia

Voltando ao pedido: eu precisava reunir iniciativas de IA aplicadas ao trabalho, incluindo planejamento de testes, apoio com código e automações.

Usei agentes para consultar minha wiki, os históricos dos repositórios, o ai-memory e as notas que tomei em reuniões. As buscas recuperaram iniciativas com datas e fontes, para eu conferir o que entraria na resposta. Esse uso da wiki se conecta ao que já contei em Para que serve uma wiki mantida por LLM no dia a dia.

Às 19h54 havia um primeiro rascunho completo, 33 minutos depois do pedido. A mensagem foi enviada às 9h50 do dia seguinte, antes do prazo das 11h.

Quero destacar esse detalhe: os 33 minutos foram até o primeiro rascunho. Houve conferência, correções e revisão depois. Eu não medi o tempo efetivo de trabalho, então não tenho como dizer quantas horas economizei.

E a revisão encontrou problemas. Um dos levantamentos contava 70 cenários de teste; depois de conferir o que estava ativo, o número correto ficou em 67. Também ajustei a descrição da minha participação: implementar cenários em outro framework não me tornava autor dos cenários originais.

Eu pedi uma revisão independente por outro modelo, e ela encontrou erros que teriam enfraquecido a resposta. O histórico organizado me ajudou a recuperar as entregas; ainda precisei verificar os números e dar o crédito correto a cada pessoa.

Esse levantamento foi uma aplicação prática da ideia do brag document, mesmo sem partir de um documento pronto com esse nome. Eu tinha registros acumulados e consegui montar uma visão deles para uma necessidade concreta.

Como venho fazendo isso

Na minha wiki, mantenho um inventário de vitórias. Ele reúne conquistas profissionais e de outras áreas da vida, com data e fonte. O brag document funciona como uma seleção desse inventário, considerando o período e a finalidade.

Eu posso considerar um projeto pessoal uma conquista e querer guardá-lo para mim. Para conversar com a liderança, preciso selecionar o que tem relação com meu trabalho. Para uma entrevista, um projeto pessoal pode ser relevante. O conteúdo depende de quem vai ler e do que quero demonstrar.

Venho estruturando os registros para conseguir responder:

• Contexto: qual problema existia ou o que precisava ser feito?
• Contribuição: o que eu fiz e o que outras pessoas fizeram?
• Resultado: o que mudou e como consigo sustentar essa afirmação?
• Fonte: onde está o documento, feedback, registro ou medição que permite conferir?

Admito que ainda tenho uma lacuna aqui. Tenho entregas e feedbacks registrados, mas nem sempre capturei o estado anterior para comparar com o resultado.

Um documento comprova que eu documentei algo. Um commit ajuda a mostrar uma contribuição. Para afirmar que reduzi o tempo de uma atividade, preciso medir esse tempo. São evidências diferentes, e misturá-las deixa o argumento fraco.

Quando falta a medição, prefiro registrar o que sei e o que ainda preciso medir. Se eu não capturei o antes, não vou inventar um número depois só para a frase ficar melhor.

Baseline: o exemplo que dei a alguém que me pediu ajuda

Recentemente, alguém me pediu ajuda para conversar sobre carreira em QA. Em determinado momento, entramos no assunto de automação de testes. Uma das orientações que dei foi: registre o tempo do processo atual antes de começar a mudar esse processo.

Esse registro inicial é o baseline, a referência com a qual você vai comparar o resultado novo.

Na conversa, usei um exemplo: você recebe 30 cenários para automatizar. Antes de desenvolver os testes, pergunta ao pessoal que faz a execução manual quanto tempo levaria para testar aquele mesmo conjunto. Vamos supor que a resposta seja quatro semanas. Você guarda essa informação, desenvolve a automação e mede sua execução. Para ilustrar, falei em 15 minutos.

Usei esses números para explicar o raciocínio. Eles não eram resultados medidos daquela pessoa. A orientação era guardar o antes e medir o depois, para conseguir apresentar a entrega com contexto.

E a natureza da informação precisa acompanhar o registro. Se o time estima quatro semanas, eu anoto que é uma estimativa. Se acompanhei execuções reais e medi o tempo, registro as condições da medição. Uma estimativa pode ser uma referência inicial útil, mas continua sendo uma estimativa quando vai para o brag document.

Também preciso conferir se estou comparando coisas equivalentes. Quatro semanas podem incluir espera e interrupções; 15 minutos podem representar só o tempo em que a suíte ficou rodando. Para afirmar quanto tempo de trabalho foi poupado, preciso separar o esforço das pessoas do prazo total e comparar o mesmo conjunto de cenários, com as mesmas verificações. O custo de desenvolver e manter a automação também entra na avaliação do ganho.

Com esses cuidados, consigo explicar o que mudou e onde está a evidência. Dizer apenas que automatizei 30 testes deixa de fora justamente a comparação que pode mostrar o valor daquela entrega.

Um modelo para preencher

Eu organizaria esse registro assim. Você pode repetir o bloco de conquista para cada entrega do período:

# Brag Document — [período]

## [Conquista ou projeto]

- Data: [quando aconteceu]
- Contexto: [problema e quem era afetado]
- Minha contribuição: [o que fiz e o papel das outras pessoas]
- Baseline (antes): [valor, unidade, escopo e data da coleta]
- Origem do baseline: [medição ou estimativa; fonte e condições]
- Mudança realizada: [o que implementei ou alterei]
- Resultado (depois): [valor, unidade, escopo e como medi]
- Comparação: [diferença observada; os dois lados são comparáveis?]
- Impacto: [o que mudou para o time, usuário ou negócio]
- Evidências: [links para registros, relatórios, documentos ou feedbacks]
- Limites e pendências: [o que ainda não sei ou preciso medir]

No exemplo que usei na conversa, o preenchimento inicial poderia ficar assim:

Enquanto essas pendências estiverem abertas, eu consigo registrar a entrega e o tempo da execução automatizada. Uma porcentagem de economia de trabalho ainda precisaria de dados comparáveis.

Quando acho interessante usar

O pedido de última hora é um exemplo, mas vejo utilidade em momentos bem comuns da carreira:

• Avaliação de desempenho e conversas com a liderança: levar exemplos do período, inclusive os que ficaram longe da entrega mais recente.
• Negociação de aumento ou promoção: apresentar contribuições e resultados que sustentem a conversa.
• Mudança de liderança: dar contexto para alguém que chegou depois e não acompanhou o trabalho anterior.
• Currículo e entrevistas: recuperar situações reais, com detalhes suficientes para explicar minha participação.
• Reflexão pessoal: observar o que venho fazendo, o que aprendi e o que quero continuar ou mudar.

Também acho útil para quem faz um trabalho que aparece pouco: ajuda colegas, revisa código, esclarece uma regra ou melhora uma documentação. Se houver um resultado observável, vale registrá-lo, mesmo quando ele não cabe numa porcentagem.

Eu começaria antes da próxima avaliação. Com os acontecimentos recentes, fica mais fácil guardar a fonte e esclarecer a participação de cada pessoa.

O agente que estou criando para o Anvilore

Já criei uma skill dedicada a brag documents na minha wiki. Estou desenvolvendo esse trabalho para levá-lo como um agente especializado ao Anvilore, meu projeto de organização de conhecimento com agentes de IA.

A skill tem duas funções: buscar possíveis conquistas nos registros e montar um documento para determinado período. Na busca, ela apresenta os candidatos com data, evidência e fonte. Eu reviso e decido o que entra no inventário.

Esse é um cuidado que faço questão de manter. Uma opinião de outra pessoa que salvei na wiki não vira uma realização minha. Uma ideia que ainda quero executar continua sendo uma ideia. E, quando minhas notas de reunião não deixam claro quem fez determinada contribuição, essa dúvida precisa aparecer no resultado.

A proposta para o agente é aproveitar essa base para preparar visões adequadas a cada situação: uma conversa profissional, uma entrevista ou uma consulta pessoal. Os números precisam vir acompanhados de sua origem, e os itens sem medição precisam continuar identificados dessa forma.

Ainda estou construindo essa parte. A skill já existe na minha wiki; a integração como agente dedicado no Anvilore é o trabalho em desenvolvimento. O episódio do relatório mostrou que tenho material útil para consultar e também mostrou onde a revisão precisa ser mais cuidadosa.

Por onde eu começaria

Você pode começar com uma nota simples. Registre uma entrega recente, a data, sua participação, o resultado observado e um link para a evidência. Quando receber um feedback relevante, guarde também. Depois, escolha um intervalo que consiga manter para voltar nessa nota e atualizá-la.

No meu caso, esse registro faz parte de um sistema maior de conhecimento, e estou usando agentes para ajudar na busca e na organização. Mas o hábito de guardar o que aconteceu veio antes. Foi o que me permitiu responder àquele pedido quando o prazo já era curto.

Por fim, o próximo passo que quero melhorar é a coleta das métricas enquanto o trabalho acontece. Já consigo recuperar boa parte do que fiz; quero conseguir explicar melhor o que mudou por causa disso.