写了多年PRD后,他总结了PRD语法、形式、自查(附大厂模板)
共 4455字,需浏览 9分钟
·
2021-06-10 21:09
![](https://filescdn.proginn.com/0a039675a85d79268fb6f2d20fe50477/1dc0eac700c44a2a7378b13624eade40.webp)
第108篇原创
![](https://filescdn.proginn.com/0a039675a85d79268fb6f2d20fe50477/1dc0eac700c44a2a7378b13624eade40.webp)
本文总结一个最基础的话题:PRD。目录如下: 一、PRD的形式
二、PRD的语法三、PRD的自查方法
一、PRD的形式
1、原型附带文字
移动端产品当然是把产品DEMO展示出来为第一位。
附带的文字,多是对原型的交互的说明、取值逻辑说明等。
比如这样:
![](https://filescdn.proginn.com/08c52687e03422a74106373b6aa66ee5/982c47755b8a10005d4a366b4ae9ca15.webp)
比如这样:
![](https://filescdn.proginn.com/25a357ec3ac63dbdb2454bfcc9185e9d/ee84a737a25ce7993d44530b521d7017.webp)
2、文字附带原型
逻辑过重的后端需求,干脆就使用Word/Excel/TXT格式的PRD。
好处是在行文的过程中,可以二次梳理思路,暴露问题。
一般这样的需求文档都包括:
版本说明(含变更日志)、背景、目标、需求范围、需求用例(正文,包含所有核心内容,如功能逻辑说明等)、参考资料等。
(1)需求背景
现状
当前业务流程怎么了,当前功能是怎么样的,问题是什么,需要怎么办,以达到什么目标。
用户故事
也可以更简单的以“作为谁,希望通过什么,实现什么”这样的用户故事形式也可以。
场景
是需求的外在,拆解和穷尽需求场景,为穷尽功能和逻辑规则打基础。拆解需求场景的方法:
按业务顺序,想象或模拟用户操作顺序;
按目标生命周期,比如草稿、待审核、审核中;
按正常、异常、正向、逆向,形成交叉矩阵。
(2)需求目标
用户角度的验收标准,即从效果的角度表达需求的预期(不表达如何实现)。
例如:
a、用户在点击页面之后3秒内必须加载完成。
b、用户能看到自己买到的商品。
c、用户可以删除自己的商品购买记录。
(3)需求范围
需求范围就是描述需求的目标项、边界、排除项,其作用是理清边界。
目的是防止需求蔓延(参考PMBOK指南)。
需求范围可以使用功能框架图。
需求用例是需求的正文部分。
先将需求分成任务点,进行描述。
描述的语句要严格按照文档语法原则进行(下文会继续聊到)。
如下图:
![](https://filescdn.proginn.com/818d26a454c86a50c0c160c8d3eae788/d31bd9cb6e3bcf900c15ad33f82077b1.webp)
(5)参考资料
参考资料部分,附上调研过程中查到的相关模板、数据表、脚本、接口地址、历史文档、原型链接等。
二、PRD的语法
这里主要以Word样式的PRD为对象。
1、需求文档的语法
(1)说明文一字千金
需求文档就像是说明书一,去掉形容词、比喻句、副词等。
能用一句话说明的就不要说第二句。(3)避免用词不当
在文档或口头交流的时候,经常用到诸如“维度”、“颗粒度”、“参数”、“字段”、“项”、“列”、“表”等词汇。
产品需求文档中,要做到用词严谨,避免词语歧义或失准。
常见用法例如:
以“订单号+产品编码”的[维度]进行唯一性判断;
按照“订单”[颗粒度]进行汇总;
以“时间”作为请求[参数];
数据库的[字段]为“number”;
页面搜索栏的“姓名”搜索[项];
页面列表的“年龄”[列]。
(4)按顺序描述
开发和测试人员通常希望将一个模块的工作做完,再进行下一个,而不是来回跳。
因此行文顺序上,按照先后、左右、大小等常规的顺序进行,一个模块写完再写下一个。
前面写过的内容,后面不要再写了,避免歧义。
比如:要在已有接口增加获取一个字段,并在页面展示,可以这样两步描述:
a、在xx接口,增加xx字段,存入数据库xx表。接口逻辑调整为xx。旧数据初始化方案是xx。
b、在xx页面列表中,新增一列“xx”,对应取值是数据库xx表中的字段xx。
(5)以“在哪里,做什么”为主线
文档以任务线为核心句式结构,即:“在哪里,做什么”。
尽量用正向语序,不要倒叙,也不要用括号或破折号。
比如避免前面描述完,后面又接着一个“即xxxxx”、“也就是说xxxxx”。
(6)非本需求的功能,不要放在文档中
产品经理是信息布道者,信息中枢。
而开发和测试人员,是希望所见即所得的阅读方式。所以不必要的任务不要加入进来。
比如不要使用“可能这次要做”、“注意,这个本次不做,只作为提前知悉”之类的内容。
正文一定传达的是“做什么”。如果想补充,那么放在参考资料部分。
(7)采用合适的行文结构
1)如果需要在旧功能基础上做优化,可以用对比结构进行描述,比如:
修改前:xxxx;
修改后:xxxx;
2)对于并列条件较多的,可以用平行列举的结构描述,比如:
每天一次,定时监控【退款单】(表f_oms_refund),若同时满足下列条件:
同时满足上述条件,则进行数据抓取。
①数据更新时间为前两天;
②退款成功的(refund_status为:2、5、8、12、24任一个);
③rma_sn不为空;
④order_sn已存在于【发票列表】中。
注意:如果不熟悉数据库,建议不要写数据库,而是要写清楚页面取值位点并配以截图,避免弄巧成拙。
3)如果需求点有多个,但属于同一个页面功能模块下的,那么可以放在一个用例中,分点描述,就像书本的目录一样进行编号。
(8)穷尽原则
“穷尽”是方案严谨的基础。
穷尽包括穷尽需求的功能点,穷尽每个功能点的要素,穷尽每一个逻辑判断、性能要求、异常机制、用户权限等。
比如:做一个新页面,就要从导航栏目、界面交互、搜索功能、网站介绍性文字、默认列表展示内容、列表数据统计等全部说清。
同时对于后端产品而言,基本上每个需求都要说明性能要求、异常机制等。
(9)最后,不要遗漏对性能的要求、对历史数据是否处理、以及权限要求
性能的要求,如果不懂技术术语,则写出性能支持的数据或现象范围。
比如:预计半年内数据量为100万/天,要求接口响应3s内。
历史数据是否要初始化,及与发版的时间顺序。
权限就是赋予页面数据、功能权限。
2、通用项进行统一
(1)命名统一
页面一些常见的插件的命名可能有多个版本,产品经理需一开始就在需求文档中确定用哪一个。
比如下面这几组意思相近的插件名称:
a、表示删除或禁用的:删除、禁用、关闭、封存;
b、表示启用的:开启、启用、生效;
c、表示设置的:配置、设置;
d、表示编辑的:编辑时间、修改时间、更新时间、操作时间。
(2)数据库表中的通用字段命名统一(开发负责的)
比如:
每个开发习惯不同,所以要固定用哪一种,避免千人千面。
a、是否已写入:用“is_use”、“is_used”还是“is_write”表示?
b、已写入/未写入:用“1/0”,还是用“1/2”表示?
笔者曾经遇到一个开发比葫芦画瓢,把“goods_sn”(商品编码),写成“good_sn”,这就闹笑话了。
(3)页面展示统一
比如:数据表为空字符串时,前端展示什么,是显示“/”,还是空白?
可以使用日期+模块名+需求名称+作者+版本号,例如:20180920_【个人资料】编辑个人资料优化_张三_V1.0。
三、PRD的自查
需限定输入的范围,做输入校验。
示例:最多输入10个数值,输入不合规则的内容,则在输入框下方红色字体提示,比如:“请不要输人汉字!”。
(2)下拉框
下拉的同时是否支持输入搜索,是否支持多选。
(3)导入文档
表头校验、自校验、与系统校验、写入逻辑(全部不予导入或部分导入)、下载结果文档;
(4)已有功能的逻辑规则变更
则要考虑旧数据兼容或初始化。
(5)基础数据删除
则要考虑基础数据被调用的地方,删除和编辑怎么处理。
比如:
商品分类中维护的“商品类型”被删除,那么再编辑和删除该分类下的历史数据的时候就可能报错,所以基础数据维护时候要校验调用情况。
(6)设置规则
考虑规则去重、规则优先级。
一般情况下,没有优先级的话,规则的去重和命中次序校验起来比较麻烦。(在<后端产品经理宝典>一书中有专门介绍)。
(7)列表的数据的排序
一般按照修改时间的倒叙排列,也可以用数据库id代替序号。
用数据库id的好处是,方便用户和技术协作追溯数据。
(8)异常机制
每时每刻都要有逆向思维,告诉开发人员什么算异常?异常了怎么标示出来。
比如:
表1字段A,匹配表2字段B,将匹配成功的数据写入表3。就要考虑表1中字段A为空的情况该怎么办。
(9)页面长期不登录
则给自动退出。主要考虑到后端系统的保密性。
(10)凡是带操作的
一般都要设置页面权限。
最简单的方式是所有系统的权限都分三个等级:不能查看、只能查看、可以编辑。
(11)功能修订
比如规则变更,需要考虑旧数据是否要按照新规则进行初始化。
2、按需求类型自查
(1)功能需求
需要穷尽功能覆盖的使用场景,穷尽本功能相关联的各个系统模块,穷尽本功能的用户角色、权限。
(2)性能需求
数据量较大时的系统压力、反应速度;
批量上传、下载要考虑数量上限,考虑是否异步处理;
考虑浏览器兼容性;考虑调用接口超时的备用策略等。
(3)安全需求
敏感词屏蔽(同步过滤和异步召回)、防刷单机制、数据补推机制、风险预警等。
3、关键词提醒自查
笔者不完全罗列了几个关键词,可以作为自查的维度。
(1)完整
流程是否存在断头路。
比如当正常流程无法传输的时候,是否可以用导入的机制救急。业务高峰的系统,是否有降级处理逻辑。
默认:是否给予了默认值。
比如设置规则功能业务未设置怎么办?
4、其他
自查的方式还有很多,比如也可以按照“增、查、改、删、显、传、算”自查等。
总结
需求文档最基础,努力做到心中有典型功能,逻辑自查举一反三,需求要点不缺失,文档内容不歧义。
产品经理要养成好的态度和习惯。比如:
1)保持学习学习其他人的文档书写长处,可以把好的东西借鉴过来,吸取精华。
2)要自己多看多换位思考,揣摩他人是否能读懂,把问题止步于自查。
3)请求同事(包括产品经理、程序员、测试员等)帮助互评自己的文档,接受对方的建议。
4)文档是改出来的,因此自己写好后,放一段时间再看,再改。
PRD模板实例
![](https://filescdn.proginn.com/df5311d733c268da2476c9c108f21ee4/2310b3fe795f4b0b257c609a35e14f2d.webp)
本文转发朋友圈,截图加管理员领取
——往期推荐——