Articles

O que é um documento de requisitos do produto (e porque precisa de um)?

Imagine que é um chefe de cozinha num restaurante de luxo. Uma noite, chega um cliente muito importante (digamos Meryl Streep) e pede massa – mas não dá outros detalhes. Entra em pânico. O suor começa a juntar-se sob o seu toque de branquinha. Se desiludir Meryl Streep, fica sem emprego. Mas ninguém lhe dirá que tipo de massa ela quer.

Este cenário imaginado ilustra porque é que um documento de requisitos de um produto é tão importante: É escrito pelo gestor do produto e detalha o que precisa de ser construído, para quem é, e como beneficia o utilizador final. É a diferença entre ser dito para cozinhar massa e ser dito para fazer esparguete à bolonhesa.

Saiba que outros benefícios pode obter ao criar um documento de requisitos do produto e veja como começar.

O que é um PRD?

Um documento de requisitos do produto define completamente o objectivo de um produto ou característica e explica o que o produto deve incluir. Sem este documento muito importante, a sua equipa tem quase a certeza de falhar porque não tem ideia do que será considerado uma construção bem sucedida.

Um PRD mantém todos na mesma página: Ninguém deve ter quaisquer perguntas sobre o que é o produto ou o que é suposto alcançar após a leitura do PRD. Define objectivos e orientações muito claros para um produto e mostra como as características de um produto satisfazem as necessidades do utilizador.

O que não é um PRD?

Não há vergonha nenhuma em confundir um PRD com um BRD – há demasiados acrónimos no mundo. Mas um PRD é definitivamente diferente de outros documentos com os quais se pode estar mais familiarizado.

Documento de requisitos empresariais (BRD)

Um documento de requisitos empresariais posiciona o produto no contexto da sua organização como um todo. Descreve o que um novo produto deve fazer e detalha as necessidades e expectativas do utilizador, a razão pela qual esta solução é necessária, e quaisquer restrições que possam afectar uma implementação bem sucedida. Não entra nas especificações do produto ou como deve ser ou actuar.

Documento de requisitos de software (SRD)

Um documento de requisitos de software entra nas porcas e parafusos do software que alimenta o seu produto. Inclui detalhes sobre interfaces, requisitos de segurança, capacidades funcionais, níveis de desempenho, e informação relacionada. Estes documentos destinam-se a programadores, testadores, engenheiros, e clientes.

Por que precisa de um documento de requisitos do produto

O PRD é a visão para o produto. Sem uma visão, o que há para trabalhar?

O documento de requisitos do produto também mostra como os objectivos do produto serão alcançados com diferentes aspectos do produto. Este documento será utilizado por várias equipas da sua empresa para ajudar a descrever o produto às partes interessadas, ajudar a sua equipa de vendas a poder lançar o produto de uma forma convincente para que possam vendê-lo e enriquecer, e os seus designers saberão como deve ser e como deve agir. É essencialmente um projecto para o seu produto.

Então, precisa de um PRD? Absolutamente. Tal como um fabricante de automóveis precisa de um plano para um carro antes de começar a construí-lo.

O que deve ser incluído no seu PRD

Porque este documento irá tocar no design, apoio, vendas, marketing, e equipas de engenharia, há alguns itens que são padrão a incluir.

O objectivo-chave

O objectivo-chave deve explicar para quem está a construir o produto, para que pontos de dor do cliente espera resolver, e como este produto se enquadra nos seus objectivos e visão como empresa. Esta secção poderia também incluir casos de uso potencial.

Antes de começar a elaborar o seu documento PRD, é importante que reúna a Voz do Cliente. Imagine que se propunha a construir um produto sem fazer qualquer pesquisa de clientes, e verificou-se que os seus clientes não queriam que ele se sentisse nada como uma aplicação das redes sociais. Está a preparar-se para construir um produto que preenche uma necessidade, por isso precisa de saber quais são essas necessidades. Quando compreender o que os seus clientes querem, poderá então explicar como o seu objectivo-chave para o produto satisfaz esses desejos.

Data de lançamento desejada

Terá provavelmente múltiplas datas de lançamento para vários componentes ou iterações do produto, especialmente se estiver a utilizar a metodologia ágil. No seu PRD, irá detalhar os prazos para os componentes-chave do projecto. Uma vez definido, os gestores de projecto podem começar a construir âmbitos e cronogramas e depois colocá-los em sprints.

