网站文章采集软件( PRD在项目中起什么作用？什么才是好的PRD？)

　　网站文章采集软件(

PRD在项目中起什么作用？什么才是好的PRD？)

　　据说产品经理有三大文件：BRD、MRD、PRD。日常工作中很多产品已经被领导定好了，所以写BRD和MRD的机会比较少，比较常用的是产品细化阶段用到的PRD。

　　PRD在项目中扮演什么角色？什么是好的PRD？PRD怎么写？本文将依次回答相应的问题，如有错误或遗漏，敬请指教。

　　一、PRD函数：你要什么用？

　　PRD 是一个文档，将产品需求和相应的需求解决方案放在一起。该文档面向与项目相关的多个角色，对项目的推广起到重要作用，例如：

　　产品：根据PRD推进计划，并以此作为最终检验产品实现程度的依据；设计：使用PRD原型作为UI设计的参考；开发：以珠三角系统规则等内容为基础进行研发；测试：根据PRD规则编写用例和测试。

　　根据需求的覆盖范围，还会涉及到其他角色，比如运营、业务、财务等，不管面对的是谁，最终的目标都是让团队成员了解业务，并在业务中更好地执行。产品开发过程。

　　二、珠三角请求：你要我做什么？

　　为了让PRD发挥更好的作用，在编写文档时需要以清晰、完整、易读的方式呈现复杂抽象的解决方案。我们怎样才能达到这样的效果？该文件必须至少满足以下要求：

　　根据具体情况，写PRD时会有其他要求。例如，对于非功能性需求（数据指标需求、操作需求……），需求的定义必须明确且无可争议。

　　三、珠三角准备：注意你的尺度！

　　知道了PRD的要求，就可以在写作的时候离要求更近一点。但是需求只能作为指导思想，并没有告诉我们怎么写。你可能还有这些疑问。

　　1. PRD应该以什么形式呈现？

　　PRD-word和prototype有两种常见的形式。这两种形式各有优缺点。比如目录的word版，更容易掌握全局；原型版本在功能需求的描述上更加灵活。

　　要采用这种方法，您必须首先查看公司系统。如果有相应的规范，可以直接实现（规范也可以调整）。如果公司没有要求，产品经理和团队沟通，采用大家都认可的更方便表达和阅读的方式。而已。

　　2. PRD应该写什么粒度？

　　写过PRD的同学应该都有这个问题。尤其是对规则的描述，如果写得太厚生怕遗漏，如果仔细写，可能会看不懂。除了简化描述中使用的词语外，还可以从规则的细化和原型设计上进行控制。

　　规则细化：通过“全局描述”来描述约定俗成的规则和可复用的规则。如手势操作、输入框定义和限制等。 原型设计：输出原型不应有高保真原型，既费时又影响UI性能；不应有复杂的交互，不利于快速识别，可在备注中说明；不要过度设计...3. PRD 由哪些部分组成？

　　总结过往项目PRD的常用组件，拆解了general、summary、detail这几个部分，仅供参考。每个珠三角的具体组成需要根据实际情况进行增减。

　　四、珠三角作文：你完成了吗？

　　终于到了写的时候了！PRD生产是产品经理的基本任务之一，可以直接反映产品经理的基本专业能力是否扎实。既然知道了PRD的组成，那我们就以原型版为例，说说各个部分怎么写。

　　1. 一般部分

　　1）文档名称

　　文件名是为了区分不同的产品和版本。常规的命名方式是产品名称+版本号。这里的“版本号”的命名因公司而异，可以使用V1.0或date作为版本号。只要能够快速识别和区分。

　　如：XX汽车租赁管理系统V1.0；XX汽车租赁管理系统-210504。

　　2）文档目录

　　一般word形式的珠三角会配备文档目录，让读者更直观地了解全局。使用原型版也可以达到类似的效果。可以将页面单独定义为一个“目录”，将单词version的内容放入其中，也可以通过给原型页面命名来达到这个效果。如下图（部分页面被隐藏）。

　　3）更新记录

　　PRD的每次更新都必须记录下来，以帮助读者了解每次更新的内容。更新记录一般以表格的形式呈现，主要字段包括：更新时间、更改的属性（增加、删除、修改）、更新内容、更新人员。

　　2. 总结部分

　　1）项目背景

　　背景说明是为了让读者了解项目或需求的来源和具体场景。

　　背景包括业务概况、业务流程、当前问题、整体解决思路等相关内容。相应的内容会涉及到用户研究和整体解决方案的编写，可以直接使用。准备方法请参考《B端产品设计：整体方案长什么样？》”。

　　2）预期收益

　　产品研发是公司经营活动的延伸，要有经营目标（预期收益）。定制产品是为了实现客户对项目的目标期望（从乙方的角度来看，客户可以通过验收），自主开发产品的预期收益不能简单粗暴地直接由商业收益决定。

　　对于B端自研产品，预期收益必须符合SMRAT原则，可以考虑功能利用率和客户满意度。

　　3）方案概述

　　方案概览是为了让读者从整体层面了解方案设计的思路，以免直接陷入细节。

　　什么是程序概述？基于整体解决方案思路展开，针对痛点描述产品的核心功能模块、技术实施方案、运营支持方案等内容。

　　4）项目范围

　　系统不能解决所有问题，所以会有边界。

　　项目范围是指产品涉及的业务范围、相关系统等。

　　项目实施前，应及时与项目利益相关者（利益相关者）确定项目范围、实施时间、资源消耗（成本），避免因项目利益相关者沟通不畅而导致项目风险。关键信息。

　　5）项目风险

　　风险是任何事情都不能忽视的问题。提前预设风险项目和解决方案，降低失控概率。项目中有哪些风险项目？

　　3. 详情

　　1）产品框架

　　产品框架是系列组成图的组成，以便读者对产品的组成结构有更深入的了解。收录

以下内容：

　　以下是过去项目的示例，其中一些已被简化。如下所示。

　　图：系统架构图

　　图：功能*敏*感*词*

　　图：系统操作流程图

　　图：状态机图

　　2）全局描述

　　关于全局术语、缩写、交互、系统规则、异常情况等相关内容，可以在全局描述中统一说明。避免文档中重复出现，导致文档臃肿，阅读困难。

　　例如：输入框定义、类型、数量限制等，分页规则，各类弹窗的交互说明等。

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

　　3）原型页面

　　原型是对最终产品每一页内容的呈现，阐述了用户与产品的交互过程。需要设计的页面和页面元素可以通过产品架构来绘制。原型工具的选择、配色、页面类型、交互注意事项等详细内容请参考上一篇《B端产品设计：拆解一个“详细设计”给你看》。

　　原型页面通常带有规则，页面旁边是规则注释。

　　4）功能需求

　　对每个页面和弹窗都做了详细的功能描述，对功能逻辑、字段规则等信息进行了清晰的描述。同时，尽量使用分段的陈述性描述，避免大段的散文式描述。更详细的内容在新文章中介绍。

　　图：原型页面+规则注释

　　5）非功能性需求

　　除了功能需求的描述，不要忘记非功能需求。非功能性需求的种类很多，会涉及到多个相关方，设计时要结合具体项目的具体需求。性能要求、操作要求、数据统计要求等约定。

　　多于。

　　本文由@耳目不染原发表，为产品经理。未经许可禁止转载。

　　标题图片来自Unsplash，基于CC0协议