PRD(产品需求文档),产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述

什么是产品需求文档

该文档是产品项目由"概念化"阶段进入到"图纸化"阶段的最主要的一个文档。当然,这个定义针对的是一个全新的产品。广义上来讲,产品需求的描述,应该包含有产品的战略和战术,战略是指:产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。
PRD的主要使用对象有:开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑;测试可以根据PRD建用例;项目经理可以根据PRD拆分工作包,并分配开发人员;交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前,必须要通过评审确定的最重要文档。

产品需求文档的要素

文档的命名和编号
文档的编号和命名很关键,每个产品都是经过若干个迭代才完成的,而每个迭代所完成的产品功能或者升级的需求都可能是不一样的,因此需要定义清楚该文件属于产品的哪个迭代,修改了几个版本。文件命名的方法一般是通过版本号定义,比如简单的方法是,XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号,后面的V2 PRD的版本号。稍微详细点可以定义成,XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名,这样更便于阅读和记忆。
文档的版本历史
包括,编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序,文档版本显示的当前修改的内容属于文档的第几个版本(或第几次修改,一次修改一般为一个版本),章节是具体到修改内容属于的功能模块,以便阅读人及时找到修改后的内容,修改原因说明为什么要修改该需求,让阅读者直观的了解原因。日期是指需求文档修改的时间,修改人是指需求内容的修改者。
目录
不需要自己新建,文档完成后直接更新模版中的目录即可。目录是用来了解文档结构的
引言
这部分的内容有:产品概述及目标、产品roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明。
产品概述:解释说明该产品研发的背景以及核心功能。
产品roadmap:为产品规划的蓝图,每个关键阶段完成的核心任务。产品研发是个不断迭代的过程,需要经过若干个版本的迭代,,对一个功能点做了N个迭代后最终又回归到了第一个迭代是很常见。产品经理需要做好心理准备。产品roadmap并不需要全部规划好所有的阶段目标,但是对产品未来发展趋势的一种预估,要达到目标,需要更多的更新和迭代。清晰的呈现产品的roadmap可以帮助产品经理把握产品的全貌,更好的控制研发过程。
预期读者:文档的使用对象
成功的定义和判断标准:旨在说明产品的目标
参考资料:PRD的参考资料
名词说明:名称、说明。名称就是对文档中会出现的比较新的名称,说明则是对这些名称进行解释。
需求概述
需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等。
需求概览:分两部分,一是业务流程图,对产品整个业务流程的发生过程做图形化的展示,是对产品整体功能流程的阐释。二是需求清单,对本次要开发的需求任务做分类,给出简明扼要的需求描述并标注优先级。
用户类与特征:产品的最终用户,确定产品的最终使用者,并对使用者的角色和操作行为做出说明。
运行环境:该产品上线后的使用环境,比如支持的浏览器及其版本,操作系统、数据库的要求等等,测试人员在看到环境要求后会在测试时重点测试,而最终上线产品时需要把最佳的运营环境告知给用户。设计和实现上的限制:比如控件的开发环境、接口的调用方式等等。
项目计划:对于prd中要开发的内容,给出关键里程碑,比如需求评审通过的时间、开发的完成时间、上线时间等等。
产品风险:描述产品可能存在的风险,比如性能瓶颈,没有解决的问题,用户不当使用的风险等等。
功能需求
功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容:
简要说明:介绍此功能的用途,包括其来源或背景,能够解决哪些问题。
场景描述,产品在哪种情况下会被用户使用,就是用户场景模拟。这也是产品经理讲"好"故事的必备条件。
业务规则:每上产品在开发时都有相应的业务规则,将这些规则清晰的描述出来,让开发、测试人员能够直观的明白该规则,且没有产生歧义。业务规则必需是完整的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改,建议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明,什么时候可见,不可见,灰掉或点亮的条件在文档中都给出说明。方便阅读者理解业务规则。
界面原型:如前所述,涉及到页面交互的部分,产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师一起来完成。建议的做法是,产品经理可设计一个页面框架,将该页面要呈现的字段及其特征以及页面要使用的场景向交互设计师解释清楚。之后交互和视觉设计师完成产品的原型设计。
使用者说明:对产品使用者做出说明,可融入简要说明中。
前置条件:该需求实现依赖的前提条件。比如,上传照片时,需要存有图像文件。
后置条件:操作后引发的后续处理。
主流程:把主流放在最后是有道理的,结合上面所说的,做出主流程说明,对每个功能流程走向分点说明(这是非常重要的)。
看过很多的PRD,文档中对既没有前提条件,也没有后置条件,只对主流程做了说明,但是在描述主流程时却没有描写主流程中每个功能流程的各种走向,只有一个主走向,让人感觉prd成了操作手册。事实上,对分支的介绍是非常重要的,开发和测试中提出的各类问题均与对分支的定义不明有关。