O que é um documento de requisitos do produto (PRD)?

Um resumo do documento de gestão do produto protótipo

>br> Kenton Kivestu, ex-Google, ex-BCG, Fundador da RocketBlocks br>>p>p>Publicado: 11 de Setembro de 2019 | Última actualização: 8 de Novembro de 2019>br>

PRD básico | Conteúdo do PRD | PRD walkthrough | PRD exemplo completo

A PRD é um conjunto estruturado de directrizes para o que um produto (ou característica) deve ser.

Ultimamente, as PRD são os goldenilocks dos documentos de desenvolvimento de produto: não pode ser demasiado tarte no céu (por exemplo, um comunicado de imprensa) nem pode ser demasiado técnico (por exemplo, um plano de implementação de engenharia detalhado).

P>Assim, uma forma útil de pensar num PRD é o documento-ponte que pode tomar a visão de alto nível do produto e defini-lo e ampliá-lo o suficiente para que um engenheiro possa escrever um plano de implementação credível fora dele.

Por que é que as empresas se preocupam em escrever PRDs? Os PRD servem como um artefacto fundamental que estabelece a razão de ser de um produto / característica, respondendo a perguntas fundamentais: Porque devemos construí-lo? Que problema irá resolver? Como é que deve ser? Como será o sucesso?

Quais as empresas que usam PRDs e quem os escreve? (Início)

Adicionalmente, a nomenclatura preferida varia de empresa para empresa (e por vezes até de equipa para equipa!). Por exemplo, Google refere-se historicamente a estes documentos como PRDs, enquanto a empresa de jogos Zynga se refere a eles como especificações, o que é abreviatura para especificações de produtos.

Finalmente, os gestores de produtos são frequentemente os autores de PRDs, mas não é verdade em todos os casos. Em particular, em pequenas empresas e startups, um PRD pode ser escrito por um Fundador, CTO, líder de engenharia ou outro líder que ajude no desenvolvimento do produto. Mas, independentemente de quem seja o autor de um PRD, o contributo de membros-chave da equipa multifuncional é fundamental para produzir um bom PRD.

Que secções e conteúdos devem ser incluídos num PRD? (Início)

As equipas que usam PRD tendem a estabelecer-se numa lista de secções “must have” num PRD que fazem sentido para o tamanho da sua organização, cadência de lançamento, fase do produto e complexidade. Aqui centrar-nos-emos num punhado de secções “habitualmente suspeitas” que são normalmente incluídas em muitos PRDs:

• Contexto & lógica: porque estamos a construir isto?
• Metas & métricas de sucesso: qual é o objectivo concreto de fazer isto?
• Casos de utilização: que casos de utilização específica deverá isto permitir?
• Requisitos: o que precisa de ser construído?
• Perguntas abertas: que perguntas precisam de ser respondidas antes de podermos começar?

p>Para rever cada uma destas secções de PRDs, imaginaremos que estamos a escrever um PRD para uma pequena adição à aplicação móvel Uber rider-facing. Imaginemos que estamos a escrever um PRD para adicionar um pequeno pedaço de texto descritor à página Uber mostra aos cavaleiros quando estes abrem a aplicação após uma viagem completa (imagem de ecrã abaixo).

Exemplo PRD: Uber rider-facing app updates (Topo)

Agora, vamos saltar e caminhar através de cada secção e imaginar como poderia ser um PRD abordando esta questão.

Secção 1: Contexto & racionale

Esta secção deve apresentar o contexto central que ilumina a razão pela qual uma característica ou produto em particular está a ser considerado. Pode incluir anedotas da equipa de apoio, observações da investigação UX, dados de apoio ao mercado ou insights da equipa sobre a direcção que o produto precisa de evoluir.

Dependente da cultura da equipa e do âmbito da característica, esta secção pode ser bastante curta ou longa. Algumas organizações adoram realizar análises detalhadas e altamente quantitativas que justificam a característica.

Para a nossa amostra Uber PRD, podemos imaginar algo como:

Sessões recentes de pesquisa de utilizadores mostraram que muitos pilotos saltam frequentemente a classificação do seu condutor neste ecrã porque não se conseguem lembrar qual o condutor que estão a classificar (por exemplo muitos condutores nunca vêem o seu condutor cara a cara, uma vez que estão na parte de trás).

Desde que as classificações dos condutores são um conjunto de dados importante para os nossos algoritmos e operações, qualquer “empurrão” que possamos dar aos utilizadores para classificar os condutores terá um impacto importante e agravante no negócio.

Secção 2: Objectivos & métricas de sucesso

