Como registrar decisões de produto e saber quando revê-las

Para registrar uma decisão de produto, escreva o problema, as alternativas consideradas, a escolha feita e as condições que a justificam. Acrescente o que ficou de fora e qual mudança de contexto exigiria uma revisão. O registro deve permitir que alguém entenda a decisão sem depender da presença de quem participou da conversa.

Isso é diferente de guardar uma ata ou marcar uma tarefa como concluída. Uma ata acompanha uma reunião; uma tarefa acompanha uma entrega. O registro de decisão preserva o motivo de uma escolha que continuará influenciando o produto depois daquele encontro e daquela entrega.

Escolha o que merece um registro próprio

Nem todo ajuste precisa de um documento. Priorize escolhas que afetam outras partes do sistema, criam uma restrição duradoura ou seriam caras de desfazer. Aceitar pedidos sem confirmação imediata de horário, por exemplo, muda a promessa ao usuário e o trabalho de atendimento. Corrigir um erro de digitação normalmente não exige a mesma discussão.

Na arquitetura de software, esse tipo de memória pode usar um ADR, sigla para registro de decisão de arquitetura. A Microsoft recomenda registrar escolhas que afetam a estrutura, atributos importantes de qualidade ou que sejam difíceis de reverter. A referência inclui contexto, opções, justificativas e consequências.

A proposta deste artigo adapta essa disciplina à conversa entre produto, operação e equipe técnica. Não é necessário chamar toda escolha de arquitetura. É necessário reconhecer quais decisões futuras dependem de compreender a escolha atual.

Se a discussão ainda é sobre contratar um SaaS ou construir uma solução própria, o roteiro de sistemas internos B2B ajuda a avaliar as opções. Aqui, o foco é preservar a justificativa depois que uma direção foi escolhida.

Escreva a decisão, não a história inteira da conversa

Um registro útil pode começar com uma frase objetiva: “O cliente solicitará uma visita, mas não reservará um horário nesta versão”. Em seguida, explique a condição que tornou essa escolha adequada. “Foi alinhado com a equipe” informa participação, não explica o motivo.

Use uma ficha curta, com campos que respondam a perguntas distintas:

• Identificação e situação: título específico, código estável, data e estado da decisão.
• Contexto: qual problema precisa ser resolvido e quais restrições estão confirmadas.
• Alternativas: quais caminhos viáveis foram comparados, incluindo manter a situação atual quando fizer sentido.
• Escolha e motivo: o que será adotado e qual critério foi determinante.
• Consequências: o que melhora, qual custo será aceito e o que continuará sem solução.
• Limites e revisão: onde a decisão vale, o que ainda é hipótese e qual evidência justificaria reconsiderá-la.
• Responsabilidade e referências: quem confirma a decisão e onde estão os insumos e trabalhos relacionados.

Não preencha alternativas apenas para tornar a escolha preferida inevitável. Se uma opção foi descartada porque exigia uma capacidade inexistente, diga qual capacidade faltava. Se ela deixou de ser considerada por uma restrição de prazo, preserve essa condição. “Não funciona” e “não cabe nesta entrega” são conclusões diferentes.

Separe proposta, aprovação e implementação

Um documento bem escrito não transforma uma hipótese em acordo. Enquanto houver uma decisão pendente, mantenha o registro como proposta e indique o ponto que precisa ser resolvido. Depois da confirmação pelos responsáveis, registre o estado aceito e a data correspondente.

O processo de ADR da AWS distingue proposta, aceitação, rejeição e substituição de uma decisão. Essa distinção ajuda a evitar que uma alternativa debatida seja lida como regra vigente.

Acompanhe a implementação separadamente. Uma decisão aceita pode ainda não estar disponível no produto. Vincule o registro às tarefas e à evidência de verificação, sem usar “aprovado” como sinônimo de “entregue”. Se a equipe descobrir uma impossibilidade durante a execução, devolva a questão para decisão; não deixe uma solução improvisada virar regra silenciosamente.

Veja uma ficha em um cenário concreto

