PRD的标准写法一套全面文档规范(完整版带模板)

做产品经常会写PRD,但是如果没有一套完整的写作思路和框架,写出的PRD质量就不会太好,导致遗漏重要信息,在项目过程中被开发、前端、测试吐槽。趁这个周末有空,来梳理下一下写PRD的逻辑。

一、什么是PRD?

PRD为Product Requirement Document的简称,其中文翻译为:产品需求文档。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然,这个定义针对的是一个全新的产品。广义上来讲,产品需求的描述,应该包含有产品的战略和战术,战略是指:产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等,本文主要讨论的是战术部分。

PRD的主要使用对象有:开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑;测试可以根据PRD建用例;项目经理可以根据PRD拆分工作包,并分配开发人员;交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前,必须要通过评审确定的最重要文档。

产品经理的PRD,就像建筑设计师的设计图纸,是整个设计和思考的结晶;同时,也是思考过程呈现。《用户体验要素》作者在书中有一句很经典的话:“文档不能解决问题,但是定义可以”,这也是PRD的另一个重要的作用:定义产品需求,在团队内达成共识。

二、写作的逻辑

写PRD,其实就是一个产品的业务需求分析过程,最近在看一本书,叫《火球UML大战需求分析》,里面提到了需求分析过程,作者的这个需求分析思路是基于传统软件/系统,但是我觉得这种思路是相通的,可以应用于所有产品。我根据这个思路,做了部分改良,形成了以下的逻辑:

  1. 整理产品结构
  2. 分析核心业务流程
  3. 分析及整理用例
  4. 分析及整理非功能性需求
  5. 整理需求文档并评审

整理产品结构

就像修建一座商场,在设计的时候,需要考虑整个商场的结构,商场包含美食区、服装区、百货区、休闲娱乐区等,然后每个区域又可以按商家或类型细分。产品也是这个道理,产品是由功能和内容组成,这些功能和内容,按照某种纬度,组成频道/模块,最终形成产品的整体结构。由于产品的结构一般比较大,这里仅以产品结构中的个人中心这个模块为例:

产品结构

产品结构一般通过MindManger梳理。需要注意的是,产品结构≠页面结构,产品结构是逻辑上的,页面结构是物理上的,至于具体的结构和方法,可以参看《用户体验要素》一书。

分析核心业务流程

每个产品,都会有几个核心的业务,分析并梳理出几个核心业务流程,可以帮助产品经理了解产品逻辑。笔者做的是B端产品,核心业务流程一般都会涉及到多个角色,而C端产品,核心流程的用户则比较单一。涉及到多个角色的业务流程,可以使用泳道图,单个角色可以使用普通的活动图。另外,在分析业务流程的时候,还可以配合使用状态图和顺序图,具体使用什么工具,视情况而定,重点是梳理清楚逻辑。

分析及整理用例

这个步骤是更具体,也很重要的的一步,前面2个步骤确定了范围和流程,这一步针对流程上的某个节点来具体描述。以会员中心→内容管理这个模块为例,这个模块下面包含的用例有:

  1. 新增文章
  2. 修改文章
  3. 删除文章
  4. 查看文章列表
  5. 查看文章详情

现在,就可以按照上面这个列表,来一一的描述用例。一个完整的用例应该包含以下主要内容:

用例卡片

在描述需求时,有2种方式,一种是用例描述,另外一种是功能点描述。用例描述和功能点描述最大的区别在于,描述的角度不一样,用例是从人和系统的旁观者来描述,而功能点是从产品的角度来描述。通过用例描述需求,最好用文档,并且有统一的用例模板,而功能描述只需要在Axure里,以注释的方式描述即可。

其实,关于需求怎么描述,没有完全正确的方式,只有最合适的方式,具体因人而异。《启示录》一书作者就建议描述产品需求只需要高保真原型+注释就可以,完全不需要文档,以下是书中的一些观点:

产品说明(需求)文档的主体应该是高保真原型,由它体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计。高保证原型最大的优势是可以用于测试。

与其花几个星期撰写冗长的Word文档,既没人读,也无法测试,还不如和设计师一起创建原型。

详细内容可以参看这本书的第十八章,「重新定义产品说明文档」一节。

不管是用例描述还是功能描述,规则都是最重要的一部分,这里主要讲一下如何描述能完整无误的阐述需求并让阅读者看懂。规则的描述,主要是从3方面思考。

  • 数据规则。主要指页面从数据库调取数据并展现的规则,比如查看文章列表这个用例,需要描述文章列表页面展示哪些字段、每个字段的类型及长度、列表的排序规则刷新频率等。
  • 状态逻辑。文章不同状态之间切换的触发点是什么,比如状态为已发布的文章,要变为下架,可能的触发条件有:发布时间已过期、手动操作下架等。
  • 交互规则。界面上存在交互的元素,一一列举并说明,比如链接、按钮、滑动、下拉的具体交互规则及异常处理。另外,整个场景由于网络问题、系统问题导致的异常也需要说明。

分析及整理非功能性需求

