prd是什么意思

据说产品经理有三个证件：brd，mrd，珠三角。在日常工作中，很多产品的方向已经被领导定了，所以编制brd和mrd的机会比较少，产品细化中使用的prd更常用。

珠三角在项目中扮演什么角色？什么是好的珠三角？怎么写prd？本文将依次回答相应的问题，如有错误或遗漏，请给出建议。

01

prd作用：要你有什么用？

prd是一个将产品需求和相应的需求解决方案放在一起的文档。文档面对与项目相关的各种角色，并在项目推广中发挥重要作用，例如：

1)产品：根据prd公布方案，作为比较终检验产品实现程度的依据；

2)设计：根据prd的原型作为ui设计的参考；

3)发展：按照珠三角的制度规则等。作为研发的基础；

4)测试：按照prd规则编写用例和测试；

根据需求的覆盖面，还会涉及到其他角色，比如运营、商务、金融等。无论面对谁，比较终目标都是为了让团队成员能够理解业务，在产品研发过程中得到更好地执行。

02

prd要求：想要我怎样？

为了让珠三角更好地运作，编写文档时需要清晰、完整且容易阅读的方式将复杂抽象的解决方案呈现出来.我们如何才能达到这个效果？文件至少必须满足以下要求：

1)场景完整:需要考虑与需求相关的各种业务场景，尤其是特殊场景的响应机制。避免场景缺失造成的方案漏洞。

2)框架清晰:提供系统架构、业务模式、功能结构、系统流程等一系列框架，帮助会员从视角了解系统概况。

3)逻辑自洽:系统运营涵盖正向和反向业务流程、主流程和分支流程，形成系统运营无冲突的闭环。

4)规则简明:描述系统全局描述、功能模块、非功能需求等规则。并使它们变得流行和完整。

5)设计友好:系统页面的布局、导航、交互、文案等交互动作都要按照尼尔森的可用性原则进行设计。

根据具体情况，编制珠三角时会有其他要求。比如非功能性需求(数据索引需求、运营需求等)。)应明确定义无异议。

03

prd编写：注意你的尺度！

知道了珠三角的需求，在编制的时候就可以贴近需求了。但是要求只能作为指导思想，并没有告诉我们具体怎么写。你可能还有这些疑问。

01

prd要用什么形式呈现？

prd有两种常见形式：——word和原型。两种形式各有利弊。比如目录的word版本，更容易概览全局；原型在描述功能需求时更加灵活。

那样的话，首先要看公司制度。如果有相应的规范，我们可以直接实现(规范也可以调整)。如果公司不要求，产品经理将与团队和采用大家认可的、更方便表达和阅读的方式即可。沟通

02

prd要写到什么颗粒度？

写过珠三角的同学应该都有过这个问题。尤其是对于规则的描述，写厚了怕遗漏，写薄了怕没人看。除了描述上精简用词，还能从规则提炼和原型设计上进行把控。

1)规则细化：常规规则和可重用规则用“全局描述”来描述。比如手势操作，输入框的定义和限制等。

2)原型设计：输出原型不要有高保真原型，耗时，影响ui播放；不具备复杂的交互，不利于快速识别，但可以在备注中说明；不要过度设计.

03

prd由哪些部分组成？

总结以往项目的prd的常用部件，从一般、一般、细节部分拆解，仅供参考。每份prd的具体组成需要项目结合实际情况进行增删。

1)通用部分：名称、目录、更新记录；

2)总结部分：项目背景、预期收益、方案概述、项目范围、项目风险；

3)详细部分：产品框架、全局描述、原型页面、功能需求、非功能需求；

04

prd组成：请问你完整吗？

终于，该写了！珠三角生产是产品经理的基础工作之一，可以直接反映产品经理的底层职业能力是否扎实。现在我们知道了

通用部分

文档名称用于区分不同的产品和版本。一般的命名方法是产品名称版本号。这里的“版本号”名称每个公司都不一样，版本号可以用v1.0或者日期。可以识别并快速区分。

如：xx车辆租赁管理系统v1.0；xx车辆租赁管理系统-210504。

1）文档名称

一般word形式的prd都会配备文档目录，让读者更直观的了解整个情况。

使用原型版本可以达到类似的效果。你可以把页面定义为一个“目录”，把word版本的内容放在里面，也可以通过定期给原型页面命名来达到这个效果。下图(部分页面隐藏)。

2）文档目录

prd的每一次更新都要有记录，帮助读者了解每一次更新的内容。

更新记录一般以表格的形式呈现，主要字段包括：更新时间、变更属性(添加、删除、修改)、更新内容、更新人员。

02

