A especificação de produto precisa urgentemente de uma renovação.
O problema não está na documentação em si, mas em como materializamos e comunicamos a solução do produto que queremos construir.
Eu não acho que o Product Manager seja o dono da solução, mas entendo que o Designer esteja mais próximo desse papel do que o PM. Contudo, o PM descreve O QUE iremos resolver e não o COMO, embora ele possa participar desse processo. Mesmo assim, ainda insistimos em tentar escrever documentos enormes que nos trazem uma impressão de que estamos no controle, mas na verdade é uma percepção falsa.
O problema com as especificações tradicionais
Nós temos uma série de formatos de documentos e estruturas de escrita de especificação no mercado: PRDs (Product Requirements Document), MRDs (Market Requirements Document), BRDs (Business Requirements Document) por exemplo, que podem ser usados por nós como bons templates para centralizar informações sobre um produto ou feature. Mas, entendo que esses formatos perderam seus propósitos originais.
Outro ponto é onde e como escrevemos esses documentos. Dependendo do sistema de gestão que você utiliza, não é possível criar uma base de conhecimento bem conectada, ou pior, pode ser que esses documentos não sejam acessíveis pra maioria das pessoas da empresa.
Embora o formato, estrutura, serviço que usamos para manter essas especificações possam ajudar até certo ponto, elas geralmente:
Demoram muito para serem escritas;
Raramente são lidas pela equipe;
Não fornecem todos os detalhes necessários;
Não abordam as questões mais difíceis ou informações críticas;
Não são atualizadas na frequência e na qualidade que deveriam;
O mais preocupante é que a mera existência desses documentos serve como um falso indicador para a gestão e para o time de que tudo está progredindo bem.
Os fundamentos de uma boa especificação
Este post é apenas para assinantes pagantes
Cadastre-se agora e atualize sua conta para ler o post e ter acesso à biblioteca completa de posts exclusivos para assinantes pagantes.