非功能需求涉及比较广,比如产品的性能需求,访问速度达到多少、最大能支持多少人同时访问;比如设计需求,产品要设计成小清新风格还是成熟稳重的风格等;还比如统计需求,产品要统计哪些字段,形成哪些报表等。这个可以根据具体的需求来描述。

整理需求文档并评审

当完成以上4个步骤以后,整个产品的逻辑已经很清楚了,再将产出物汇总,就可以整理出需求文档。文档出来后,需要和项目相关的负责人一起评审,评审确认通过,就可以进入产品的实施阶段。实施一般是由项目经理负责,但是很多公司没有配备该岗位,这就要求产品经理拥有项目管理的能力,来推动产品顺利实施并上线。

三、PRD文档的格式

目前市面上各种需求文档,五花八门,千万不要试图找到一个100%完美的文档模版,PRD文档,只有最合适的,没有最好的,每个人所在的公司背景都不一样,大公司要求文档规范,细节到位,小公司可能只需要记录关键信息,剩余的靠口头沟通,甚至都不需要文档。还有些人,直接通过Axure描述产品需求。

PRD文档,最重要的还是以上的整个思考和整理的过程,当以上步骤梳理清楚后,文档只是水到渠成的产出。我的原则是,只要内容清楚,文档格式没那么重要。

01 你是否遇到过这样的问题?

  • PRD里关键需求描述不准确,研发过程中不断修改,导致项目延期;
  • 产品总监、项目经理、研发、测试总是不断挑刺,信誉度降低,自信心受打击;
  • 到新公司负责新项目,前任产品经理留下的文档晦涩难懂,不知所云。

如果遇到以上一个或多个问题,那么你可能需要反思,自己写PRD的思路是不是有问题?写PRD是产品经理非常重要的基本功,写好PRD,可以提高团队效率,减少无效的沟通。

02 什么是PRD?

PRD是Product Requirement Document的简称,其中文翻译为:产品需求文档。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最重要的一个文档。

PRD的主要使用对象有:研发、测试、交互设计师及其他业务人员。

  • 研发可以根据PRD获知整个产品的逻辑,作为编码的依据;
  • 测试可以根据PRD编写测试用例,为正式测试做准备;
  • 交互设计师可以根据PRD设计交互细节;
  • 业务人员可以通过PRD提前了解产品,为运营和推广做准备;

PRD是项目启动之前,必须经过评审达成共识的最重要文档。

产品经理的PRD,就像建筑设计师的设计图纸,是设计和思考的文档化呈现。

《用户体验要素》作者在书中有一句很经典的话:“文档不能解决问题,但定义可以”,PRD就是要定义需求。

03 动手之前,先思考这几个问题

1. 解决什么问题?

解决用户什么问题?发现问题比解决方案更重要。给公司能否带来收益?相关干系人的需求是什么?是不是老板说这样做的?是不是“他们”说这样做的?他们是谁?真正的问题是他们说的那样吗?

产品经理正确的设计思路如下:

这叫RTPA设计框架,是一种逆向思维假设分析,我们要使用这样一种思考技巧:假设初始需求都是错误的,即问题并不存在,你需要重新发现问题。

不要需求方一提需求,就开始着手设计,多问几个为什么并着手调查,以了解真正的问题。

下面是一次完整的设计思路示例:

2. 怎么衡量?

不同的干系人,通过什么指标去衡量问题是否已解决?有没有埋点?有没有业务数据?谁来运营?

3. 需要多少资源?

为了实现这个解决方案,需要多少资源、多少人?能大致评估吗?

4. 会不会太复杂?

这个解决方案会不会太复杂?复杂是产品的坟墓。有没有性价比更高的解决方案?会不会影响现有的业务?会不会影响历史数据?

5. 有风险吗?

这个方案会有风险吗?有没有违法?相关政策是什么?尤其是金融、游戏领域,国家监管比较严,有可能上不了应用市场,有可能三方服务商不会提供服务。

6. 有创新吗?

有更创新的解决方案吗?竞品怎么做的,有没有调研3个以上的竞品方案。

7. 用户怎么说?

需求真的是提交人说的那样吗?有亲身体验过场景吗?有跟用户面对面交流吗?熟悉相关领域的基本知识吗?有看不懂的名词吗?

动手写文档或做设计方案之前,一定要问问自己以上几个问题,想清楚了在动手,任何一个问题没想清楚,都不要进行下一步。

04 写PRD的基本步骤

搭框架、定流程、扣细节,这是从一名产品前辈那了解到的产品设计流程,写PRD,也可以按照这个思路。

1. 搭框架

首先遍历出所有用户角色,再针对每个角色,提供相应的系统/功能,然后按照某种维度进行结构划分。这个步骤完成后,就可以输出产品的系统架构图及系统的功能结构图。

产品架构图,出自《电商产品设计全攻略》

更细化的功能结构图

产品由一个个功能组成,功能是逻辑结构,一个完整的功能具备输入、处理、输出三大特性。从大到小的划分是:系统>功能模块>功能,用户+功能组成了用例,用例是PRD文档里描述占比70%以上的内容,所以合理的功能结构,是写好PRD的前提。

