育才学习网1.如何撰写PRD文档
prd文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
开发工具推荐 ：
Rational Rose★★★★--熟悉项目发生的相关业务行为。
visio 2007★★★★--将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统一
mind manager★★★--把项目条目化，条理化，目录结构具体规定好。
Axure★★★--前台结构布局，合理规范的将系统脱去朦胧的华纱。
Word★★★★★--穿针织网，把需求综合起来，整理成最终的产品需求文档。
也就是用以上任意一种软件都可以打开，不过应该有版本要求。
2.PRD怎么写
1、文件命名（编号）
文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”，当出现产品第二版时，可以命名为“公司名-产品名-PRD-D2.0”。
2、修订控制页
一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序，文档版本显示的当前修改的内容是在哪个版本中出现，修订章节是具体到哪个章节哪个功能模块的修改，修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期，修改人显示修改内容模块的人，可能是当前用户也可能是其它产品人员。
3、目录
不建议自己去添加一个新的目录，你可以去其它的文档中拷一个过来，不考虑目录的内容，等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。
4、请与以下部门讨论PRD
PRD做为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上，需要与相关人员确定“沟通内容”，这对于产品整体流程将是很重要的。同时对于产品核心功能的提取也是一个重要环节。产品经理很重要的一个职能就是沟通。例与客服中心：客服服务部，讨论的内容：预测客服成本、工作量；讨论客服如何支持；协助评估诈欺/数据窜改风险：欺诈/数据窜改风险、不正使用风险。这就是要写在与其它部门讨论PRD中的。一个产品经理需要考虑如何与其它部门之间的沟通合作，文档很大一部分的功能是提醒你要做的工作，同时不断补充将要面临的工作。
3.如何写出好的PRD
首先，先了解清楚PRD的阅读对象，使用者。
PRD的模版中一般有如下信息： PRD预期的读者包括：产品、开发、测试人员及相应的负责人和用户方代表。产品、开发、测试人员会从中了解到本次需求的背景和详细要求，以及每个需求点未来的优化方向或对用户的价值。
而用户方代表则可以通过该文档了解PRD中所描述内容是否是自己期望中的需求，是否符合以及是否都覆盖到了自己的预期。因此PRD也是产品经理同相关角色确认开发任务的重要依据。
当所有角色认可了PRD中的内容后，这份PRD将作为后续开发、测试、需求验证的依据。 其次，一个完整的PRD还应该具备的要素有 1、文档的命名和编号 文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。
文件命名的方法一般是通过版本号定义，比如简单的方法是，XX产品V1.0PRD_V2，前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号。稍微详细点可以定义成，XX产品XXXX需求PRD_V2，即对本次迭代的需求任务做命名，这样更便于阅读和记忆。
2、文档的版本历史 包括，编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序，文档版本显示的当前修改的内容属于文档的第几个版本（或第几次修改，一次修改一般为一个版本），章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求，让阅读者直观的了解原因。
日期是指需求文档修改的时间，修改人是指需求内容的修改者。 3、目录 不需要自己新建，文档完成后直接更新模版中的目录即可。
目录是用来了解文档结构的 4、引言 这部分的内容有：产品概述及目标、产品roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明 产品概述：解释说明该产品研发的背景以及核心功能。 预期读者：文档的使用对象 成功的定义和判断标准：旨在说明产品的目标 参考资料：PRD的参考资料 名词说明：名称、说明。
名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。 5、需求概述 需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等 需求概览：分两部分，一是业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释。
二是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级。 用户类与特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和操作行为做出说明。
运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本，操作系统、数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户。 设计和实现上的限制：比如控件的开发环境、接口的调用方式等等 项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时间、开发的完成时间、上线时间等等 产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。
6.功能需求 功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。
功能详情包括以下内容： 简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。 场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。
这也是产品经理讲“好”故事的必备条件 使用者说明：对产品使用者做出说明，可融入简要说明中。 前置条件：该需求实现依赖的前提条件。
比如，上传照片时，需要存有图像文件。 后置条件：操作后引发的后续处理。
主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明（这是非常重要的）。 推荐一个方法：“用例”，在面向对象的软件设计模型中，用例是一个被阐述的内容，用例是对功能使用场景的解释。
用例很条理的介绍了每个功能的前置、后置条件，主流程介绍，帮助开发、测试等角色快速的了解产品功能。 7、可选方案 列出所有可以选择的达到该产品目标的方案要点（主要思路），给各方案适当的评价，并推荐最优方案（在功能需求中描述的）。
你在做这个产品规划时一定有很多的备选方案，别放弃这些方案，永远没有过时的idea，只有最适合时机的idea。所以可以写出几个可选方案，或许是你下期产品改版一个方向。
记住，多思考方案是永不为过的 8、效益成本分析 通过这一点上能看出产品经理必须是个全才，不仅要具备行业知识，还需要有财务知识。一个产品的成本衡量一般包括三个方面：效益预测、产品技术成本和其他成本支出。
9、整合需求 产品整合能力是产品经理很重要的一个能力，业务合作通常是不可避免的，将隶属于两个不同来源的业务功能做整合也是常见需求，比如系统登陆使用公司的域用户登陆，或者付款使用财付通、支付宝付款，解决好整合需求也是体现产品经理核心竞争力的。
4.如何快速写好基于AxureRP原型的PRD文档
大公司才会有交互设计师这个岗位，也就才会有交互设计稿这种文档产出，一般的公司都是只有产品设计师、需求分析师、商务分析师或者产品经理这样的岗位，这个岗位基本会包办了从需求收集，需求分析，需求设计，原型设计，编写PRD这样的一个过程，所以说小公司比较锻炼人，会练就全能的本事。
编写PRD文档是个较为苦命的工作项，具体的编写要求参见《如何书写好的产品需求文档PRD》，这份文档将会作为产品的指导性文档，告诉开发、测试产品的需求点，实现的要求，验证的逻辑，运营人员也需要参考，以获知当前产品所能达到的功能层次。写文档的时候事无巨细吧，人家会嫌你写的太繁琐了；写的太简单吧，人家又会嫌你没说清楚该说的；开始使用敏捷模式要求文档弱化了，但其实只是在过需求的时候不需要提前先把PRD写好，事后还是得补的；写文档耗掉的时间多了，人家会说能否除掉一半，功能需求都确认好了，你只是将它描述出来为什么要用掉那么多的时间？凡此种种，都让做产品的我们感觉命怎么这么苦，因此开拓一种写PRD的新思路新方法是相当有必要的。
现在都讲究用工具来辅助，工具用的好，确实能事半功倍，那要是工具用的不好呢？那就只能自求多福了。原型设计软件的主要功能还是用来做原型，那是否原型演示完了之后就没有用了呢？这个我想有点工作经验的人都不会这么认为，当然我们还是可以发挥一下原型的剩余价值的。
大家都知道，如果一份文档里面可以图文结合，所描述的东西更能吸引到人去阅读，也更能帮助别人理解。AxureRP所设计的原型支持HTML格式的浏览，相较于其他原型设计软件直接产出图片，AxureRP的原型即可以直接导出成图片格式，也可以通过在浏览过程当中用截图软件来截图的方式使用，当然后一种方式更为繁琐，后面说明为什么直接生成图片反而不方便。
使用AxureRP自带的文档生成功能去生成PRD文档这点我在之前写AxureRP使用教程的时候有提到过，AxureRP是支持通过即定的word模板格式来导出生成文档的，可以参考《AxureRP教程–生成规格说明书》。不过使用这个功能对自身的要求是比较高的：1、要对AxureRP所提供的注释功能非常熟悉，其默认提供的注释字段是国际通用的，并不适合中国国情，要根据产品和项目的需求进行修改和自定义。
要了解组件注释和页面注释的使用方式，以及这些注释会出现在文档的什么位置等；2、要在做原型设计的时候就做好注释的录入，每个组件的交互，前置触发条件，后置反馈事件，以及每个页面的功能说明等，这是一项细致活，挺耗时间的，和快速原型设计的要求不大相符；且万一在确认需求的过程当中需要修改的，这个维护量也比较大；3、要熟悉word的格式排版设置，用AxureRP默认提供的word模板生成出来的PRD文档，估计不符合大多数公司的文档编写要求，如果没有要求的则可以直接使用，否则就得自己倒腾一个word模板出来，这个对word的功底要求较高，再就是还得熟悉AxureRP里面模板导入的机制和模板使用机制；4、综上所述，这个功能虽然很强大但实际应用的较少，其实比较鸡肋，个人是已经放弃了，有兴趣的朋友可以深入研究一下，到时分享一下； 基于AxureRP原型的PRD文档编写这个方式其实就是截图，然后用截图+文字的形式来书写PRD文档，有人就说了，图片制作软件那么多，为什么非得用AxureRP来做原型，还得截图呀，这里有个已经使用AxureRP的前提：1、AxureRP提倡快速原型设计法，可以大大减少原型设计的时间，这是选择使用AxureRP的一个原因；2、AxureRP支持HTML格式的浏览，极大的方便了原型的演示效果，可以很清楚地告诉演示对象每个页面的跳转，每个按钮的操作效果，每个连接点击结果等，这是选择使用AxureRP第二个原因； 当然AxureRP的优点不止于此，原因可能很多，但主要的是这两个方面，这两个前提决定了我们当前都是使用AxureRP来做原型设计的，然后再讨论如果在已经使用AxureRP的情况再来优化截图写PRD的方法，否则就没法进行下去了。1、为什么是HTML格式页面的截图而不是直接导出图片？这个从操作层面上来讲，导出图片的模式操作流程如下：导出为图片>>>打开word>>>选择插入菜单>>>选择插入图片>>>搜寻图片所在文件夹>>>选择图片>>>点击按钮完成插入图片操作；或者是下面这种方式：导出为图片>>>打开图片所在文件夹>>>选择插入图片并打开>>>复制图片>>>打开word>>>粘贴图片完成插入图片操作；这个比上面的省一个步骤；从HTML页面截图的模式操作流程如下：打开对象所在HTML页面>>>用截图工具截图>>>复制所截图片>>>打开word>>>粘贴图片完成插入图片操作；对比一下就知道，用截图的方式所需的操作步骤是最少的，也就是最能节省时间的，这里推荐一个截图工具：Snagit（下载地址），可以对所截的图进行一些简单的编辑，比如画个圈圈提示一下，画点箭头什么的。
2、基于AxureRP原型截图这种方式更能适应需求变化。大家都知道AxureRP是支持单个页面的修改单个页面重新生成原型的，不需要整体原型重新生成一遍，这样某个地。
5.PRD文档到底有什么用
首先，PRD是给我们产品部内部人看的。我们根据公司的阶段运营目标，提出合理的需求，那么实现这个需求的功能、逻辑，通过思维导图、流程图、用例图、状态图等做分析，再书写成PRD，慢慢梳理出逻辑。
其次，PRD是给团队的其他人看的。一个业务功能，即便能够在脑海里想清楚所有的功能、逻辑，但是还不能保证团队的其他人也能在头脑里想清楚一切逻辑。所以，就需要通过输出PRD，让团队其他人员理解需求的逻辑。
再就是，PRD也是给领导看的，这样，再跟领导申请资源的时候，给出一份清晰的PRD能够让领导看明白为什么我要要这些东西。
6.如何快速写好基于AxureRP原型的PRD文档
大公司才会有交互设计师这个岗位，也就才会有交互设计稿这种文档产出，一般的公司都是只有产品设计师、需求分析师、商务分析师或者产品经理这样的岗位，这个岗位基本会包办了从需求收集，需求分析，需求设计，原型设计，编写PRD这样的一个过程，所以说小公司比较锻炼人，会练就全能的本事。
编写PRD文档是个较为苦命的工作项，具体的编写要求参见《如何书写好的产品需求文档PRD》，这份文档将会作为产品的指导性文档，告诉开发、测试产品的需求点，实现的要求，验证的逻辑，运营人员也需要参考，以获知当前产品所能达到的功能层次。写文档的时候事无巨细吧，人家会嫌你写的太繁琐了；写的太简单吧，人家又会嫌你没说清楚该说的；开始使用敏捷模式要求文档弱化了，但其实只是在过需求的时候不需要提前先把PRD写好，事后还是得补的；写文档耗掉的时间多了，人家会说能否除掉一半，功能需求都确认好了，你只是将它描述出来为什么要用掉那么多的时间？凡此种种，都让做产品的我们感觉命怎么这么苦，因此开拓一种写PRD的新思路新方法是相当有必要的。
现在都讲究用工具来辅助，工具用的好，确实能事半功倍，那要是工具用的不好呢？那就只能自求多福了。原型设计软件的主要功能还是用来做原型，那是否原型演示完了之后就没有用了呢？这个我想有点工作经验的人都不会这么认为，当然我们还是可以发挥一下原型的剩余价值的。
大家都知道，如果一份文档里面可以图文结合，所描述的东西更能吸引到人去阅读，也更能帮助别人理解。AxureRP所设计的原型支持HTML格式的浏览，相较于其他原型设计软件直接产出图片，AxureRP的原型即可以直接导出成图片格式，也可以通过在浏览过程当中用截图软件来截图的方式使用，当然后一种方式更为繁琐，后面说明为什么直接生成图片反而不方便。
使用AxureRP自带的文档生成功能去生成PRD文档这点我在之前写AxureRP使用教程的时候有提到过，AxureRP是支持通过即定的word模板格式来导出生成文档的，可以参考《AxureRP教程–生成规格说明书》。不过使用这个功能对自身的要求是比较高的：1、要对AxureRP所提供的注释功能非常熟悉，其默认提供的注释字段是国际通用的，并不适合中国国情，要根据产品和项目的需求进行修改和自定义。
要了解组件注释和页面注释的使用方式，以及这些注释会出现在文档的什么位置等；2、要在做原型设计的时候就做好注释的录入，每个组件的交互，前置触发条件，后置反馈事件，以及每个页面的功能说明等，这是一项细致活，挺耗时间的，和快速原型设计的要求不大相符；且万一在确认需求的过程当中需要修改的，这个维护量也比较大；3、要熟悉word的格式排版设置，用AxureRP默认提供的word模板生成出来的PRD文档，估计不符合大多数公司的文档编写要求，如果没有要求的则可以直接使用，否则就得自己倒腾一个word模板出来，这个对word的功底要求较高，再就是还得熟悉AxureRP里面模板导入的机制和模板使用机制；4、综上所述，这个功能虽然很强大但实际应用的较少，其实比较鸡肋，个人是已经放弃了，有兴趣的朋友可以深入研究一下，到时分享一下； 基于AxureRP原型的PRD文档编写这个方式其实就是截图，然后用截图+文字的形式来书写PRD文档，有人就说了，图片制作软件那么多，为什么非得用AxureRP来做原型，还得截图呀，这里有个已经使用AxureRP的前提：1、AxureRP提倡快速原型设计法，可以大大减少原型设计的时间，这是选择使用AxureRP的一个原因；2、AxureRP支持HTML格式的浏览，极大的方便了原型的演示效果，可以很清楚地告诉演示对象每个页面的跳转，每个按钮的操作效果，每个连接点击结果等，这是选择使用AxureRP第二个原因； 当然AxureRP的优点不止于此，原因可能很多，但主要的是这两个方面，这两个前提决定了我们当前都是使用AxureRP来做原型设计的，然后再讨论如果在已经使用AxureRP的情况再来优化截图写PRD的方法，否则就没法进行下去了。1、为什么是HTML格式页面的截图而不是直接导出图片？这个从操作层面上来讲，导出图片的模式操作流程如下：导出为图片>>>打开word>>>选择插入菜单>>>选择插入图片>>>搜寻图片所在文件夹>>>选择图片>>>点击按钮完成插入图片操作；或者是下面这种方式：导出为图片>>>打开图片所在文件夹>>>选择插入图片并打开>>>复制图片>>>打开word>>>粘贴图片完成插入图片操作；这个比上面的省一个步骤；从HTML页面截图的模式操作流程如下：打开对象所在HTML页面>>>用截图工具截图>>>复制所截图片>>>打开word>>>粘贴图片完成插入图片操作；对比一下就知道，用截图的方式所需的操作步骤是最少的，也就是最能节省时间的，这里推荐一个截图工具：Snagit（下载地址），可以对所截的图进行一些简单的编辑，比如画个圈圈提示一下，画点箭头什么的。
2、基于AxureRP原型截图这种方式更能适应需求变化。大家都知道AxureRP是支持单个页面的修改单个页面重新生成原型的，不需要整体原型重新生成一遍，这样某个地。