Como criar o documento de requisitos do produto (PRD)

Resumo: um documento de requisitos do produto (PRD) define os requisitos de um produto específico, incluindo o propósito, as funções, a funcionalidade e o comportamento do produto. O documento funciona como um guia para equipes técnicas e de negócios ajudarem a criar, lançar ou comercializar o produto.

Criar um ótimo produto exige muita pesquisa e planejamento abrangente. Mas por onde começar? Os gerentes de produtos costumam começar com um documento de requisitos do produto (PRD, na sigla em inglês).

Um documento de requisitos do produto define o produto que você está prestes a criar: ele descreve a finalidade do produto, suas funções, funcionalidades e comportamento.

Em seguida, você compartilha o PRD (e procura opinião) com as partes interessadas - equipes de negócios e técnicas que ajudarão a criar, lançar ou comercializar seu produto.

Uma vez que todas as partes interessadas estão alinhadas, o PRD serve como uma bússola, proporcionando uma direção clara em direção à finalidade do produto, criando uma compreensão compartilhada entre negócios e equipes técnicas.

Como o processo de coleta de requisitos se parece em um mundo ágil? Parece complicado - e é. Mas não se preocupe. Na Atlassian, sabemos tudo sobre como criar PRDs em um ambiente ágil. Aqui estão algumas coisas para ter em mente:

Os requisitos ágeis são o melhor amigo de um proprietário de produto. Os proprietários de produto que não usam requisitos ágeis se atrapalham na especificação dos detalhes para fornecer o software certo (depois cruzam os dedos esperando que tenham feito a especificação correta). O requisitos ágeis, por outro lado, dependem de um entendimento compartilhado do cliente que é compartilhado entre o proprietário do produto, o designer e a equipe de desenvolvimento. Esse entendimento compartilhado e a empatia em relação ao cliente fornecem informações ocultas para os proprietários de produto. Eles podem focar-se nos requisitos de níveis mais altos e deixar os detalhes de implementação para a equipe de desenvolvimento, que é totalmente preparada para fazer isso – novamente devido ao entendimento compartilhado. (Boom).

Se estiver animado com a ideia de um entendimento compartilhado, mas não sabe como fazer isso, tente algumas dessas dicas:

• Ao fazer entrevistas com clientes, inclua um membro das equipes de design e de desenvolvimento para que possam ouvir de um cliente diretamente em vez de depender de notas do proprietário produto. Isso também fornece a oportunidade de investigar mais a fundo enquanto o tópico está fresco na memória do cliente.
• Tornando o desenvolvimento e o uso de personalidades do usuário um esforço em equipe. Cada membro da equipe tem conhecimentos e insights únicos e precisa entender como as personalidades influenciam o desenvolvimento de produtos.
• Torne a triagem de itens e a revisão de tarefas um trabalho em equipe. Essas são grandes oportunidades para certificar-se de que todos estão na mesma página e entender por que da maneira como o proprietário do produto priorizou o trabalho.

Quer testá-lo? Faça o cadastro ou entre no Confluence >>

Crie um template de entrevista de cliente para documentar as ideias relacionadas ao cliente. Siga nosso tutorial para começar a fazer entrevistas valiosas com o cliente:

• Crie páginas informativas de entrevista relacionadas ao cliente
• Transforme a informação em insights com a Pirâmide de entrevista do cliente

Tudo bem, você discutiu várias histórias de usuário com seu engenheiro e designer. Executou vários testes, fez sessões de quadro branco e concluiu que há mais dimensões que precisa considerar para esse recurso no qual está trabalhando. Você precisa eliminar algumas de suas suposições, pensar mais sobre como isso se adéqua ao esquema geral das coisas e monitorar todas as questões em aberto que precisa responder. O que vem depois?

Ao escrever um documento de requisitos, é útil usar o mesmo template para toda a equipe, assim todos podem acompanhar e dar feedback. Na Atlassian, a gente usa o Confluence para criar requisitos de produto com o template do documento de requisitos do produto. A gente descobriu que a seção abaixo proporciona exatamente o contexto "suficiente" para entender os requisitos de um projeto e o impacto nos usuários:

1. Defina as especificidades do projeto
A gente recomenda incluir orientações gerais na parte superior da página, da seguinte forma:

• Participantes: quem está envolvido? Inclua o proprietário do produto, a equipe, as partes interessadas
• Status: qual é o status atual do programa? Em andamento, em risco, adiado, diferido, etc.
• Liberação de destino: qual é a projeção de envio?

2. Metas da equipe e objetivos de negócios
Vá direto ao ponto. Informe, mas não chateie.

3. Contexto e ajuste estratégico
Por que estamos fazendo isso? Como isso se encaixa nos objetivos gerais da empresa?

4. Suposições
Liste as suposições técnicas, comerciais ou de usuário que você pode estar fazendo.

5. Histórias de usuário
Liste ou coloque o link das histórias de usuário envolvidas e das entrevistas de clientes, ou mesmo capturas de tela do que você viu. Dê informações detalhadas o suficiente para elaborar uma história completa e inclua índices de sucesso.

6. Interação dos usuários e design
Depois que a equipe apresentar a solução para cada história do usuário, faça o link das explorações de design e wireframes na página.

7. Perguntas
À medida que a equipe compreende os problemas que devem ser resolvidos, muitas vezes surgem perguntas. Crie uma tabela de "coisas para decidir ou pesquisar" para monitorar esses itens.