2. 定流程

每个产品都有一个核心业务流程,这个核心业务流程涉及多个角色,这个步骤就是把各个角色和功能联系起来。通过核心业务流程,阅读者可以了解产品全貌,对产品有个宏观的认识。

此外,每个系统也有各自的核心业务流程,全业务流程+子系统业务流程,可以概括产品的业务逻辑。

这个步骤输出产品核心业务流程图,子系统核心业务流程图,活动图,状态机图,与外部系统交互可能还有时序图。

3. 扣细节

这一步的核心的画原型和功能设计,通过原型表达产品的界面和交互。功能设计主要是从输入处理输出三个方面去考虑,用户执行输入指令后,系统会进行逻辑处理,然后输出结果。此外,还要考虑功能涉及到哪些数据,表结构怎样设计,这些会涉及大量细节,PRD大部分内容,都是在描述这些细节。

步骤1和步骤2没有严格的顺序,也可以先梳理业务流程,再根据流程中的具体场景梳理出实际功能或系统结构。

05 文档的组成部分

1. 修订记录

记录每次文档更新的时间、作者、修订内容,便于追溯历史变动;

2. 全局说明

包括名词解释、统一异常处理、列表默认数据规则等。

  • 名词解释:每个行业都有专业术语,可以提前将晦涩难懂的术语提前做好解释,便于达成共识,更好沟通;
  • 统一异常处理:网络异常、后台服务异常的交互逻辑;
  • 列表默认数据规则:默认列表的排序方式,默认显示条数,超过多少条翻页,缺省值展现方式;
  • 所有涉及全局的描述,都可以罗列在这里。

3. 项目背景

每个产品,都有一套价值模型。以信贷产品为例,针对用户的价值指标有放款额、审批时长、是否上征信等;针对后台业务人员,有审批时效、通过率、放款率、坏账率等指标;针对老板,有投资回报比、员工成本、净利润等价值指标,每一个需求,应该都是围绕某个价值指标展开。

背景从现状、方案、目标3方面描述。

  1. 现状:描述当前需求方遇到的问题,最好能跟价值模型关联;
  2. 方案:针对这个问题,所提供的解决方案概述;
  3. 目标:期望获得多少价值指标提升;

通过项目背景的描述,可以让项目参与者感受到自己的工作价值。

4. 项目范围

项目范围对应搭框架部分,将功能结构图在此处罗列;

5. 业务流程

业务流程对应定流程部分,将核心业务流程、子系统业务流程在此处罗列;

6. 功能需求

这个部分在PRD中占比最大,搭框架部分,已经将产品功能点全部梳理出来了,这部分就是对功能点进行逐一描述。

功能是从系统的角度来看,我们还要考虑用户角度,所有我们采用用户+功能的方式来描述需求,这就是用例。完整用例名称一定是动宾结构,如添加文章、删除文章、修改文章、查看文章列表。

一个完整的用例包含:

  1. 描述(非必须)
  2. 前置条件
  3. 后置条件
  4. 界面交互
  5. 业务流程
  6. 异常和分支流程
  7. 数据字典(非必须)

1)描述

功能的简要描述。

2)前置条件

要操作此功能,需要具备什么角色、权限或状态。

3)后置条件

执行完这个用例后,关联的数据会有什么变化,页面怎么跳转。

4)界面

每个界面都可以拆分成多个元素,如表单、文本、链接、图片等;

表单的每个元素要描述是否可为空、是否有初始内容、是否默认选中、是否有字数限制等,还有对应的错误提示;

文本要考虑最大显示长度,超过怎么处理;

链接一定要指定点击后跳转到哪个页面;

图片要考虑显示的比例,如果未加载出来该显示什么;

还要考虑界面的内容是写死还是通过后台配置;

界面元素:

5)业务流程

当用户完成输入并提交时,后端应该做什么校验,不同输入该怎么处理,不同结果该返回什么值,最好通过业务流程图+文字来描述,确保逻辑完整。

示例:

文字版:

6)异常和分支流程

异常流程如网络错误、接口返回异常、服务器内部错误等;

以登录为例,分支流程包括找回密码、密码登录等,分支流程非必须,简单的分支流程可以直接通过主流程体现,具体可以视情况按照一定颗粒度进行拆分。

7)数据字典

这个用例涉及哪些数据,可以通过数据字典描述,这一步非必须,最终表结构也不一定就是这样,只是给开发一个参考。有技术背景的产品,也可以做得更细。以注册功能涉及的用户表为例:

产品经理一定要懂基本的数据库知识,程序=数据结构+算法。用户使用产品时,本质上是在和数据进行交互,只是在用户和数据之间,加了一些列算法。

7. 非功能需求

数据需求。常见的就是数据埋点,产品经理需要梳理出埋点事件表,告知开发,让开发在编码过程中进行埋点。

监控需求。需要监控某个接口或某些服务,当出现异常时,可以发送报警信息至相关人员。

性能需求。需要支撑多大的并发,运维人员可以提前准备部署方案。

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/3242.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息