如何写PRD（产品需求文档） 产品需求文档，也叫业务需求文档。 一般写这样的文档用WORD+VISIO或AXURE，建议互联网产品经理都熟悉一下AXURE这个软件的使用，能直接生成PRD，但是生成的文档是英文的，听说只有腾讯有个汉化的版本。 产品需求文档主要是描述产品功能，业务流程和LOFI。可以提供给UE，美工 ...产品需求文档，也叫业务需求文档。一般写这样的文档用WORD+VISIO或AXURE，建议互联网产品经理都熟悉一下AXURE这个软件的使用，能直接生成PRD。产品需求文档主要是描述产品功能，业务流程和LOFI。可以提供给UE，美工和项目经理执行的文档。
一般每个业务功能都按以下格式写： 1.1.1 （业务功能名称） 1.1.1.1 业务功能基本信息 1.1.1.2 业务功能 1.1.1.3 业务流程 1.1.1.4 业务规则 1.1.1.5 界面管理 1.1.1.6 数据要求 1.1.1.6.1 输入 1.1.1.6.2 输出 1.1.1.7 费用处理要求 1.1.1.8 打印单据／文件要求 1.1.1.9 参数要求 1.1.1.10 与其它界面的整合建议
文档分为两轮 第一轮： 1，文档使用方：UI设计师 2、内容： .根据战略层定义出来产品功能范围， .说明此产品的目的，方便UI设计人员更好的理解产品 .产品基本流程 .详细的设计框架图，推荐用axure,简单效率高 .详细文案 3、格式： html，visio，或word，如果PS用的不熟练，不推荐使用，会影响工作效率。 上面是要UI设计人员出来高保真原型图
第二轮： 文档使用方：开发人员 用高保真原型图来对开发人员写技术需求说明 有了高保真原型图，开发人员看的最明白，我们只需要写好详细的逻辑功能结构和详细的流程图 在工作流程中，特别是面向UI和工程师，没有必要详细的写出来什么行业分析，开发背景之类的内容，因为UI和工程师是在干活，不去关心这些问题，但一定要写清楚功能范围和此产品的目的，这样有助于UI设计人员的理解。 另外，上面说的是个人理想状态，可能每个公司有自己的现实情况而有不同的流程。关键是提高效率减少不必要的扯皮沟通。
2.2 产品定义 Product Definition 2.2.1 What 做什么产品定义，即定义产品到底要做成什么。一般来说，比较正规的做法是撰写一份称之为 PRD（Product Requirements Document）的文档，该文档一般可以包括以下内容： 该产品的远景目标（vision） 目标市场和客户（target market and customers）的描述 竞争对手分析（competitive summary） 对产品主要feature的比较详细的描述 这些feature的优先级 初步拟定的实现进度安排 用例（use cases），这可以是较粗略的大致描述，未必一定要UML Use Case图。 产品的软硬件需求 产品的性能要求 销售方式上的思路、需求（直销还是渠道？直销怎么做？渠道怎么做？） 技术支持方式上的思路、需求（提供什么样的技术服务？） 显然，PRD文档就是对产品的整体规划，应该比上述Market Research阶段的MRD文档要细化一些： MRD文档主要侧重于市场机会的分析，得出结论“就当前市场情况而言，我们可以做什么” PRD侧重于整个产品的规划，以及business方面的需求。 PRD不同于SRS（System Requirement Specification），SRS是系统需求分析说明书，是以相当技术化的语言撰写的，主要给研发人员看的。
2.2.2 Goal 目标是什么 产品定义是产品管理的核心工作。 通过产品定义： 使得公司内部所有与业务相关的部门（高层领导、研发、销售、支持等部门）都能基本清楚我们到底要做什么产品，从而统一大家的思想和行动。 产品定义的PRD文档，为研发部需求分析组接下来出SRS文档提供了基本依据。
2.2.3 How 怎么做 产品管理部门根据市场研究结果，和各个业务相关部门沟通，发挥自己的创造力来进行产品定义工作。
2.2.4 Who 谁来做 产品经理负责牵头，主要由产品管理部门进行具体工作实施。
2.2.5 Deliverable 有无输出 比较正规的做法是输出上述PRD文档。对小公司或者小团队而言，有时可以把MRD和PRD合并在一个文档里描述。
| 
收藏
淘帖
踩