Características do produto

Definir as características do seu produto para que as pessoas saibam o que devem construir. Em relação aos seus principais objectivos, esta secção deve detalhar qual é a finalidade de cada característica e qual o problema que espera resolver.

Por exemplo, digamos que está a fazer uma aplicação de mercado para vender e comprar roupa – quer incorporar toda a diversão das redes sociais com a excitação de pontuar roupa fixe por menos. No seu PRD, terá então a descrição de como será a sua alimentação em casa e mostrará como satisfaz o requisito de se sentir como um envolvimento das redes sociais. Também poderá então ter uma descrição do correio de um artigo com o preço original em contraste com o preço “para venda” e provar que cumpre o requisito de pontuar roupas fixes por menos dinheiro. Desta forma, cada elemento tem uma finalidade calculada.

Tambem deve ser capaz de detalhar como o utilizador irá interagir com a aplicação: Terá um pergaminho infinito, haverá uma funcionalidade de câmara incorporada, e haverá uma forma de bloquear facilmente os utilizadores problemáticos? Tudo isto deve ser definido no seu PRD.

O seu documento de requisitos do produto deve também incluir critérios de lançamento, objectivos que deve atingir antes de lançar o produto. Criar critérios de lançamento em torno:

  • Funcionalidade mínima
  • Utilidade, medida através de testes do utilizador
  • Reliabilidade
  • Desempenho e velocidade
  • Suporte

Considerar ferramentas tais como uma árvore de qualidade crítica para ligar as necessidades do cliente aos requisitos do produto.

P>Aprender mais

Fluxo de utilização e design

Design é, obviamente, visual. É aqui que vai querer incorporar wireframes de páginas e maquetes de desenhos para ajudar os outros a ver o que está a imaginar para o aspecto e a sensação do site.

annotated login or sign-up page wireframe
Annotated Login or Sign-up Page Wireframe (Clique na imagem para modificar online)
exemplo de wireflow da aplicação bancária
Bank App Wireflow Exemplo (Clique na imagem para modificar online)

Métricas de desempenho

Se ainda não definiu como será determinado o desempenho do seu produto, não há forma de saber se é um sucesso ou um fracasso. O seu produto deve ter um rastreador de características que determine quais as características do seu produto que estão a ser mais frequentemente utilizadas para ajudar a avaliar quais os componentes do seu produto que têm mais sucesso. Este tipo de rastreio ajuda-o a melhorar o seu produto no futuro. Os indicadores de desempenho podem incluir a frequência com que cada característica é utilizada, quanto tempo os seus utilizadores passam a interagir com as características, como os utilizadores navegam nos fluxos de trabalho, etc.

Quantificar o sucesso de cada característica. Por exemplo, poderá dizer “Acreditamos que a nossa integração Apple Pay será utilizada por 40% dos utilizadores”. A partir daí, tem uma forma numérica de determinar se estava ou não correcto e se a funcionalidade foi ou não um sucesso.

Utilize uma hipótese para cada uma das suas funcionalidades, incluindo uma hipótese quantificável que pode ser revisitada após o lançamento para determinar o sucesso ou o espaço para melhorias. Poderá descobrir que algumas características podem ser totalmente abandonadas.

Trabalho futuro antecipado

As análises acima referidas podem ajudar a determinar melhorias no futuro. Mas também pode ter ideias de como deseja que o produto evolua ao longo do tempo. Esse trabalho futuro deve ainda ter em mente as necessidades dos clientes. Nesta secção, é importante manter as suas ideias de alto nível – pode obter mais granular no futuro.

Felizmente, existem modelos de documentos de requisitos do produto que retiram as conjecturas do processo. Crie um modelo a partir da informação que fornecemos e personalize-o de acordo com as necessidades da sua empresa.

Lucidchart é excelente para a criação de wireframes, maquetes, estruturas de trabalho, linhas de tempo, e outros elementos visuais que o ajudam a explicar os requisitos do produto. E podem ser facilmente adicionados ao seu PRD usando as nossas integrações com G Suite, Microsoft Office, Atlassian, e outras plataformas. Inscreva-se hoje para uma conta grátis.

Ver porque é que o Lucidchart é um espaço de trabalho ideal para criar wireframes e explicar os requisitos do produto.

Saiba mais

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *