Documentos de requisitos do produto, reduzidos

Ninguém gosta de escrever documentos de requisitos de produtos enormes e cheios de detalhes. E ninguém gosta de ler um desses, também.

Dan Radigan Dan Radigan
Buscar tópicos

Criar um produto excelente exige muita pesquisa e planejamento abrangente. Mas por onde começar? Os gerentes de produtos costumam começar justamente com um documento de requisitos do produto ou PRD, a sigla em inglês. 

Um documento de requisitos do produto define o produto que você está prestes a criar: 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 busca opiniões) com os interessados, equipes de negócios e técnicas que vão ajudar a criar, lançar ou comercializar seu produto.

Uma vez que todas essas partes estiverem alinhadas, o PRD serve como uma bússola, dando um rumo claro em direção à finalidade do produto, criando uma compreensão compartilhada entre equipes técnicas e comerciais.

Levantamento de requisitos em um mundo rápido

Como é o processo de reunir os requisitos em um mundo ágil? Parece complicado. E é. Mas não se preocupe. A Atlassian sabe tudo sobre a preparação de PRDs em um ambiente ágil. Aqui estão algumas coisas para se 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 oferecer 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 sobre o cliente 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 destravam um nível de informações que fica escondido dos proprietários de produto. Eles podem, então, se concentrar nos requisitos de níveis mais altos e deixar os detalhes de implementação para a equipe de desenvolvimento, que é muito preparada para fazer isso, mais uma vez 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 tem ideia de como começar, tente algumas dessas dicas:

  • Ao fazer entrevistas com clientes, chame também um membro das equipes de design e de desenvolvimento, para que possam ouvir da boca de um cliente em vez de confiar nas observações do proprietário do produto. Isso também vai dar a eles a oportunidade de fazer perguntas mais profundas enquanto o tópico está fresco na cabeça do cliente.
  • Faça com que o desenvolvimento e o uso de personas de clientes seja um esforço de equipe. Cada membro da equipe tem perspectivas e ideias únicas e precisa entender como as personas influenciam o desenvolvimento dos produtos.
  • Faça com que a triagem de itens e a revisão de tarefas também sejam um trabalho em equipe. São ótimas oportunidades para garantir que todos estejam no mesmo ponto e entender por que o proprietário do produto priorizou o trabalho daquela maneira.

Quer tentar? Inscreva-se ou faça login no Confluence >>

Crie um modelo de entrevista para documentar ideias do cliente. Siga nosso tutorial para começar a realizar entrevistas de grande valor com clientes:

Antipadrões que devem ser observados
  • Todo o projeto já está especificado em detalhes antes do início de qualquer trabalho de engenharia
  • Uma análise minuciosa e aprovação sem ressalvas por todas as equipes são necessárias antes que o trabalho comece
  • Os designers e desenvolvedores não sabem quando os requisitos foram atualizados
  • Os requisitos nunca são atualizados (porque todos os aprovaram, lembra?)
  • O proprietário do produto registra os requisitos sem a participação da equipe 

Então tá: você discutiu várias histórias de usuários com seu engenheiro e designer. Aquele vai-e-vem de informações, algumas reuniões, e concluiu que há mais dimensões a considerar para esse recurso no qual está trabalhando. Você precisa eliminar algumas de suas suposições, pensar mais sobre como isso se encaixa no 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 preparar um documento de requisitos, é útil usar o mesmo modelo para toda a equipe, assim todos podem acompanhar e dar feedback. Na Atlassian, usamos o Confluence para criar os requisitos do produto com o modelo do documento de requisitos do produto. Descobrimos que a seção abaixo proporciona exatamente o contexto "suficiente" para entender os requisitos de um projeto e seu impacto nos usuários:

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

  • Participantes: Quem está envolvido? Inclua o proprietário do produto, equipe, interessados
  • Status: qual é o estado atual do programa? Em dia, em risco, atrasado, diferido, etc.
  • Conclusão da meta: para quando o lançamento está programado?
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ários
Liste ou coloque o link das histórias de usuários envolvidas e das entrevistas de clientes, ou mesmo screenshots 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 podem ser considerados depois.

Dica profissional:

O manifesto ágil 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 para trocar ideias 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 tentar? Inscreva-se ou faça o login no Confluence >>

Depois de entrar, escolha o modelo de requisitos do produto e siga o tutorial abaixo para começar a definir seus requisitos:

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

Se você for aprender uma coisa só nesse blog, é a importância de entender o "porquê", e não o "o que", pois o "porquê" vai 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 uma referência como o local de acesso central economiza o tempo dos membros da equipe por meio de 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 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 com clientes para obter informações detalhadas, validação ou contexto adicional para o recurso
  • Páginas ou blogs em que ideias semelhantes foram propostas
  • Discussão anterior ou documentação técnica e diagramas
  • Vídeos de demonstração de produtos ou outro conteúdo relacionado 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 elas em nossa página (o que, muito conveniente, também cria um link dos itens de volta para a página). A sincronização de mão dupla entre o Confluence e o Jira Software significa que 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 dar a sensação de uma equipe pequena.

6. Incluindo "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 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 pensamentos. 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 os dois maiores desafios enfrentados na Atlassian e observados em nossos 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 encorajar as pessoas a comentarem?", "Como posso encorajar 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 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. Manter esses requisitos informativos e breves dá autonomia para a equipe de desenvolvimento usar a implementação que se encaixar melhor em sua pilha de arquitetura e tecnologia.

Assim que os requisitos de um projeto estão bem sustentados, é aconselhável ligar as histórias do usuário na seção 5 acima às histórias correspondentes no rastreador de itens da equipe de desenvolvimento. Assim, o processo de desenvolvimento fica mais transparente: é fácil de ver o status de cada parte do trabalho, o proprietário do produto, consegue tomar decisões mais bem fundamentadas, assim como as equipes que vão trabalhar no mesmo projeto em seguida, como as de marketing e suporte.

Dica profissional:

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

Não se esqueça de ser ágil na evolução dos requisitos de um projeto. Não há problema em alterar as histórias de usuários à medida que a equipe cria, envia e recebe feedback. Sempre mantenha um nível de qualidade alto e uma cultura de engenharia saudável, mesmo que isso signifique lançar menos recursos.