3）更新记录

概要部分

背景描述是让读者了解项目或需求的来源和具体情况。背景包括业务概述、业务流程、当前问题、整体解决方案等相关内容。

相应的内容会涉及到用户调研和整体方案撰写，可以直接使用。编译方法见b端产品设计：整体方案长这样？。

1）项目背景

产品r&d是公司经营行为的延伸，必须有经营目标(预期收益)。

定制产品是为了实现客户对项目的目标预期而设计的(从乙方的角度来看，客户可以通过验收)，自主开发产品的预期收益不能简单粗暴地由业务收入决定。

2）预期收益

方案概述是让读者从全局的角度了解方案设计的思路，以免直接陷入细节。什么是程序概述？基于整体解决方案的扩展，。对于b端自研产品的预期收益制定需要符合smrat原则，可以考量功能使用率、客户满意度等。

3）方案概述

制度不能解决所有问题，所以会有界限。项目范围是指产品的业务范围和相关系统。在项目实施前，需要及时与项目干系人确定项目范围、实施时间和资源消耗(成本)，避免关键信息沟通不畅带来的项目风险。

针对痛点问题描述产品的核心功能模块、技术实现方案、运营支持方案等内容。

风险是一个无论如何都不能忽视的问题。预先设定风险项目和解决方案，从而降低失控的概率。项目中存在哪些风险项目？

流程：没有明确的标准化流程；进度没有及时更新；任务报告占用了太多资源(人员、时间).

计划：重要事项省略；时间评价不合理；任务分配不合理；该计划没有预留缓冲时间.

人员：人员不足；新人员的改编费用；任务和人员技能的不匹配…

沟通：信息传递机制不完善导致沟通效率低下(传递方式、触发传递条件、指定对接人).

需求：需求的变化；变更引起的工作调整(项目规划、设计、开发和测试).

技术：开发环境不稳定；对技术困难的评估不足；开发和测试时间评估不准确；三方系统对接进度延迟.

其他：服务器不到位；市场和政策问题.

03

4）项目范围

5）项目风险

产品框架是系列构成图的构成，为了让读者对产品的构成和结构有更深入的了解。包括以下内容：

系统架构图：开发当前系统不同层次的功能模块，表达功能层次的概况。

功能结构图：系统结构的反汇编是对一级菜单和二级菜单中具体页面操作项的细化。细化成字段，就成了信息架构图。

操作流程图：用户使用系统时，如何通过一系列操作完成相应的任务。

状态机图：描述每个关键节点的状态是如何触发和流动的。比如订单状态的改变。

以下是过去项目的例子，其中一些已经简化。下图。

图：系统架构图

图：功能结构图

(950

图：状态机图

详细部分

全局通用术语、缩写、交互、系统规则、异常等相关内容可以在全局描述中统一解释。避免在文档中重复出现，这样会导致文档臃肿，阅读困难。比如：输入框定义、类型、数量限制等。分页规则、各种类型弹出窗口的交互式描述等。

异常包括断线、误操作、数据丢失等。需要描述如何处理相应的案例，也可以写在具体功能需求的描述中。

1）产品框架

原型是比较终产品每一页内容的呈现，它阐述了用户和产品之间的交互过程。通过产品架构，可以获得需要设计的页面和页面元素。有关原型工具选择、颜色匹配选择、页面类型和交互注意事项的详细信息，请参考上一节b端产品设计：拆个“详细设计”给你看。

原型页面通常与规则一起呈现，规则注释在页面旁边。

2）全局说明

对每个页面和弹出窗口都做了详细的功能描述，并对功能逻辑、字段规则等信息进行了清晰的描述。同时，要尽量使用分段语句描述，避免大规模的话语描述。更详细的内容，新文章介绍。

思维(用什么工具写prd文档)" src=" https://p6-tt . byteimg.com/origin/pgc-image/5bb 1 e2e f 664 a 4316 bb 000 c 039118 ec 7 . png " class=" aligncenter "

图：原型页面规则注释

5）非功能需求

除了功能性需求的描述，不要忘记非功能性需求。非功能性需求有很多种，也会涉及到很多利益相关方，应该根据具体项目的具体需求来设计。一般，如性能要求、操作要求、数据统计要求等。

性能要求：性能要求需要考虑用户体验和资源输入成本，例如响应时间、比较大并发性、兼容性要求.

运营计划：产品的配套运营和推广计划，在设计运营者和产品时应予以确认和记录。

数据统计：可以根据产品需求设计数据嵌入需求，可以监控嵌入点，如按钮、页面、事件等。可以自己埋，也可以用市面上成熟的数据采集软件。

以上。