Log de Decisões: Como registrar decisões para que os motivos sobrevivam

Organizações lembram o que decidiram, mas esquecem o porquê. Como funcionam os registros de decisão, o que capturar, um modelo leve e como vincular cada um aos resultados.

Ibrahim Elkobeissi · 2 de novembro de 2026 · 6 min de leitura ·

LinkedIn X WhatsApp

A fachada de um grande edifício institucional modernista

Pergunte a uma equipe por que uma política existe e, muitas vezes, você ouvirá um silêncio. Alguém se lembra de uma reunião. Outro acha que foi um problema com um fornecedor. A pessoa que sabia saiu no ano passado. A decisão sobreviveu. Os motivos, não.

Isso é comum e custoso. Sem os motivos, uma equipe tem duas opções ruins: manter uma decisão que não entende mais ou revertê-la e correr o risco de trazer de volta o problema que ela resolveu. Um log de decisões oferece uma terceira via. Leia o registro, verifique se as condições ainda se mantêm e decida novamente com propósito.

Por que as organizações esquecem o porquê de suas decisões

Três forças agem contra a memória de uma organização sobre suas próprias decisões.

Os motivos vivem em conversas. Decisões são tomadas em reuniões, chamadas e threads de mensagens. O resultado vira uma política ou um plano. O contexto raramente chega lá.
Pessoas mudam. As pessoas que avaliaram as opções mudam de cargo ou saem. O entendimento delas vai junto.
A memória se reescreve. Em um estudo de 1975, o psicólogo Baruch Fischhoff descobriu que, uma vez que as pessoas conhecem o resultado, elas o julgam como mais previsível do que realmente foi. Ele chamou isso de "determinismo progressivo". Após o fato, uma decisão sólida que deu errado parece descuidada, e uma decisão de sorte parece sábia.

O último ponto é o mais importante. Mesmo quando as mesmas pessoas permanecem, a memória de por que decidiram é moldada pelo que aconteceu depois. Apenas um registro feito no momento preserva o que era conhecido, o que era esperado e o que era incerto.

As diretrizes de arquitetura da Microsoft expõem o custo claramente. Uma decisão que nunca é registrada "provavelmente será esquecida, levando a debates repetitivos."

O que as equipes de software aprenderam: o registro de decisão de arquitetura

A engenharia de software tem uma resposta testada. Em novembro de 2011, Michael Nygard propôs o architecture decision record, ou ADR: um documento curto para cada decisão significativa, numerado em sequência e mantido junto ao projeto. Seu formato possui cinco partes.

Título. Uma frase nominal curta com um número, como "ADR 9: LDAP para Integração Multitenant."
Contexto. As forças em jogo: técnicas, políticas, sociais e locais. Nygard pediu que esta seção fosse neutra, uma descrição de fatos.
Decisão. A resposta a essas forças, em frases completas na voz ativa: "Nós iremos..."
Status. Proposta, aceita, obsoleta ou substituída, com uma referência a qualquer substituição.
Consequências. O contexto resultante. Nas palavras de Nygard, "Todas as consequências devem ser listadas aqui, não apenas as 'positivas'."

A prática se espalhou. A Thoughtworks colocou ADRs leves no anel Adopt de seu Technology Radar, seu nível mais forte de recomendação, e aconselhou mantê-los no controle de versão em vez de uma wiki separada. O Azure Well-Architected Framework da Microsoft chama o registro de decisão de uma das entregas mais importantes de um arquiteto de soluções. Suas diretrizes adicionam duas regras que valem a pena adotar: trate o log como apenas para anexar (append-only) e registre um nível de confiança em cada decisão.

Nada disso é específico para software. Hospitais mudam procedimentos de admissão. Escolas mudam políticas de avaliação. Agências mudam fornecedores. Cada uma dessas decisões tem contexto, opções e consequências, e cada uma será questionada futuramente por alguém que não estava na sala.

O que um registro de decisão deve capturar

Um log de decisões é a coleção desses registros, com um índice que resume cada um. O playbook de engenharia da Microsoft descreve o log como uma tabela de sumários executivos, com metadados, para as decisões contidas nos registros completos. O modelo de log de decisões abaixo funciona bem além da engenharia. Cada campo tem seu lugar.

