Relato De Experiencia

Como construir um relato de experiencia que pessoas realmente leem

Vou direto ao ponto. Um relato de experiencia funciona quando você documenta o que aconteceu, o que deu errado e como resolveu, sem enfeites. A maioria das pessoas escreve isso como se fosse um curriculum vitae disfarçado — cheios de adjetivos, sem dados concretos, impossível de replicar. Isso não serve pra ninguém. Relato de experiencia é a documentação estruturada de uma situação real que você enfrentou, com contexto suficiente para outro profissional entender o problema, as opções consideradas e o resultado final. Não é tutorial passo a passo. Não é teoria. É a versão crua de "eu passei por isso e aqui está o que aprendi". Na area de desenvolvimento de software, engenharia e consultoria, esse formato é o que separa o conhecimento tribal do conhecimento transferivel. Eu já vi relato de experiencia ser usado de tres formas principais: post-mortem tecnico, case study interno e documentacao de licoes aprendidas. Cada uma tem publico diferente. Post-mortem é pra quem vai investigar o mesmo erro no futuro. Case study é pra gerentes que precisam justificar investimento. Licoes aprendidas é pra equipe que vai trabalhar no proximo modulo. Se voce misturar esses tres, o relato perde o foco e vira uma sopa de letrinhas que ninguem termina de ler.

Metodo pratico que eu uso

A estrutura que funciona pra mim tem cinco blocos, mas a ordem que eu sigo nao é a ordem cronologica. Eu começo pelo resultado, depois o problema, depois o caminho que eu tentei, depois o que eu faria diferente, e por ultimo os dados brutos. Isso parece contra-intuitivo no principio porque todo mundo quer contar a historia do inicio pro final, mas quem lê um relato de experiencia precisa saber primeiro se vale a pena continuar lendo. O bloco de resultado deve ter duas coisas: o que foi alcançado em numeros e o que ainda esta pendente. Nao use linguagem vaga como "resultados positivos". Escreva "tempo de resposta caiu de 2.3 segundos para 180 milissegundos em 95% das requisicoes". O bloco de problema deve descrever o sintoma que voce viu antes de entender a causa raiz. A maioria dos relatos pula essa parte e vai direto pra solucao, mas o sintoma é o que permite que alguem identifique o problema antes que ele vire crise. O bloco de tentativa é onde a maioria falha. Voce precisa listar as opcoes que considerou e por que descarto cada uma, com o criterio de decisao explcito. Eu costumo incluir uma tabela simples: opcao, criterio de rejeicao, impacto se eu tivesse escolhido aquela. Isso economiza horas de conversa na revisao do relato. O bloco de licoes tem que ser especifico demais pra dar margem a interpretacao. "Melhor comunicar cedo" nao é uma licao. "Implementei check semanal de integridade dos dados no dominio X após observar que 3 de 4 incidentes tiveram origem em corrupcao de dados de migragao" é uma licao que alguém pode reproduzir.

Um caso especifico que me pegou

Em 2023, trabalhei num relato de experiencia sobre migracao de banco de dados relacional para PostgreSQL com particionamento por tenant. A situacao era simples na teoria: 47 tabelas, 12GB de dados, downtime permitido de 4 horas. O que eu nao previu foi que o processo de dump usando pg_dump com a flag --no-owner gerava arquivos com 3GB a mais do que o esperado porque include grants em lingua estrangeira que o destino nao reconhecia. O erro apareceu so durante a restauracao, quando o PostgreSQL recusada constraints referenciando usuarios que nao existiam no novo cluster. A workaround que eu usei foi executar um script Python de pre-validacao antes do dump, comparando os mapeamentos de role entre as instancias fonte e destino e gerando um arquivo de exclusoes manual. Isso adicionou 22 minutos ao processo total mas evitou 4 horas de debug em producao. Eu dokumentei isso no relato de experiencia com o script incluso num repositorio interno. O problema é que esse tipo de detalhe técnico specifico geralmente é cortado dos relatos porque a pessoa acha que "ninguem vai se importar". Errado. Quem vai enfrentar o mesmo problema no futuro é exatamente quem mais precisa desse detalhe.

Erros comuns que iniciantes cometem

O primeiro erro é escrever o relato de experiencia como se fosse um artigo academico. Nao cite referencias. Nao use linguagem passiva. Nao tenha vergonha de mostrar que voce errou. O segundo erro é omitir os dados que mostram a magnitude do problema. "O sistema estava lento" nao diz nada. "O tempo medio de resposta subiu de 400ms para 3.2 segundos durante o pico de 14h-16h" sim. O terceiro erro é nao incluir o que voce NAO fez. As fronteiras da decisao sao tao importantes quanto a decisao em si. Também vejo muita gente incluir prints de tela em excesso. Um screenshot do log de erro central ja basta. Mais do que isso vira ruido visual. E cuidado com a armadilha do retrospecto perfeito: voce nunca deve escrever o relato de experiencia como se tudo tivesse dado certo desde o inicio. Se o primeiro plano falhou e voce improvisou, documente a falha. A credibilidade do relato depende disso.

Quando um relato de experiencia nao funciona

Ha tres situacoes em que esse metodo falha completamente. Primeira: quando o problema é puramente humano, sem componente tecnico. Relato de experiencia de conflito interpessoal entre colegas nao deve ir pra documentacao tecnica, a menos que voce transforme em processo organizacional identificavel. Segunda: quando voce nao tem dados mensuraveis. Sem numeros, o relato vira opiniao disfarçada. Terceira: quando o contexto mudou tanto que a solucao nao é mais aplicavel. Nao force uma analogia. Diga explicitamente "isso funciona para X contexto, nao para Y". Uma alternativa quando o relato de experiencia nao se aplica é o decision log, que foca em por que certas opcoes foram rejeitadas sem necessidade de descrever o resultado completo. Ou o failure mode analysis, mais indicado para riscos potenciais do que para incidentes já ocorridos. Escolha a ferramenta certa pro trabalho.

Duracao real do processo

Escrever um relato de experiencia completo leva entre 45 minutos e 2 horas, dependendo da complexidade. A maior parte do tempo nao é escrever, e sim coletar os dados: logs, métricas, prints de status, depoimentos de envolvidos. Eu recomendo passar 60% do tempo coletando e 40% escrevendo, nao o contrario. Quem tenta escrever primeiro acaba inventando detalhes que depois precisam ser corregidos na revisao. O revisao do relato leva em media 20 minutos quando o autor segue a estrutura proposta. Mais do que isso indica que algo nao está claro no texto original. Se a revisao demorar mais de 30 minutos, releia o bloco de resultado e verifique se os dados estão presentes e verificaveis antes de mandar pra outra pessoa.