PRD(Product Requirement Document)产品需求文档,是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档,其作用就是“对MRD中的内容进行指标化和技术化”,这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
PRD的意义:该文档在产品项目中是一个“承上启下”的作用,“向上”是对MRD内容的继承和发展,“向下”是要把MRD中的内容技术化,向研发部门说明产品的功能和性能指标。
为什么会有PRD?
1、稍微大一点的团队产品经理未必能向每个人传达产品需求,就需要有一个文档的形式来向项目的所有成员来传达需求,这就是文档的来源。
2、由于产品经理经常会变更需求,经常爱拍脑袋,容易变卦,所以程序员就想到用一个文档来约束产品经理。
3、测试人员需要根据产品需求文档来验收产品质量。
4、当你的项目有新人进入的时候,可以让新人更快的了解产品。
5、有利于装逼。
主要内容:功能使用的具体描述(每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程等几大块),Visio做的功能点业务流程,界面的说明,demo等。Demo方面,可能用Dreamweaver、ps甚至画图板简单画一下,有时候也会有UI/UE支持,出高保真的demo,开发将来可以直接用的那种。
文档核心:该文档中,侧重的是对产品功能和性能(即“产品需求”)的说明,相对于MRD中的同样内容,要更加详细,并进行量化。在一些国外的公司,是允许把MRD和PRD合并成一个文档的,通常叫做“Marketing & Product Requirements Document”。
如何写出优秀的PRD?
1、需求
一个PRD首先应该展示的内容是需求,需求的背景是什么,没人会想做一个完全不了解或者没有意义的需求,作为项目的一分子,研发们有必要知道需求本身最重要需求背景是什么,需求意义是什么,而且PM和研发也有必要知道本需求有效的衡量方法:
需求意义:XX需求为XX解决了XX问题,以提升XX指标/体验
衡量方法:XX数据发生XX变化
2、业务
① 一个需求/项目里面包括了很多小的需求分支、业务逻辑、甚至是之前没有的名词和定义,这里需要用心考虑周全,业务上所有的角色流程都要考虑到。
② 相比大段的说明文档,可能大家需要一个逻辑图。
1)业务流程图
2) 操作流程图
3)功能流程图
4)新定义说明
3、页面
页面是用户真正看到的东西,这里的细节也是研发真正实现的时候最容易遇到细节不清楚的地方
1)角色方式
进入页面时是否分角色展示不同内容
2)展示方式
进入页面后,默认展示的样式、多信息排列的规则,UE图涉及到的逻辑变化、控件点击前后的细节、文字数目的限制等都需要做详细的描述
3)交互方式
页面中各个控件切换的交互方式是怎样的,是否有特殊的交互方式需要特别指出
4)退出方式
页面退出逻辑是否遵从从哪里进,退回哪里的逻辑(以场景判断,属于需求层面),若不遵从,需做明显标识
5)数据规则
刷新、缓存、加载、loading具体细节如何,都需要做出详细的描述,但是由于此部分涉及技术层面内容较多,故一定要与RD做好预沟通再将确定的内容填写只PRD