Por que as suas decisões de produto continuam sendo contestadas

Uma equipe de produto passa duas semanas avaliando se deve criar um aplicativo móvel nativo ou um aplicativo web progressivo (PWA). Eles pesquisam as opções, consultam a engenharia sobre a viabilidade, analisam os dados dos usuários e decidem pela abordagem de PWA com base em um conjunto específico de restrições. A decisão é discutida em vários tópicos do Slack, debatida em uma reunião e confirmada em uma mensagem de acompanhamento. A implementação começa.

Três meses depois, um novo VP entra na empresa. Ele pergunta: "Por que estamos fazendo um PWA em vez de um aplicativo nativo?" Ninguém consegue apresentar os argumentos rapidamente. Os tópicos do Slack já sumiram no histórico. A reunião não foi gravada. A mensagem de acompanhamento está enterrada em um canal com milhares de mensagens. Então, a discussão recomeça. Os mesmos argumentos são apresentados. A mesma análise é conduzida. A mesma conclusão é alcançada, duas semanas depois, após consumir o tempo das mesmas pessoas (menos as que saíram) e do novo VP que motivou a reabertura do caso.

Esse padrão de re-discussão é uma das ineficiências mais comuns e mais caras nas organizações de produto. Ele desperdiça tempo, frustra a equipe e atrasa o trabalho que depende de a decisão permanecer consolidada.

Por que isso acontece

As decisões costumam ser boas. Os argumentos costumam ser sólidos. O problema é que esses argumentos não foram preservados em um formato que possa ser encontrado quando a pergunta surgir novamente.

As decisões de produto são normalmente tomadas por meio de uma combinação de discussões no Slack, reuniões e conversas informais. Cada canal captura uma parte do raciocínio, e nenhum deles preserva o cenário completo de forma pesquisável e persistente. A decisão fica distribuída em três tópicos do Slack, duas reuniões e um Google Doc que foi compartilhado, mas nunca arquivado em um local acessível.

Quando alguém pergunta "por que decidimos isso?", a equipe não consegue dar a resposta rapidamente porque reuni-la exige pesquisar em vários canais, reconstruir a linha do tempo e lembrar qual discussão aconteceu onde. O atrito para encontrar os argumentos é tão alto que muitas vezes é mais fácil discutir tudo de novo do que pesquisar.

Registros de decisão como a solução

Um registro de decisão que captura cada decisão importante de produto com seus argumentos, alternativas e restrições evita re-discussões ao tornar a resposta instantaneamente localizável.

O formato é simples: qual era a questão, quais opções foram consideradas, o que foi decidido, por quê e o que precisaria mudar para que a decisão fosse revista. Quando o novo VP pergunta "por que PWA em vez de nativo?", a equipe o direciona para o registro de decisão. O VP lê os argumentos, entende as restrições e aceita a decisão ou traz uma nova consideração que a equipe original não tinha. De qualquer forma, a re-discussão que teria consumido duas semanas é reduzida a uma leitura de quinze minutos.

O desafio é criar registros de decisão de forma consistente, e é aí que a documentação autoescriturável faz a diferença. Quando o sistema captura o tópico do Slack onde a decisão do PWA foi debatida e a reunião onde ela foi confirmada, gerando um registro de decisão estruturado a partir dessas fontes, o log é criado sem que ninguém precise escrever um documento separado. A decisão foi tomada no fluxo de trabalho normal da equipe. A documentação foi gerada a partir desse fluxo.

O benefício composto

Os registros de decisão tornam-se mais valiosos à medida que se acumulam. Após seis meses, a equipe tem um arquivo pesquisável de decisões e seus argumentos. Após um ano, eles têm um registro abrangente de como o produto evoluiu e por quê. Novos membros da equipe podem ler o histórico de decisões para entender não apenas o que o produto é, mas como ele chegou a ser assim, que é o contexto que os impede de propor mudanças que revisitem assuntos já resolvidos.

O registro de decisão também melhora a qualidade da tomada de decisão ao longo do tempo, pois cria responsabilidade pelos argumentos apresentados. Uma decisão documentada com sua justificativa pode ser avaliada retrospectivamente: o raciocínio era sólido? As restrições eram precisas? Tomaríamos a mesma decisão hoje? Esse tipo de prática reflexiva é impossível quando as decisões e seus argumentos se perdem poucas semanas após serem tomadas.

Perguntas frequentes

O que conta como uma decisão "importante" que vale a pena registrar? Qualquer decisão que afete a direção do produto, arquitetura, priorização ou escopo e sobre a qual você espera que alguém pergunte mais tarde. Se um novo membro da equipe provavelmente perguntaria "por que é assim?", o raciocínio deve ser documentado. Decisões de implementação do dia a dia não precisam de registros.

Isso não desacelera a tomada de decisão? Quando os registros de decisão são gerados automaticamente a partir de discussões existentes, não há custo de tempo adicional. A equipe toma decisões da mesma forma que sempre tomou (Slack, reuniões, documentos). O registro acontece como um subproduto.

E quanto às decisões que precisam ser revistas porque as circunstâncias mudaram? O registro de decisão deve incluir "o que precisaria mudar para que isso fosse revisto". Quando essas condições forem atendidas, reabrir a decisão é apropriado e o registro fornece o ponto de partida. Isso é diferente de re-discussão, que é reabrir uma decisão sem novas informações.

Leitura recomendada: Como construir uma base de conhecimento de produto, Sua base de código está documentada, mas suas decisões não, Dívida de documentação. Páginas relacionadas: Registro de decisão, Documentos autoescrituráveis, Para gerentes de produto.