ID e título. Um número e uma frase que indica o que foi decidido.
Data. Quando a decisão foi tomada, não quando foi escrita.
Responsável. A pessoa que responde pela decisão e quem foi consultado.
Contexto. O problema, as restrições e as forças em tensão.
Opções consideradas. Incluindo as rejeitadas e o porquê. Este é o campo que mais falta e que mais se faz necessário.
Decisão. Uma frase clara que começa com "Nós iremos..."
Evidências. Links para os dados, relatórios, auditorias ou feedbacks nos quais a decisão se baseou.
Resultado esperado. O que deve ser verdade se a decisão funcionar, e até quando.
Confiança. Alta, média ou baixa, com uma indicação do que permanece incerto.
Data de revisão. Quando a decisão será confrontada com o resultado esperado.
Status. Proposta, aceita, substituída ou aposentada, com um link para qualquer substituta.

Os campos de resultado esperado e confiança cumprem o papel de um Journal de decisões. Eles registram o que você acreditava antes de conhecer o resultado, que é exatamente o que o viés de retrospectiva apaga.

Aplicamos o mesmo rigor às nossas decisões de produto. O que é observado é registrado separadamente do que é inferido, e visões conflitantes são preservadas, em vez de suavizadas. Uma decisão merece, no mínimo, esse cuidado.

Vincule cada decisão às suas evidências e ao seu resultado.

Um registro que se sustenta sozinho é melhor do que nada. Um registro que é vinculado é muito mais útil.

Vincule de volta às evidências. Quando uma decisão cita uma pesquisa de pacientes, uma análise de custos ou um relatório de incidente, vincule a própria fonte. Leitores posteriores poderão julgar se a evidência ainda é válida. A orientação da Microsoft reforça esse ponto: um registro sem justificativa "perde seu valor com o tempo."

Vincule adiante ao resultado. Na data de revisão, escreva o que realmente aconteceu ao lado do que era esperado. Se a lacuna for grande, pergunte o porquê. A evidência era fraca? As condições mudaram? A decisão foi correta e o resultado foi apenas azar? A resposta é uma lição, e ela pertence à mesma cadeia. Nosso artigo sobre lições aprendidas que mudam o próximo projeto explica como fazer com que essas lições sejam aplicadas.

Vincule aos sucessores. Quando uma decisão for revertida, não edite o registro antigo. Marque-o como substituído e aponte para o novo. O histórico de uma mudança de direção é, muitas vezes, o item mais valioso do log.

Um exemplo hipotético ilustra a cadeia. Uma clínica decide transferir as chamadas de acompanhamento de enfermeiros para um coordenador dedicado. O registro cita dados de conclusão de chamadas, nomeia o gerente de operações como responsável, espera que a conclusão aumente em três meses e define uma data de revisão. Na revisão, a conclusão aumentou, mas a carga de trabalho dos enfermeiros não diminuiu como esperado. Um novo registro substitui o primeiro, ajusta a função e vincula de volta ao anterior. Dois anos depois, um novo gestor pode ler toda a história em cinco minutos.

Mantenha-o leve o suficiente para durar.

Logs de decisão falham da mesma forma que a maioria das documentações. Eles se tornam um fardo e, então, param. Cinco regras os mantêm vivos.

Registre apenas decisões significativas. O teste da Microsoft é útil: decisões que moldam a estrutura, afetam qualidades essenciais ou são difíceis de reverter.
Mantenha cada registro curto. Uma página ou menos. Vincule ao material de apoio em vez de copiá-lo.
Escreva no momento da decisão. Um registro escrito na mesma semana é preciso. Um escrito meses depois é uma reconstrução.
Mantenha-o onde o trabalho acontece. Um log mantido junto aos planos e procedimentos que ele afeta é lido. Um log em uma pasta separada, não.
Comece agora e depois preencha o passado. Comece com as novas decisões. Depois, reconstrua as poucas decisões passadas sobre as quais as pessoas mais perguntam e marque-as como reconstruídas.

Uma decisão sem seus motivos é uma instrução. Uma decisão com seus motivos pode ser testada, mantida ou alterada com cuidado.

Como o Prism mantém registros de decisão

Prism armazena as decisões e o conhecimento de uma organização como itens com um nível de Confiança declarado: ratificado, baseado em evidências, observado ou inferido. Cada decisão vincula-se às suas evidências, aos passos para executá-la e aos resultados e lições de Pause and Learn que se seguem. Quando uma decisão é substituída, a anterior permanece visível. Os assistentes que sua equipe já utiliza também podem ler o registro, para que os motivos estejam lá quando alguém perguntar. As pessoas tomam as decisões. O Prism guarda os motivos.