网站内容发布流程图( 产品经理如何写PRD文档(一)|文档)

　　网站内容发布流程图(

产品经理如何写PRD文档(一)|文档)

　　

　　来源：产品经理朱学敏（ID：pm_zhuxuemin）

　　排版：鱼丸汤圆

　　01

　　什么是珠三角文件

　　PRD是产品从立项阶段到需求阶段最重要的文件。

　　简而言之，PRD就是将宏观抽象的业务拆分为具体的功能需求，并通过文字或图片的形式呈现出来。

　　PRD 文件主要用于产品、设计、项目、开发和测试。产品经理可以根据PRD进行功能自查，从而更全面地梳理产品；设计师可以使用PRD设计交互细节，提升用户体验；项目经理可以根据PRD拆分工作任务，分配开发人员；开发者可以基于PRD了解整个产品的逻辑；测试人员可以基于 PRD 构建用例并执行可用性测试。

　　传统的珠三角文件冗长而复杂。一方面，产品经理不方便清晰、全面地表达产品设计的相关细节，另一方面，产品经理也不方便将需求简单清晰地传达给珠三角读者。

　　02

　　PRD文件的目的

　　PRD文档是产品新人的必修课，是进入职场的垫脚石，是产品经理基本功的体现，也是衡量产品经理整体思维的标准。

　　PRD文件是每个产品经理处理最多的文件。也是项目启动前必须通过项目组审核，确定最终需求范围的重要文件。

　　PRD文件可用于在项目批准阶段评估产品机会。在需求阶段，可以定义产品功能的范围。

　　PRD文档可以梳理产品业务逻辑，记录需求变化，管理产品迭代流程，方便部门需求沟通。PRD文档的质量直接影响到开发进度、测试质量，以及最终的实施效果。

　　PRD文档是产品经理和开发人员沟通需求的重要工具。产品经理通常将其用于需求管理和版本管理。PRD 文件应显示的第一个内容是要求。如果一个 PRD 文档能够充分表达用户的需求，那么它就可以作为需求验收标准。

　　03

　　珠三角文件怎么写

　　之前有一些想转行，刚开始做产品的朋友，在产品经理朱学敏的公众号上留言，问我PRD文档怎么写。借此机会与大家分享一下我自己的一些产品体验。

　　PRD文档的写法有很多种，常见的有Word、PPT、Wiki或Axure，但我个人更喜欢直接在Axure中写PRD。此外，为了描述需求或业务规则，我重点使用可视化的*敏*感*词*、流程图和原型。正文仅作补充说明。

　　PRD文档的内容结构包括：文档概览、产品描述、全局描述、功能需求、非功能需求、改进建议等，基于以上几个方面，从理论的角度，结合案例进行阐述分析。

　　一、文档概览

　　1.1 修订历史

　　主要包括版本、时间、内容、备注等，方便沟通，记录产品成长路径，为规划未来产品迭代提供参考。以下是 PMLink 产品迭代的简化修订记录。

　　

　　1.2 项目背景

　　简要描述项目的背景、目标、定位和用户，让成员对项目有一个整体的了解和明确的方向。

　　1.3 位读者

　　文档的主要读者和使用者一般包括产品、设计、项目、开发、测试以及甲方负责人。

　　1.4 技术术语

　　解释一些会出现在文档中的专业术语，方便项目成员了解业务，统一名称。

　　二、产品描述

　　从产品生命周期了解各个阶段的运营活动，如产品路线图、功能列表、产品结构设计、用例图、业务流程图、需求列表、产品进度表、开发进度表等。

　　2.1 产品路线图

　　

　　2.2 函数列表

　　

　　2.3 产品结构设计

　　

　　2.4 用例图

　　

　　2.5 业务流程图

　　

　　2.6 需求清单

　　

　　2.7 产品进展

　　

　　2.8 开发进度

　　

　　三、全局描述

　　为产品设定的一些行为准则是​​根据既定标准和规范的要求进行操作的。如页面设计规范、产品状态规范、操作提示规范、数据加载规范、消息通知规范等。

　　3.1 页设计规范

　　

　　3.2 产品状态说明

　　

　　3.3 操作提示规范

　　

　　3.4 数据加载规范

　　

　　3.5 消息通知规范

　　四、功能需求

　　功能需求一般由功能概述、页面原型、用例描述和业务规则四部分组成。主要是对所有产品功能的描述和规划。其实就是通过场景模拟，告诉用户这个功能主要是做什么的，了解用户在什么情况下会使用这个产品。

　　4.1 个原型页面

　　常见的原型*敏*感*词*法包括手绘原型、灰色模型原型和交互式原型。产品经理一般会画低保真手绘原型或者灰模原型，高保真交互原型更多是为了UI来实现，但是我们需要在软件需求中指定所有页面的显示和各个功能的状态.

　　

　　4.2 用例描述

　　用例描述文档以文本形式表达。为了更清楚地描述用例，还可以选择用例图或流程图来辅助描述。

　　

　　用例名称：用例的名称；

　　用例编号：用例的编号，一般定义到函数Uc级别；

　　操作角色：参与或执行用例的用户。

　　Priority：功能优先顺序；函数目标：函数要达到的预期效果；

　　先决条件：参与或执行用例的先决条件，或它所处的状态；后置条件：执行完成后的结果或状态。

　　4.3 业务规则

　　业务规则是指业务定义和约束的描述，用于维护业务结构或控制和影响业务的行为。也就是告诉我们这个函数在运行时有什么约束。

　　以PMLink快速登录为例，讲解操作、输入框、内容格式、长度、灯光、控件、数据之间的关联。产品在使用时必须有相应的业务规则，业务规则必须完整、准确、通俗易懂。

　　

　　业务规则从程序代码中提取系统处理的业务逻辑，转化为简单的业务规则，用结构化的业务规则数据来表达业务行为。通过这种方式，用户可以在不寻求程序员帮助的情况下更改业务规则。

　　

　　最典型的是CRM客户关系管理系统。其复杂多变的业务规则需要一套业务规则引擎架构设计。

　　五、非功能性需求

　　非功能性需求是指软件产品为了满足用户的业务需求而必须具备的特性，而不是功能性需求。一般涉及的有：性能要求、安全要求、可靠性要求、数据监控要求、系统要求、运行环境要求、对外接口要求等。

　　以性能需求为例，我们将重点关注每秒处理的事务、功能操作的响应时间和页面刷新时间。以系统需求为例，我们会关注服务器连接失败后的重启次数。时间导致故障的比例和发生故障时数据损坏的可能性。

　　六、改进建议

　　改进建议其实就是根据用户体验区域优化产品路径。

　　网上可以作为参考的PRD文件太多了，但都不是标准规范。最忌讳的是一步步套用BAT公司的文档规范标准。需要结合公司的实际需求，写出适合自己产品团队的PRD文档。

　　写出一个好的 PRD 不是一朝一夕就能完成的。除了基本的专业技能和逻辑思维，还要经常采集

、反馈、总结。

　　写PRD文档不能为了人脸工程或个人表现而写一堆琐碎的废话。这只会让产品经理在需求审查期间和开发人员眼花缭乱。归根结底，要求必须回到及时性上。在业务逻辑清晰的前提下，尽量使用简洁的语言将需求快速传递到开发中。

　　一份脚踏实地的珠三角文档，必须遵循整体逻辑清晰、语言简洁易懂、信息实时共享、功能范围清晰、需求快速落地的原则。总而言之，PRD文件最重要的就是明确要求。

　　如果您觉得文章对您有帮助，请留言并推荐给您的朋友。