教你如何写PRD.docx
《教你如何写PRD.docx》由会员分享，可在线阅读，更多相关《教你如何写PRD.docx（11页珍藏版）》请在冰豆网上搜索。
教你如何写PRD
教你如何写PRD（产品需求文档）
如何写PRD（产品需求文档）
产品需求文档，也叫业务需求文档。
一般写这样的文档用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设计人员出来高保真原型图，
第二轮：
文档使用方：
开发人员
用高保真原型图来对开发人员写技术需求说明
有了高保真原型图，开发人员看的最明白，我们只需要写好详细的逻辑功能结构和详细的流程图
PS：
个人认为在工作流程中，特别是面向UI和工程师，没有必要详细的写出来什么行业分析，开发背景之类的内容，因为UI和工程师是在干活，不去关心这些问题，但一定要写清楚功能范围和此产品的目的，这样有助于UI设计人员的理解。
另外，上面说的是个人理想状态，可能每个公司有自己的现实情况而有不同的流程。
关键是提高效率减少不必要的扯皮沟通。
2.2产品定义ProductDefinition
2.2.1What做什么产品定义，即定义产品到底要做成什么。
一般来说，比较正规的做法是撰写一份称之为PRD（ProductRequirementsDocument）的文档，该文档一般可以包括以下内容：
该产品的远景目标（vision）
目标市场和客户（targetmarketandcustomers）的描述
竞争对手分析（competitivesummary）
对产品主要feature的比较详细的描述
这些feature的优先级
初步拟定的实现进度安排
用例（usecases），这可以是较粗略的大致描述，未必一定要UMLUseCase图。
产品的软硬件需求
产品的性能要求
销售方式上的思路、需求（直销还是渠道？
直销怎么做？
渠道怎么做？
）
技术支持方式上的思路、需求（提供什么样的技术服务？
）
显然，PRD文档就是对产品的整体规划，应该比上述MarketResearch阶段的MRD文档要细化一些：
MRD文档主要侧重于市场机会的分析，得出结论“就当前市场情况而言，我们可以做什么”
PRD侧重于整个产品的规划，以及business方面的需求。
PRD不同于SRS（SystemRequirementSpecification），SRS是系统需求分析说明书，是以相当技术化的语言撰写的，主要给研发人员看的。
2.2.2Goal目标是什么
产品定义是产品管理的核心工作。
通过产品定义：
使得公司内部所有与业务相关的部门（高层领导、研发、销售、支持等部门）都能基本清楚我们到底要做什么产品，从而统一大家的思想和行动。
产品定义的PRD文档，为研发部需求分析组接下来出SRS文档提供了基本依据。
2.2.3How怎么做
产品管理部门根据市场研究结果，和各个业务相关部门沟通，发挥自己的创造力来进行产品定义工作。
2.2.4Who谁来做
产品经理负责牵头，主要由产品管理部门进行具体工作实施。
2.2.5Deliverable有无输出
比较正规的做法是输出上述PRD文档。
对小公司或者小团队而言，有时可以把MRD和PRD合并在一个文档里描述。
从“产品需求文档”（PRD）到“产品设计文档”（PDD）
传统上写产品需求文档（PRD）的做法，就是把用例、流程图和网页原型图一股脑的放到一个Word文档里。
一般一个产品都包含乃几十个乃至上百用例，每个用例都有自己的流程图，每个流程图又包含了少则几个多则几十的网页原型图，结果就是产品需求文档变得庞大无比，写的人费事儿，读的人更惨。
自从我受到了这样文档的折磨，我就一直都在琢磨怎么才能把文档写得更简单一点，让阅读的人－通常是设计师和程序员－能够在最短的时间内领会产品的设计。
原来做UI设计师的时候，我创造了一种的办法，这个方法受到了很多人的欢迎，这篇文章也引起了一定的反响。
其实当时在实际使用的时候，我不仅产出这样一份流程图，还利用网页热区，把流程图中的界面元素（蓝色的元素）和原型网页（HTML文件）给结合起来了，这样设计师和程序员在看流程图的时候，只要用鼠标点一下界面元素，就可以连接到原型网页，非常方便！
这个办法我一直都在用，只是当时没有写在文章里罢了。
后来随着工作性质的变化，我需要越来越多地考虑产品的整体和功能、而不是像原来一样只在特定需求内围绕界面做文章，我就开始寻找把用例整合进前述方法的可能。
在经过了一段时间的摸索和实践后，我逐渐形成了自己特有的一套产品需求文档的写法，为了表示区别，我称之为“产品设计文档”，简称PDD。
本文就是对PDD的介绍。
PDD的组成部分
PDD有三个组成部分，它们分别是用例、流程图和原型图。
用例
用例从整体脉络上定义了产品所具有的功能。
比如对于一个邮件系统来说，“写邮件”、“发邮件”和“删除邮件”等功能都是用例。
用例比较流行的写法，是在每一个用例中标明它的前后置条件和异常情况等属性。
不过在PDD中，我完全放弃了上述属性，只保留用例的名称和简要描述。
因为“用例”的出发点就是“用户”，如果你站在一个用户的角度来思考产品的功能，你会发现那些属性你根本就不会考虑。
并且，各种前后置条件和异常情况，完全可以放在流程图中，这样更清楚。
流程图
流程图是对用例的细化，它可以清晰地表现一个用例所有相关的前置、后置和分支条件。
流程图的画法我在一文中已经说得非常清楚了，在此不再赘述。
唯一值得注意的是，我以前并没有意识到流程图本身也是有ISO标准的，因此“画”中使用的流程图元素并不符合ISO标准，也和一些已经成型的系统（比如这篇）有出入，因此元素在使用上还存在一些问题。
在日常工作当中我已经对元素使用做了修改，以后有时间我会更新“画”一文的内容，也有可能直接把模板放出来。
原型图
原型图是对流程图中“界面元素”的展现。
这个东西没什么可说的。
PDD的表现方式
用例、流程图和原型图一般都是产片需求文档（PRD）中已有的东西，PDD在这点上和PRD没什么区别。
而下面要说的表现方式，则是PDD的精髓。
我比较孤陋寡闻，还没看到过有人像我这样组织这三块内容，所以姑且认为这是我的首创吧。
用例和流程图
首先把用例和流程图整合起来。
方法很简单，利用网页的frame标签，新建几个帧：
1.index.html－另外两个帧的容器，不用解释吧
2.navigation.html－导航帧，用于存放用例列表
3.main.html－默认情况下的主帧，用于存放文档简介、作者、版本和更新日志一类的东西
然后新建一大堆网页，把所有的流程图都放在这些网页里，每个流程图（即每个用例）放在一个网页里，最后修改navigation.html，把用例名称和其对应的网页链接起来。
完工以后，页面应该是下面这个样子：
PDD文档首页
左侧为用例，右侧为流程图
好了，左侧为用例，右侧为流程图，这样就把用例和流程图整合了起来，并且结构清晰，查看方便。
流程图和原型图
整合流程图和原型图的重点在于，提供一种方便的方式，以让读者能够在看流程图时方便的看到其中包含的原型图。
为了达到这个目的，我的做法是：
1.在用画流程图时，选择界面元素（蓝色的那个），然后在“检查器”－“属性：
动作”中选择“打开文件”，然后按“选择文件”，找到你的原型图文件并按“确定”，这样你这个元素就和原型图链接起来了。
如下图所示：
2.在OmniGraffle中输出这个流程图文档时，不是选择图片，而是选择“HTML图像映射”，这样在生成出来的网页上，蓝色的界面元素都是可以点击的，点了以后就链接到原型图。
很方便对吧？
但这还不够；
3.用，把所有图片链接都改成弹出图层，这次再点刚才那些链接看看，效果是不是更棒？
好了，通过这样的方法，产品设计文档（PDD）就将用例、流程图和原型图这三块内容有效的整合了起来。
如何正确的写产品需求文档（PRD）附常用工具
宗旨：
通过工具—把思想有逻辑、有细节的合理的组织到一起！
互联网行业，蓬勃兴起，很多从事产品工作。
不管是生手、新手、老手还是高手，我也想和大家分享一下产品需求文档的一些心得，希望能帮助大家（pa/pm）更好的提高自身水平、提高工作效率。
我这里只是简单的从需求的实施环节进行描述。
之前的需求的调查、需求的获取、需求的比较分析取舍等等都不再阐述了。
1、熟悉项目发生的相关业务行为。
言下之意，就是说：
我们要做的是什么项目，我们这个项目主要是做什么业务，具体业务我们怎么通过更合适的框架、平台去实现它、支撑它。
简而言之，得要求：
面向业务（对象），进行业务行为（设计），也是需求的开始，
推荐工具：
Rationrose★★★★
说明：
通过usecase可以很容易，很清晰的将整个业务员系统直观、规范的表达出来，按照模块建立各个package,从而将复杂的业务通过case直观的表现出来。
工程师看的明白、产品人员也看得明白。
2、将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统一
很笼统的说，就是；流程问题
流程就是逻辑，你只有制定合理的、符合业务实际情况。
符合系统实现（可实现、容易或稳定实现）的流程，才会更好支持日后的业务系统和管理系统服务实际的业务。
不管是进销存、还是SAP原理其实都是相通的。
推荐工具：
Visio2007★★★★★
说明：
Visio是个老掉牙的工具了，从微软手里出到了07版本，它该有的模型都有了，通过visio你可以直接的把整站流程框束在文档上。
不论你开发怎么样的系统，需求什么样的环境，都可以一一标明出来。
你的流程图的好坏直接会影响工程师实现你指定产品的实现方式。
所以强调一点，产品人员要熟悉计算机开发，熟悉人机交互，熟悉一些常用的开发方式，这样有助于很好的和团队做融合，更好的框架更容易扩展。
3、把项目条目化，条理化，目录结构具体规定好。
有了上面主要的CASE和流程的保障，接下来就应该要从系统的功能方面做条目化的规划制定了。
功能怎么排列，设置更符合业务的使用逻辑，怎么样让使用者更容易、直观的入手，怎么样一个很好的B/S或C/S的功能界面呈现到前台。
推荐工具：
Mindmanager★★★★
说明：
mindmanager是一款可视化思维导图软件，它可以智能的建立各个模块，各个主、次、平级目录。
同时也当便做调整、做对外的功能结构的报告演示。
更值得一提的是通过它可以导出到word中，方便您对word进行完善。
4、前台结构布局，合理规范的将系统脱去朦胧的华纱。
众所周知开发者和使用者是不知道这
升级会员 