1.什么是prd
prd即产品需求文档;PRD的主要使用对象有:研发、测试、交互设计师及其他业务人员
-
研发可以根据PRD获知整个产品的逻辑,作为编码的依据;
-
测试可以根据PRD编写测试用例,为正式测试做准备;
-
交互设计师可以根据PRD设计交互细节;
-
业务人员可以通过PRD提前了解产品,为运营和推广做准备;
2.写prd的基本步骤
搭框架,定流程,扣细节
2.1搭框架
首先遍历出所有用户角色,再针对每个角色,提供相应的系统/功能,然后按照某种维度进行结构划
这个步骤完成后,就可以输出产品的系统架构图及系统的功能结构图
产品由一个个功能组成,功能是逻辑结构,一个完整的功能具备输入、处理、输出三大特性,从大到小的划分是:系统>功能模块>功能,用户+功能组成了用例,用例是PRD文档里描述占比70%以上的内容;
2.2定流程
每个产品都有一个核心业务流程,这个核心业务流程涉及多个角色,这个步骤就是把各个角色和功能联系起来。通过核心业务流程,阅读者可以了解产品全貌,对产品有个宏观的认识。
此外,每个系统也有各自的核心业务流程,全业务流程+子系统业务流程,可以概括产品的业务逻辑。
这个步骤输出产品核心业务流程图,子系统核心业务流程图,活动图,状态机图,与外部系统交互可能还有时序图
2.3扣细节
这一步的核心的画原型和功能设计,通过原型表达产品的界面和交互。
功能设计主要是从输入处理输出三个方面去考虑,用户执行输入指令后,系统会进行逻辑处理,然后输出结果。
此外,还要考虑功能涉及到哪些数据,表结构怎样设计,这些会涉及大量细节,PRD大部分内容,都是在描述这些细节
3.文档的组成部分
3.1修订记录
记录每次文档更新的时间、作者、修订内容,便于追溯历史变动
3.2全局说明
包括名词解释、统一异常处理、列表默认数据规则等。
-
名词解释:每个行业都有专业术语,可以提前将晦涩难懂的术语提前做好解释,便于达成共识,更好沟通;
-
统一异常处理:网络异常、后台服务异常的交互逻辑;
-
列表默认数据规则:默认列表的排序方式,默认显示条数,超过多少条翻页,缺省值展现方式;
-
所有涉及全局的描述,都可以罗列在这里。
包括名词解释、统一异常处理、列表默认数据规则等。
-
名词解释:每个行业都有专业术语,可以提前将晦涩难懂的术语提前做好解释,便于达成共识,更好沟通;
-
统一异常处理:网络异常、后台服务异常的交互逻辑;
-
列表默认数据规则:默认列表的排序方式,默认显示条数,超过多少条翻页,缺省值展现方式;
-
所有涉及全局的描述,都可以罗列在这里。
3.项目背景
每个产品,都有一套价值模型。以信贷产品为例,针对用户的价值指标有放款额、审批时长、是否上征信等;针对后台业务人员,有审批时效、通过率、放款率、坏账率等指标;针对老板,有投资回报比、员工成本、净利润等价值指标,每一个需求,应该都是围绕某个价值指标展开。
背景从现状、方案、目标3方面描述:
-
现状:描述当前需求方遇到的问题,最好能跟价值模型关联;
-
方案:针对这个问题,所提供的解决方案概述;
-
目标:期望获得多少价值指标提升;
通过项目背景的描述,可以让项目参与者感受到自己的工作价值。
4.项目范围
项目范围对应搭框架部分,将功能结构图在此处罗列;
5.业务流程
业务流程对应定流程部分,将核心业务流程、子系统业务流程在此处罗列;
6.功能需求
这个部分在PRD中占比最大,搭框架部分,已经将产品功能点全部梳理出来了,这部分就是对功能点进行逐一描述。
功能是从系统的角度来看,我们还要考虑用户角度,所有我们采用用户+功能的方式来描述需求,这就是用例。
完整用例名称一定是动宾结构,如添加文章、删除文章、修改文章、查看文章列表。一个完整的用例包含:
-
描述(非必须)
-
前置条件
-
后置条件
-
界面交互
-
业务流程
-
异常和分支流程
-
数据字典(非必须)
描述:
功能的简要描述。
前置条件:
要操作此功能,需要具备什么角色、权限或状态。
后置条件:
执行完这个用例后,关联的数据会有什么变化,页面怎么跳转。
界面:
每个界面都可以拆分成多个元素,如表单、文本、链接、图片等;
表单的每个元素要描述是否可为空、是否有初始内容、是否默认选中、是否有字数限制等,还有对应的错误提示;
文本要考虑最大显示长度,超过怎么处理;
链接一定要指定点击后跳转到哪个页面;
图片要考虑显示的比例,如果未加载出来该显示什么;
还要考虑界面的内容是写死还是通过后台配置;
界面元素:
业务流程:
当用户完成输入并提交时,后端应该做什么校验,不同输入该怎么处理,不同结果该返回什么值,最好通过业务流程图+文字来描述,确保逻辑完整。
示例:
文字版:
异常和分支流程:
异常流程如网络错误、接口返回异常、服务器内部错误等;
以登录为例,分支流程包括找回密码、密码登录等,分支流程非必须,简单的分支流程可以直接通过主流程体现,具体可以视情况按照一定颗粒度进行拆分。
数据字典:
这个用例涉及哪些数据,可以通过数据字典描述,这一步非必须,最终表结构也不一定就是这样,只是给开发一个参考。
用户使用产品时,本质上是在和数据进行交互,只是在用户和数据之间,加了一些列算法。
7.非功能需求
数据需求。常见的就是数据埋点,产品经理需要梳理出埋点事件表,告知开发,让开发在编码过程中进行埋点。
监控需求。需要监控某个接口或某些服务,当出现异常时,可以发送报警信息至相关人员。
性能需求。需要支撑多大的并发,运维人员可以提前准备部署方案。