教你怎样写PRD.docxVIP

教你如何写PRD（产品需求文档）如何写PRD（产品需求文档）产品需求文档，也叫业务需求文档。一般写这样的文档用WORD+VISIO或AXURE，建议互联网产品经理都熟悉一下AXURE这个软件的使用，能直接生成PRD，但是生成的文档是英文的，听说只有腾讯有个汉化的版本。下次哪位老兄进了腾讯给俺捎一个，在这里谢谢了哈。产品需求文档主要是描述产品功能，业务流程和LOFI。可以提供给UE，美工和项目经理执行的文档。一般每个业务功能都按以下格式写：1.1.1 （业务功能名称） 业务功能基本信息 业务功能 业务流程 业务规则 界面管理 数据要求.1 输入.2 输出 费用处理要求 打印单据／文件要求 参数要求0 与其它界面的整合建议＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝文档分为两轮　第一轮：　1，文档使用方：UI设计师　2、内容：　.根据战略层定义出来产品功能范围，　.说明此产品的目的，方便UI设计人员更好的理解产品　.产品基本流程　.详细的设计框架图，推荐用axure,简单效率高　.详细文案　3、格式：　html，visio，或word，如果PS用的不熟练，不推荐使用，会影响工作效率。　　上面是要UI设计人员出来高保真原型图，　　第二轮：　文档使用方：开发人员　用高保真原型图来对开发人员写技术需求说明　有了高保真原型图，开发人员看的最明白，我们只需要写好详细的逻辑功能结构和详细的流程图　　PS：个人认为在工作流程中，特别是面向UI和工程师，没有必要详细的写出来什么行业分析，开发背景之类的内容，因为UI和工程师是在干活，不去关心这些问题，但一定要写清楚功能范围和此产品的目的，这样有助于UI设计人员的理解。　　另外，上面说的是个人理想状态，可能每个公司有自己的现实情况而有不同的流程。关键是提高效率减少不必要的扯皮沟通。2.2 产品定义 Product Definition2.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合并在一个文档里描述。从“产品需求文档”（PRD）到“产品设计文档”（PDD）传统上写产品需求文档（PRD）的做法，就是把用例、流程图和网页原型图一股脑的放到一个Word文档里。一般一个产品都包含乃几十个乃至上百用例，每个用例都有自己的流程图，每个流程图又包含了少则几个多则几十的网页原型图，结果就是产品需求文档变得庞大无比，写的人费事儿，读的人更惨。自从我受到了这样文档的折磨，我就一直都在琢磨怎么才能把文档写得更简单一点，让阅读的人－通常是设计师和程序员－能够在最短的时间内领会产品的设计。原来做UI设计师的时候，我创造了一种http://dingyu.me/blog/posts/view/flowchart-howtos \t _blank用流程图来表示产品交互的办法，这个方法受