Como criar o documento de requisitos do produto (PRD)

Criar um ótimo produto exige muita pesquisa e planejamento abrangente. Mas por onde começar? Em geral, os gerentes de produto começam com um PRD.

A product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.

Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.

Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

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).

Por outro lado, os requisitos ágeis também dependem de uma compreensão do cliente que é compartilhada entre o proprietário do produto, o designer e a equipe de desenvolvimento. Essa compreensão compartilhada 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.

• Transforme a triagem de tickets e a revisão de tarefas em um trabalho em equipe. Essas são grandes oportunidades para garantir que todos estejam na mesma página e entender por que o proprietário do produto priorizou o trabalho.

Quer testá-lo? Cadastre-se ou faça login 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 essa função na 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 especificações do projeto

Recomendamos que você inclua informações detalhadas 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égicoPor que a gente está fazendo isso? Como isso se encaixa nos objetivos gerais da empresa?

4. Suposições

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

5. Histórias de usuário

Liste as histórias de usuários envolvidas ou crie um link para elas. Além disso, crie links para entrevistas de clientes e inclua capturas de tela do que você viu. Forneça detalhes suficientes para elaborar uma história completa e insira métricas de sucesso.

6. Interação e design do usuário

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.

Aqui está um documento de requisitos de produto totalmente pormenorizado que a gente criou usando o Confluence. Lembre que não há dois requisitos de produto exatamente iguais. Use este exemplo para entender os diferentes elementos que devem ser incluídos no PRD, mas não como a forma definitiva de fazer isso.

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 é como a “página de chegada” de tudo relacionado ao conjunto de problemas em um epic específico. Com um documento único e centralizado, os membros da equipe acessam essas informações com mais rapidez e aproveitam uma visibilidade concisa.

2. Agilidade extra

Uma das maiores vantagens do uso de uma página simples para colaborar (em comparação com uma ferramenta de gerenciamento de requisitos dedicada) é que você pode utilizar a agilidade na documentação. Não é preciso seguir o mesmo formato sempre. Faça o que precisar e quando precisar usando a agilidade. Modifique tudo conforme necessário.

3. Contexto e detalhes suficientes

Muitas vezes, as pessoas se esquecem de como um simples link pode ser poderoso. Incorporamos uma grande quantidade de links nos documentos de requisitos dos nossos produtos. Isso ajuda a eliminar a complexidade e a divulgar aos poucos as informações ao leitor conforme necessário. Uma lista de links para recursos detalhados pode incluir o seguinte:

• 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

Depois de elaborar as histórias em termos gerais e inserir todas elas como tickets no Jira, são criados links para elas na nossa página (para nossa conveniência, isso também gera um link dos tickets de volta para a página). Com a sincronização bidirecional entre o Confluence e o Jira, a gente pode ver em tempo real o status atual de cada ticket direto da página de requisitos.

5. Sabedoria coletiva

Inserir os requisitos do 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 em projetos similares. Isso ajuda empresas grandes a terem a sensação de equipes pequenas.

6. Extras “interessantes”

Diagramas criados com ferramentas como Visio, Gliffy e Balsamiq comunicam melhor os problemas para sua equipe. Também é possível inserir conteúdos dinâmicos, 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. Documentação pode ficar obsoleta

O que acontece quando você implementa uma história, recebe feedback e então modifica a solução? Alguém se encarrega de atualizar a página de requisitos com a implementação final? Esse é um desafio que enfrentamos com qualquer tipo de documentação, e sempre vale a pena questionar se essas compensações são válidas. Converse com sua equipe sobre o que vocês fariam em um cenário como esse.

2. Falta de participação

O que fazer para incentivar as pessoas a enviarem comentários? Como incentivar as pessoas a criarem mais especificações e histórias na sua intranet? Esse é um abacaxi difícil de descascar, mas a resposta pode estar nas várias técnicas de adoção de wiki que você pode usar na sua organização. Há muitos recursos para ajudar você nesse processo. E problemas culturais mais profundos também podem estar em jogo aqui.

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 projeto estão definidos, a gente recomenda vincular as histórias de usuário na seção 5 acima às histórias correspondentes no rastreador de tickets da equipe de desenvolvimento. Com isso, o processo de desenvolvimento se torna 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 um nível elevado de qualidade e uma cultura de engenharia íntegra– mesmo se isso significar menos funções.