Explique O Que Era

O que é e como explicar o que era

A expressão explique o que era resume um problema que aparece o tempo todo em documentação técnica, preservação digital e jornalismo de pesquisa: como descrever algo que já não existe mais de forma clara e útil para quem não vivenciou a época. Não é só dar uma definição. É reconstruir contexto. E isso exige trabalho de campo, não só leitura.

explique o que era na prática

Eu comecei a lidar com isso de forma séria quando fui chamado para ajudar num projeto de migração de dados de um sistema legado de gestão hospitalar dos anos 90. O software chamava-se SAGE-H, rodava em DOS, e os únicos documentos que restavam eram manuais em papel amarelado e três e-mails de um desenvolvedor que já tinha falecido. Meu chefe pediu que eu escrevesse um documento explicando como o sistema funcionava para a equipe nova que ia fazer a migração para a nuvem. O problema real não era técnico. Era que cada campo do banco de dados tinha um nome que fazia sentido na época — como "COD_PRE" para código do prontuário do paciente — e ninguém mais lembrava o porquê daquelas abreviações. Eu precisei rastrear a origem de cada sigla, cruzar com normas da ANS daquela época, e encontrar o desenvolvedor original usando o Internet Archive para recuperar versões antigas do site da clínica que hospedava o sistema.

A estrutura básica para explicar algo do passado

A primeira coisa que todo mundo erra é começar pela definição. A definição vem por último. Você começa pelo problema que aquilo resolvia. Antes de 2010, hospitais pequenos usavam planilhas Excel como sistema de prontuário. O SAGE-H nasceu porque o coordenador médico da clínica percebeu que estava perdendo dados de pacientes entre uma planilha e outra. Esse é o ponto de partida. A partir daí, a explicação flui naturalmente: problema solução como funcionava por que foi substituído.

Uma estrutura que eu uso e que funciona na maioria dos casos é esta:

• Contexto histórico: o que estava acontecendo quando aquilo foi criado
• Problema original: qual dor real ele resolvia
• Mecanismo: como funcionava na prática, passo a passo
• Limitações: o que não funcionava bem
• Legado: o que restou disso hoje

O item "limitações" é o mais negligenciado e o mais importante. Quem criou o SAGE-H tinha um bug conhecido: quando o paciente tinha dois códigos de convênio, o sistema travava o cadastro. Esse detalhe foi crucial para a equipe nova entender por que alguns registros estavam incompletos na base de dados.

Onde a coisa complica

Existem situações em que a explicação do que era algo se torna quase impossível por falta de fontes. Isso acontece com frequência em pequenas empresas que cresceram rápido e nunca documentaram nada. O fundador sai, o computador quebra, e sobram só memórias de pessoas que podem estar erradas ou ter saído também. No caso do SAGE-H, eu levei seis semanas só para mapear os dez campos mais importantes. O gargalo não era a técnica. Era a escassez de fontes primárias. Minha solução foi fazer uma sessão de gravação com o antigo responsável financeiro da clínica, que lembrava como os dados entravam no sistema todos os dias. A gravação rendeu três horas de áudio, mas só duas partes foram úteis. Eu transcrevi, cotei com os prints de tela que encontrei no Wayback Machine, e construí a narrativa campo a campo.

Erros comuns ao escrever esse tipo de texto

O erro mais frequente é assumir que o leitor conhece o contexto. Quando eu explicava o SAGE-H para a equipe nova, eu precisava primeiro descrever o que era um prontuário eletrônico, como funcionava o SUS na época, e qual era o formato dos arquivos .dbf que o sistema usava. Sem isso, nenhuma explicação faz sentido. Outro erro é usar linguagem da época sem explicação. Termos como "netbook", "USB 1.1", ou "disquete de 3,5 polegadas" precisam de uma frase de contextualização, mesmo que pareça óbvio. Para quem tem menos de 30 anos, essas referências são alienígenas.

Quando a abordagem falha

Há casos em que não vale a pena explicar o que era algo. Se o sistema foi substituído há dez anos, não deixou legado, e ninguém mais precisa entender seu funcionamento interno, gastar semanas pesquisando é investimento sem retorno. Nesse cenário, uma nota de rodapé de duas linhas basta. A regra prática é: explique profundamente só quando o conhecimento anterior impacta decisões presentes. Caso contrário, seja breve e direcione para arquivo. No meu projeto com o SAGE-H, identificamos que o legado mais importante não era o software em si, mas o padrão de nomenclatura dos campos que depois foi adotado pela rede de clínicas parceiras. Esse foi o foco da documentação final: não o sistema, mas as regras de dados que ele estabeleceu.

Um resumo prático

Para explique o que era qualquer coisa do passado, o caminho mais eficiente é: encontre o problema original que aquela solução endereçava, reconstitua o contexto com fontes primárias quando possível, documente as limitações tanto quanto os acertos, e decida se o esforço de explicação profunda vale a pena com base no impacto que aquele conhecimento ainda tem hoje. Sem esse critério, você gasta tempo demais em coisa que ninguém mais precisa saber.