写了多年PRD后,他总结了PRD语法、形式、自查

PRD是产品由立项阶段进入到需求阶段的最重要的一个文档。简而言之,PRD就是将宏观抽象化的业务,拆分成具体化的功能需求,并通过文字或图像等方式呈现出来。

写了多年PRD后,他总结了PRD语法、形式、自查

一、PRD的形式

1、原型附带文字

移动端产品当然是把产品DEMO展示出来为第一位。

附带的文字,多是对原型的交互的说明、取值逻辑说明等。

比如这样:

写了多年PRD后,他总结了PRD语法、形式、自查

文字较多的,可以把原型靠右的部分都分简单排版。

比如这样:
写了多年PRD后,他总结了PRD语法、形式、自查

2、文字附带原型

逻辑过重的后端需求,干脆就使用Word/Excel/TXT格式的PRD。

好处是在行文的过程中,可以二次梳理思路,暴露问题。

一般这样的需求文档都包括:

版本说明(含变更日志)、背景、目标、需求范围、需求用例(正文,包含所有核心内容,如功能逻辑说明等)、参考资料等。

(1)需求背景

现状

当前业务流程怎么了,当前功能是怎么样的,问题是什么,需要怎么办,以达到什么目标。

用户故事

也可以更简单的以“作为谁,希望通过什么,实现什么”这样的用户故事形式也可以。

场景

是需求的外在,拆解和穷尽需求场景,为穷尽功能和逻辑规则打基础。拆解需求场景的方法:

按业务顺序,想象或模拟用户操作顺序;

按目标生命周期,比如草稿、待审核、审核中;

按正常、异常、正向、逆向,形成交叉矩阵。

(2)需求目标

用户角度的验收标准,即从效果的角度表达需求的预期(不表达如何实现)。

例如:

a、用户在点击页面之后3秒内必须加载完成。

b、用户能看到自己买到的商品。

c、用户可以删除自己的商品购买记录。

(3)需求范围

需求范围就是描述需求的目标项、边界、排除项,其作用是理清边界。

目的是防止需求蔓延(参考PMBOK指南)。

需求范围可以使用功能框架图。

(4)需求用例

需求用例是需求的正文部分。

先将需求分成任务点,进行描述。

描述的语句要严格按照文档语法原则进行(下文会继续聊到)。

如下图:
写了多年PRD后,他总结了PRD语法、形式、自查

(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)页面展示统一

比如:数据表为空字符串时,前端展示什么,是显示“/”,还是空白?

(4)文档命名统一

可以使用日期+模块名+需求名称+作者+版本号,例如:20180920_【个人资料】编辑个人资料优化_张三_V1.0。

(5)术语名词定义统一

比如跨境电商行业的“清关”、“保税”、“头程运费”、“尾程运费”、“大包”、“小包”等。

三、PRD的自查

PRD可形成一套自查规则。笔者抛砖引玉。

1、按功能插件自查

(1)输入框

需限定输入的范围,做输入校验。

示例:最多输入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)完整

流程是否存在断头路。

(2)逆向功能流程是否可逆,如果逆向操作,是否考虑对应的机制:比如退款、退货操作。

(3)异常即异常机制。各个步骤都可能出现预期外的情况。

(4)歧义需求文档的语法、功能文案、名词是否易懂,是否存在歧义。

(5)兼容是否存在兼容问题:不同业务人员对功能都能接受吗?各个系统之间兼容吗?新旧功能的兼容吗(比如历史数据要不要初始化)?

(6)备用是否有备用方案,次级选项。

比如当正常流程无法传输的时候,是否可以用导入的机制救急。业务高峰的系统,是否有降级处理逻辑。

(7)穷尽业务场景和可能原因是否穷举完毕。

默认:是否给予了默认值。

比如设置规则功能业务未设置怎么办?

(8)脱敏是否存在敏感信息,是否有脱敏机制。

4、其他

自查的方式还有很多,比如也可以按照“增、查、改、删、显、传、算”自查等。

总结

需求文档最基础,努力做到心中有典型功能,逻辑自查举一反三,需求要点不缺失,文档内容不歧义。

产品经理要养成好的态度和习惯。比如:

1)保持学习学习其他人的文档书写长处,可以把好的东西借鉴过来,吸取精华。

2)要自己多看多换位思考,揣摩他人是否能读懂,把问题止步于自查。

3)请求同事(包括产品经理、程序员、测试员等)帮助互评自己的文档,接受对方的建议。

4)文档是改出来的,因此自己写好后,放一段时间再看,再改。

业界动态

社区团购,告别补贴

2021-6-11 9:04:56

业界动态

招聘初级产品助理的时候,我最看中的是Ta的什么能力?

2021-6-11 9:27:25

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索