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

Criar um ótimo produto exige muita pesquisa e planejamento abrangente. Mas onde você começa? Os gerentes de produtos normalmente começam com um documento de requisitos do produto (PRD). 

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

When writing a requirements document, it's helpful to use a consistent template across the team so everyone can follow along and give feedback. At Atlassian, we use Confluence to create product requirements with the product requirements document template. We've found that the section below provides "just enough" context to understand a project's requirements and its impact on users:

1. Definir os detalhes do projeto
Recomendamos incluir orientações de alto nível na parte superior da página, como segue:

  • 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 sem tédio.

3. Histórico 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 os pressupostos técnicos, de negócios ou de usuário que você pode estar elaborando.

5. Histórias de usuário
Liste ou vincule as histórias de usuário envolvidas. Vincule também entrevistas de cliente e screenshots inclusos do que você viu. Forneça detalhes suficientes para fazer uma história completa e incluir métricas de sucesso.

Histórias de requisitos ágeis | Coach Agile Atlassian

6. Design e interação com o usuário
Após a equipe desenvolve uma solução para cada história de usuário, vincule explorações de design e wireframes à página.

7. Perguntas
À medida que a equipe compreende os problemas que devem ser resolvidos, eles frequentemente têm perguntas. Criar uma tabela de "coisas que precisamos decidir ou pesquisar" para rastrear esses itens.

8. O que  não estamos fazendo 
Mantenha a equipe focada no trabalho à disposição solicitando ajuda quando necessário. Sinalize itens que estão fora do escopo no momento, mas que poderão ser considerados posteriormente.

Pro Tip:

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 nossa 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

Aqui está um documento de requisitos de produto muito detalhado que criamos usando o Confluence. Lembre-se: os requisitos de dois produtos nunca serão exatamente os mesmos. Use esse exemplo para entender os diferentes elementos que devem ser inclusos em seu PRD, mas não como o modo definitivo de fazer isso. 

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

Quer testá-lo? Cadastre-se ou faça login 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
Mantendo simples. O documento de requisitos do produto torna-se a "página inicial" para tudo relacionado 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
Um dos melhores aspectos de usar uma página simples para colaborar (versus 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 precisa, quando precisa e use o método ágil para isso. Elimine e altere conforme o necessário.

3. Detalhes e contexto suficientes
Muitas vezes nos esquecemos quão poderoso pode ser um simples link. Incorporamos vários links dentro de nossos documentos de requisitos do produto. Isso ajuda a demonstrar a complexidade e a divulgar progressivamente as informações ao leitor, conforme necessário. O vínculo de recursos detalhados 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 de vida
Também vejo muitos clientes fazendo isso. Assim que as histórias tiverem sido pensadas e inseridas como problemas no Jira Software, criamos um link a elas em nossa página (que, convenientemente, também cria um link dos problemas de volta para a página). A sincronização de dois modos entre o Confluence e o Jira Software significa que podemos ver automaticamente cada status atual do problema diretamente da página de requisitos.

5. Sabedoria coletiva
Capturar requisitos de produto no Confluence facilita a contribuição e as sugestões de outras pessoas em equipes diferentes. Impressiono-me com as várias vezes que alguém de outra equipe entrou em uma conversa com um comentário que fornecia ótimo feedback, sugestões ou lições aprendidas com projetos similares. Isso ajuda uma organização grande a se sentir como uma equipe pequena.

6. Engajamentos extras
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 é manter todos envolvidos. Nunca escreva um documento de requisitos do produto sozinho – você deve sempre ter um desenvolvedor com você para que escrevam juntos. Compartilhe a página com sua equipe e ouça os feedbacks. Comente, faça perguntas, incentive todos a contribuírem com ideias e pensamentos. Isto é especialmente importante para equipes distribuídas que muitas vezes não têm a chance de discutir projetos pessoalmente.

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, recebe feedback e modifica a solução? Alguém atualiza a página de requisitos com a implementação final? Isso é um desafio para qualquer tipo de documentação, e é sempre bom questionar se essas trocas valem a pena. Converse com sua equipe sobre o que vocês fariam em um cenário como esse.

2. Falta de participação
"O que posso fazer para encorajar as pessoas a comentarem?", "Como posso encorajar as pessoas a escreverem mais especificações e histórias em nossa intranet?". Isso é bem complicado e resulta em várias técnicas de adoção de wiki em sua organização. Há muitos recursos para ajudar você aqui. 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.