P>Próximo, a secção de objectivos irá, sem surpresa, definir o(s) objectivo(s) específico(s) a ser(em) alcançado(s) pelo recurso/produto. Enquanto a secção de contexto pintará um quadro das razões pelas quais a equipa poderá pensar que o esforço é importante, a secção de objectivos deverá colocar uma aposta específica no terreno sobre como a empresa / equipa / produto irá beneficiar e como o medir.

Retrocedendo ao nosso Uber PRD, a secção de objectivos poderá parecer:

Disponibilizar um aumento de 5% nos condutores de classificação de pilotos quando confrontados com este ecrã de classificação de pilotos.

Secção 3: Casos de utilização

Casos de utilização explicam como os clientes irão interagir com as alterações de características propostas. O objectivo é descrever o contexto específico em que os clientes irão experimentar a funcionalidade e como isso irá ajudar os clientes a completar tarefas específicas.

Again, regressaremos ao nosso ecrã de classificação de Uber ride-completion exemplo:

Travis tomou recentemente um Uber no final da noite de sexta-feira, depois de ter conversado com os amigos. Ele só volta a usar Uber na próxima quarta-feira durante um dia de trabalho atarefado, altura em que abre a aplicação e vê a classificação de conclusão da cavalgada de sexta-feira à noite. Ele não se lembra da última vez que pegou num Uber e não reconhece o condutor. Como resultado, ele pressiona o botão “Skip” em vez de classificar o condutor.

Secção 4: Requisitos

Esta pode ser considerada a “carne” de um PRD, onde o que está realmente a ser construído será delineado. Dependendo da característica ou produto em questão, esta secção poderia incluir wireframes de características, maquetes de fidelidade total, detalhes sobre que alterações terão de ser feitas no front end (por exemplo, aplicações móveis) e/ou back end (por exemplo, bases de dados, processamento, etc.).

Vejamos o que isto poderá parecer para o exemplo Uber:

Front-end

• Exibir um novo snippet de texto descritor abaixo do alerta de classificação actual
• Copy (exemplo): “A sua boleia de sexta-feira à noite”

API

Ao solicitar os detalhes da boleia (por exemplo, condutor, imagem do condutor, etc.), pegue também no descritor de boleia (não é necessário construir nenhuma nova lógica aqui, basta usar os mesmos descritores de boleia que já colocamos nos sujeitos de recibos de boleia enviados por correio electrónico, em vez de carimbos temporais específicos).

Secção 5: Perguntas abertas

Finalmente, as perguntas abertas são uma espécie de secção usada como “parque de estacionamento” para levantar questões que o autor precisa de investigar, tomar uma decisão ou obter feedback antes de considerar o PRD concluído.

De que cor e tamanho deve o texto descritor estar no ecrã? Cc @design – pode recomendar os parâmetros certos aqui?

Como são granulares os descritores de viagem que são gerados (por exemplo são mais específicos do que, digamos, sexta-feira à noite?)

Se esta funcionalidade não produzir os resultados desejados, que próximos passos devemos considerar?

Conjuntando tudo: um exemplo completo de PRD (Topo)

Se colocar tudo o que discutimos em conjunto, acabará por obter um documento que se parece com o que se segue (link para documento fictício aqui). NOTA: Este é *não* um PRD Uber real – é um exemplo representativo e fictício baseado num cenário plausível.

Even uma característica extremamente simples como a detalhada poderia gerar um PRD em excesso de uma página! Como pode imaginar, características mais complicadas podem acabar por gerar PRD muito, muito mais tempo do que o exemplo aqui discutido.

Sumário: pensamentos finais sobre o PRD

O que analisámos acima é um retrato representativo de como é um PRD hoje.

Como mencionado, é uma amostra representativa, mas deve fornecer uma ideia precisa do aspecto de um PRD. No entanto, não se surpreenda se vir diferentes formatos ou diferentes tipos de conteúdo incluídos (por exemplo, uma secção de estimativas de trabalho de um líder de engenharia sobre quanto tempo demorará a construir, etc.). Por exemplo, aqui está um grande modelo de PRD elaborado por Kevin Yien, um líder de produto na Square.

Finalmente, plataformas de comunicação modernas e ferramentas de produtividade como Slack, Google Docs, Notion, Quip, Office Online, Dropbox Paper, Asana, terão um impacto significativo na evolução dos PRD nas próximas décadas. Já vimos os PRDs evoluir para se tornarem documentos “vivos” que identificam os principais contribuintes, solicitam comentários e feedback em linha e incorporam dados adicionais (por exemplo, tabelas, capturas de ecrã, etc.).

No entanto, com tudo o que foi dito, uma coisa chave não mudará: a necessidade de um tipo de documento de produto para alinhar as partes interessadas, servir como um projecto de alto nível e traduzir a visão em requisitos concretos do produto.