8. O que não estamos fazendo
Mantenha a equipe focada no trabalho disponível chamando atenção para o que não está sendo feito. Sinalize o que está fora do escopo no momento, mas que pode ser considerado depois.

Este é um documento de requisitos de produto muito detalhado que criamos usando o Confluence. Não se esqueça: os requisitos de dois produtos nunca vão ser idênticos. Use esse exemplo para entender os diferentes elementos que devem ser incluídos em seu PRD, mas não como o modo definitivo de fazer esse documento.

Se quiser aproveitar algo desse blog, entenda o "porquê" – e não o "o que" – pois o "porquê" ajudará você a explorar o que é melhor para a equipe. Aqui estão os benefícios e os desafios que observamos com a abordagem do painel de uma página:

1. Uma página, uma fonte
Mantenha a simplicidade. O documento de requisitos do produto se transforma na "página inicial" para tudo que se relaciona ao conjunto de problemas em um epic específico. Ter algo como o local de acesso central economiza o tempo dos membros da equipe ao acessar essas informações e proporciona uma visão concisa.

2. Agilidade extra
Uma das coisas impressionantes sobre o uso de uma página simples para colaborar (em comparação com uma ferramenta de gerenciamento de requisitos dedicada) é que você pode usar o método ágil em sua documentação! Não é necessário seguir o mesmo formato sempre. Faça o que precisar, quando precisar e use o método ágil para isso. Elimine e altere conforme o necessário.

3. Contexto e detalhes suficientes
Muitas vezes a gente esquece como um simples link pode ser poderoso. Por exemplo, uma grande quantidade de links nos documentos de requisitos do produto ajuda a demonstrar a complexidade e a divulgar aos poucos as informações ao leitor, conforme necessário. Uma lista detalhada de links de recursos pode incluir itens como:

• Entrevistas de clientes para histórico, validação ou mais contexto para função
• Páginas ou blogs nos quais ideias semelhantes foram propostas
• Discussão anterior ou documentação técnico e diagramas
• Vídeos de demonstrações de produto ou outros conteúdos relacionados de fontes externas

4. Histórias vivas
Muitos clientes também fazem isto. Depois de elaborar as histórias em termos gerais e inserir todas como itens no Jira, são criados links para elas na nossa página. Para nossa conveniência, isso também cria um link dos itens de volta para a página. Com a sincronização bidirecional entre o Confluence e o Jira, podemos ver em tempo real o status atual de cada item direto da página de requisitos.

5. Sabedoria coletiva
Coletar os requisitos de produto no Confluence facilita a contribuição e as sugestões de outras pessoas em equipes diferentes. É incrível a quantidade de vezes que alguém de outra equipe contribuiu em outras conversas com comentários que ofereciam um ótimo feedback, sugestões ou lições aprendidas com projetos similares. Isso ajuda uma empresa grande a ter a sensação de uma equipe pequena.

6. "Extras" atraentes
Diagramas feitos com ferramentas como Visio, Gliffy ou Balsamiq comunicam melhor os problemas para sua equipe. Também é possível inserir conteúdo dinâmico, vídeos e imagens externas.

7. Colaboração!
O aspecto mais importante de tudo isso é envolver todos. Nunca escreva um documento de requisitos do produto sozinho. Tenha sempre um desenvolvedor por perto para ajudar nesse processo. Compartilhe a página com sua equipe e ouça os feedbacks. Comente, faça perguntas, incentive todos a contribuírem com ideias e opiniões. Isto é de extrema importância para equipes distribuídas, que muitas vezes não têm a chance de discutir projetos cara a cara.

Há desvantagens em todas as abordagens. Aqui estão dois principais desafios que tivemos e observamos nos clientes:

1. A documentação pode ficar obsoleta
O que acontece quando você implementa uma história, obtém feedback e modifica a solução? Alguém deve atualizar a página de requisitos com a implementação final? Esse é um desafio para qualquer tipo de documentação e sempre vale a pena questionar se essas compensações valem a pena. Converse com sua equipe sobre o que você faria em um cenário como este.

2. Falta de participação
"O que posso fazer para incentivar as pessoas a comentarem?", "Como posso incentivar as pessoas a escreverem mais especificações e histórias em nossa intranet?". Esse é um abacaxi difícil de descascar, e a resposta pode estar nas várias técnicas de adoção de wiki em sua empresa. Há muitos recursos para te ajudar nisso. Também pode haver problemas culturais mais complicados.

Quando requisitos são ágeis, o proprietário do produto tem mais tempo para compreender e acompanhar o ritmo do mercado. E informar de modo breve possibilita que a equipe de desenvolvimento use a implementação que se encaixar melhor em sua pilha de arquitetura e tecnologia.

Assim que os requisitos de um produto estão razoavelmente definidos, recomendamos vincular as histórias de usuário na seção 5 acima às histórias correspondentes no rastreador de problemas da equipe de desenvolvimento. Isso torna o processo de desenvolvimento mais transparente: é fácil de ver o status de cada parte do trabalho, o que facilita a tomada de decisões mais informadas pelo proprietário do produto, bem como favorece as equipes, como as de marketing e suporte.

Lembre-se de usar o método ágil em seu desenvolvimento dos requisitos para um projeto. Não há problemas em alterar as histórias de usuários à medida que a equipe cria, envia e recebe feedbacks. Sempre mantenha uma barra de alta qualidade e uma cultura de engenharia íntegra– mesmo se isso significar menos recursos.