Considere um exemplo hipotético de um sistema de solicitação de manutenção. O cliente quer escolher uma visita, mas a equipe ainda precisa verificar deslocamento, especialidade e disponibilidade antes de confirmar o horário.

Um registro possível seria:

• Decisão D-014: receber solicitações de visita sem reserva automática de horário.
• Estado: aceita para a primeira versão, neste exemplo hipotético.
• Contexto: a disponibilidade depende de uma conferência operacional que o sistema ainda não consegue realizar.
• Alternativas: oferecer horários fixos; pedir somente a solicitação; permitir uma preferência de período sem prometer reserva.
• Escolha: coletar a solicitação e, quando útil ao atendimento, a preferência de período, identificada como preferência.
• Motivo: não apresentar como disponível um horário que ainda depende de confirmação.
• Consequência aceita: haverá uma etapa posterior de contato; a experiência não termina com agendamento confirmado.
• Fora do escopo: pagamento e distribuição automática das visitas.
• Condição de revisão: existir uma forma confiável de consultar e reservar disponibilidade, incluindo o tratamento de duas solicitações para o mesmo horário.

A ficha não especifica todas as telas nem substitui os testes técnicos. Ela explica por que o fluxo termina em solicitação. Quem for alterar o botão ou a mensagem de confirmação consegue perceber que escrever “Visita agendada” contrariaria a decisão, mesmo sem modificar o restante do sistema.

Revise quando a justificativa mudar

Meses depois, no mesmo cenário hipotético, uma integração passa a oferecer horários consultáveis. Isso não invalida automaticamente a escolha anterior. Primeiro, verifique se ela também permite reservar o horário de forma confiável e como trata indisponibilidade, conflito e falha de confirmação.

Se essas condições forem demonstradas, há um motivo concreto para propor outra decisão. O novo registro pode explicar a capacidade adquirida, o alcance da mudança e o que continua dependendo do atendimento. Se apenas algumas modalidades permitem reserva, a revisão precisa delimitar essas modalidades, em vez de liberar a promessa para todas.

Evite gatilhos vagos como “rever quando crescer”. Prefira condições observáveis: uma restrição deixou de existir, um requisito mudou ou um teste mostrou que a hipótese usada não se sustenta. Uma data de revisão pode ajudar a lembrar da análise, mas não é prova de que a decisão precisa mudar.

Preserve a decisão substituída e ligue os registros

Quando uma nova escolha for aceita, não reescreva a justificativa antiga como se a equipe sempre tivesse conhecido as condições atuais. Marque a decisão anterior como substituída e vincule o novo registro. Preserve o contexto original para explicar versões antigas do produto e escolhas que ainda dependem dele.

A AWS recomenda manter o registro anterior no histórico e indicar sua substituição. Também sugere um local central, como repositório ou wiki. Para uma equipe de negócio, a escolha do lugar deve considerar quem precisa consultar e revisar o conteúdo, não apenas quem consegue editar código.

Mantenha um índice com título, estado e referência à decisão vigente. Restrinja informações comerciais e técnicas sensíveis ao público necessário. Um registro interno não deve ser copiado para um case público sem revisão e autorização próprias.

Use o registro na próxima mudança

Antes de aprovar uma alteração, peça que a pessoa responsável identifique a decisão afetada. A proposta respeita o limite atual, acrescenta algo compatível ou exige substituí-lo? Essa pergunta torna o documento parte do trabalho, em vez de um arquivo produzido apenas ao final do projeto.

Para começar, escolha uma decisão que a equipe costuma rediscutir. Reconstrua somente o que tiver evidência e marque as lacunas, sem inventar uma justificativa retrospectiva. Peça a alguém que não participou da conversa para explicar a escolha, a consequência aceita e o motivo que permitiria revê-la. Se essas três respostas estiverem claras, o registro já oferece uma base melhor para a próxima mudança.

Referências

• Microsoft — Maintain an architecture decision record
• AWS — Architectural decision record process
• AWS — Best practices for using architectural decision records