标准化产品需求文档逻辑思路

PRD被公认为产品经理的标准文档，但你写PRD文档时是否做过这些事：

1、下载模版，填入内容；

2、不了解的章节内容，略过或删掉；

3、找己经做好的PRD，做内容替换。

以前我所在的公司，PRD管理不太好。常常使用上一个迭代，或其它产品团队的PRD模版，做内容替换。

按理解删减，严重的就只留下产品功能的内容。结果是需求没有可读性，长篇大论，甚至需求遗失，团队沟通成本极高，项目延期严重。

我们都说产品PRD是没有人看的，但对于大型项目PRD有着重要的地位，如果对PRD理解不够，应付了事，在项目开发过程中会造成极大的损失。

PRD是什么

MRD文档表达的是做什么，PRD是MRD的延续，只一个表达主题是：产品怎么做。

PRD文档是市场想法落地设计方案的文档，是承上启下的重要文档。尤其在开始过程中，是开发人员的重要参与文件。

因此在产品实现过程中，PRD的重要性不言而喻。对于PRD文档，我们必定明确：

01

谁看这PRD文档

PRD的读者包含但不仅限于以下角色：产品总监、研发、UI、测试、相关产品团队（含硬件团队）、运营、客服。

最常关注的读者是：UI、测试、开发

02

PRD文档怎么写

PRD文档没有模板

适合的就是最好的，适合自己团队的文档需要产品经理做内容规划。

现在项目开发，多采取敏捷模式，提倡过程中文档的合适数量。因些，很多公司对PRD形式没有特殊要求。

这时，产品经理要制作合适团队的PRD文档，大公司的模版不一定适用小公司。

 

例如，有的团队研发能力强，配合度高，团队有长期磨合经历。无需过多表达就能理解产品经理的隐性需求，PRD当然可以不写，当然，这是项目规模不太大的情况下，对于大型项目，还是建议产品经理要制作正式的PRD文档。

同样的，合作度高的团队，他们的PRD文档，也许并不合适其它团队用，解释很久可能还要返工。

团队合作情况、项目状况。这些都是形成恰当PRD文档的参考因素。

可以参考Volere产品需求模板

虽然，前面说没有标准的团队PRD文档。但有没有一个规范的PRD模板文件，能够让我们对内容按需调整，形成自己的PRD文件呢？

这里给大家介绍一个极全面的一个PRD文档模板，Volere需求模板。大家可以利用这个模板，进行调整。我收集了很多模板，就是这个是最全面的了，这里分享给大家。

整体概览如下，后面对每个章节分解说明：

1、基本结构

先从前说起，一个需求文档，最前面的内容通常是产品相关信息介绍。但很多产品经理只重视“产品功能”描述，对其它信息空着，或随便填充内容，是一种误区。

文档是沟通用的，我们认为不言而喻的事，别人未必十分清楚。所以对于前面的内容，也应该有必要的关注。

A.        项目驱动

这部分内容表达了构建新产品的根本理由。

它描述了客户面对的业务问题，解释了产品将如何解决该问题，一定程度上可以展示公司和团队形象。

其中有两部分内容：项目目标和利益相关人

项目目标：描述我们希望产品做什么，以及它将为工作的整体目标带来什么好处。

这里的内容不用太长，简短地解释项目目标，通常比长而杂乱的论述更有价值。

 

利益相关人：描述了产品干系人，即与产品有利益关联的人。

这部分的内容可以让产品经理花时间确定与产品利益相关的人，不知道他们的后果可能非常严重。项目开发过程中，上线后，忽略与产品有利益关系的人，产品经理会掉入自挖的坑中。

B.        项目限制条件

这部分主要是描述对产品最终设计的可能形成限制的条件。

它们限制了你能做的事，从而塑造了产品。限制条件像其他类型的需求一样，需要有描述、提出的理由和验收标准。

 

例如，这个限制条件：产品的运行环境应在移动设备中

C.        功能需求

l  工作的范围

工作范围描述了产品中包含的业务领域的边界，工作上下文范围图明确了产品要完成的业务边界。

 

l  业务用例

详细确定业务用例( BUC)对的响应过程，当用户发起产品任务时，应执行的详细业务响应流程，这里是发现详细需求提供基础。

这部分的内容非常的多，也是产品经理主要完成的内容

 

l  业务数据模型和数据字典

例如：

地区气象产品的类：

在这个模型中，每个矩形代表业务数据的一个类。该类的属性在数据字典中定义

 

2.数据字典

数据字典确定下面的内容。

1.数据模型中的类。

2.这些类的属性。

3.这些类之问的关联。

4.所有模型的输入和输出。

5.输入和输入中的数据元素。

3.产品的范围

这部分的内容主要是用例图，它确定了用户与产品之间的边界。

 

Ø  产品用例清单

这部分描述产品中包含的所有用例，并能够确定用例中的输入和输出数据。

 

Ø  单个产品用例

对产品用例清单中的单个产品用例描述细节。包含每个产品用例的场景或模型。

例如

1.文本场景描述。

2.故事板。

3.低保真原型。

4.高保真原型。

5.正式的用例规格说明书，包括异常和可选场景。

6.序列图、活动图、数据流图或项目团队熟悉的其他类型的模型。

4.功能需求

每项需求的详细说明，是最细节的功能内容。

写这部分内容时，建议大家用表格一块块去，我尝试过很多次。表格式的详细需求，可读性是最强的。

 

A.        非功能需求

这部分包含了与产品质量相关，用户体验的所有需求。对于产品的体验性需求都记录在这部分中。

这里的内容重点是需求的可验证，也就是产品实现后，能够对这里的功能进行测试。

 

B.        项目问题

这部分主要描述产品的现阶段存在的问题：如：己经被提出但没有答案的问题、产品可以即刻使用的解决方案、产品出现的新问题、产品开始进度总体计划、费用风险和产品培训等问题。

这部分的内容是动态添加的，因为在产品开发过程中，产品所处的环境是随时在发生着变化的。