Documentos de requisitos do produto, reduzidos

Ninguém gosta de escrever documentos de requisitos de produto muito grandes e com muitos detalhes. E ninguém gosta de usar eles.

Dan Radigan Dan Radigan
Buscar tópicos

Resumo: um documento de requisitos do produto (PRD) define os requisitos de um produto específico, incluindo o propósito, os recursos, 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, seus recursos, funcionalidades e comportamento.

Documentos de requisitos de produtos ágeis | Coach Agile Atlassian

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.

Levantamento de requisitos em um mundo rápido

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

Criando uma compreensão compartilhada entre as equipes

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 problemas e a organização da lista de pendências 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? Cadastre-se ou faça login no Confluence >>

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

Antipadrões que devem ser observados
  • O projeto todo já é especificado muito detalhadamente antes do trabalho de engenharia começar
  • Uma revisão completa e uma conclusão infalível de todas as equipes são necessárias antes mesmo de começar o trabalho
  • Os designers e os desenvolvedores não sabem quando os requisitos foram atualizados
  • Os requisitos nunca são atualizados em primeiro lugar (porque todo mundo concluiu eles, lembra?)
  • O proprietário do produto elabora os requisitos sem a participação da equipe 

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?

Manter os requisitos enxutos com um painel de uma página

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?
Requisitos ágeis | Coach Agile Atlassian

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?

Requisitos de produtos ágeis | Coach Agile Atlassian

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.

Histórias de requisitos ágeis | Coach Agile Atlassian

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.

Dica profissional:

manifesto ágilnos lembra que podemos ser flexíveis com o modo como criamos os requisitos. Algumas equipes fazem exercícios de mapeamento da história do usuário para identificar problemas e soluções. Às vezes, toda a tríade do produto (proprietário do produto, desenvolvedor e designer) visita um cliente e faz reuniões de brainstorm sobre as soluções para um problema específico que o cliente mencionou.

 

Não importa como os requisitos são criados, é importante que a equipe os considere uma de muitas maneiras de definir e comunicar os problemas do cliente. Veja a seção sobre design ágil para saber como os proprietários de produtos podem usar o Keynote e o PowerPoint para simular experiências reais como requisitos. 

Exemplo de um PRD de uma página

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. 

Exemplo de documento de requisitos de produtos | Coach Agile Atlassian
Documento de requisitos de produtos | Coach Agile Atlassian

Quer testar? Faça o cadastro ou entre no Confluence >>

Uma vez dentro, escolha o modelo de requisitos do produto e siga o tutorial abaixo para ajudá-lo a começar a definir seus requisitos:

Principais concessões de uma abordagem de uma página:

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 o recurso
  • 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
Vejo muitos clientes fazendo isso. Depois de pensar nas histórias, elas são inseridas como itens no Jira Software. Então, um link é criado para eles em nossa página (o que, muito conveniente, também cria um link dos itens de volta para a página). Com a sincronização de mão dupla entre o Confluence e o Jira Software, 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.

Desafios

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.

Agora, mãos à obra!

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.

Dica profissional:

Não monitore as histórias de usuário advindas dos requisitos do projeto em um sistema e defeitos em outro. Gerenciar trabalho em dois sistemas é desnecessariamente desafiador e desperdiça tempo.

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.