PRD复杂逻辑怎么整?7个精选案例,没人告诉你的PRD漏洞,在这里!(附资料)

文摘   2024-05-27 22:21   湖南  
‍‍
【产品参赵221篇原创
关注公众号 “产品参赵” 右上角置为星标,开启进阶之旅
关注后  回复 1 即抽取50份电子书
回复 加我进群 
本文3.0K字,文末是一批免费资料


设计型”产品经理变为“方案策略型”产品经理,深入学习一段B端产品PRD就好了。




———————— 

方案型产品经理就是,不再只说“我要xx”(潜台词怎么实现我不管),而是思考“我要xx,逻辑是……”(潜台词是我已经想透了)。
方案设计更多体现在逻辑规则与整体架构的契合度上。差的方案往往让开发过程反复拉锯,事倍功半。
需求与方案的融合,对团队和谐、产品扩展,大有裨益!是产品经理的价值体现之一。
来聊聊产品新书<TOB产品经理之美>的提到的深度能力之一:中/后端需求方案(PRD)的话题。
PRD,不只是画个圆形标注下就是最好的。
原型+备注,一方面不正式,另一方面容易看漏,三方面是不利于存档保持信息不失真。
因此,要形成图文文档,是B端产品多数时候的PRD严谨的呈现。
那么怎么写好呢?
相信你看过很多大佬的文章,但是没几个人告诉你的真实现状,本文以例子形式介绍下。

1、想好方案,还要恰当好处的叙述

在PRD中表达“区间不能相互交叉”呢?

案例:

在一个Excel导入功能的需求中,要导入的内容是不同重量区间对应的费用计算规则。因此需求文档中,要体现不允许重量区间交叉。
如何描述呢?

描述一同一规则的任意两条数据,其重量区间不能有交叉
点评描述一
看起来比较需求化,但实际上存在一个问题,就是没有定义什么样才算是交叉。
因此,是需求描述的不清楚。
如果产品经理认为交叉是个白痴问题,无需定义(实际确实如此),但是开发的代码如果写错,就会出现对标不一致。
换句话说,产品理解这句话,开发也理解这句话的意思,测试也理解,但是没有确保大家的理解是一致的。
描述二同一规则的任意两条数据,假设重量区间分别为a-b、c-d,那么若出现a<e<b、a<f<b、e<b<f、e<a<f中的任意一种情况,则视为这两个重量区间交叉。

点评描述二
比描述一更加具体化,抽象概括,给出了定义。
但是实际上遇到的情况是,开发自己把自己搞糊涂了,最后开发看着描述三,才把代码写清楚。

描述三:同一规则的各条数据,每一条数据的起点或终点,都不能介于其余各行的起点和终点之间。

点评描述三
比起描述二,描述三的本质是一样的,但是你会发现,换了一个简单的描述方式,避免了一个先入为主的限制,给开发一些留白,又能不遗漏地去想自己的代码。

2、注意遵从Web页面设计常识
在一个页面当中,我们看到不同的位置摆放不同的元素,就像被割开一块一块的。
这是由于HTML本身就划定了页面元素的坐标,因此在规划页面的时候就要遵从或利用这些规则。
比如:在一个表单当中,当你要在二维栏中加一行描述的时候,如下图这样地设计就有点含糊:
因为,页面的这个位置就像是一个两列的表格,而截图批注的内容却是在一个表格展示的。
所以开发会困惑:你是要让重新插入一个新的区域做成一维单元格,还是在原来的表格中分两列展示呢?

3、结合业务场景灵活设计方案
举个例子:客户等级规则设置功能,参数多,每个参数存在大于、等于、介于三种情况。
常规的设计思路是不同的参数分开存储,也就是一条完整数据要分多条存储。
比如,“id”为“001”的规则选择了三个参数,就要出现三行数据,且每一行数据都要对应考虑四组数据关系(大于、大于等于、小于、小于等于)。如下所示:
这样的设计导致字段较多(列较多),且每个规则又会随着参数的增多而导致行数增多的问题。
由于这些规则要传递给另一个系统去识别和运算,那么就更显得冗余沉重,是否能更简单点呢?
进一步调研获知,这个功能运算出来的数据本身就有结果偏差。因此对精确度的要求不高。
于是,重新和业务用户沟通后,优化了数据存储方案为:每个参数都用一个列,而每列的取值约定双侧为闭区间,用逗号隔开。
如果业务用户想表达大于100,那就写“100.01,”,即“大于100”约等于“大于等于100.01”。同样,小于80.01约等于“小于等于80.00”。因此只需要简单如下所示的存储结构即可(注意逗号是取值区间的分割符号):
结论:

尽量使用从简的设计方案。发现复杂的时候回到问题源头,结合业务场景灵活设计。
如果你开始觉得有点意思了,那关注本书
都是书中提到的
↓↓


4、不要想当然
比如:设计页面搜索项,搜索条件的多少和搜索速度并没有必然的线性关系。

有时候将筛选条件细化,即增加筛选项,反而可能加快速度。
这与筛选字段的索引情况、数据量、数据存储在表的结构(如分表存储)都有关系。
比如:查学生姓名之前先选班级,会比不选班级的查询速度稍微快一点。
因此,在设计方案的时候,并不能一概地通过减少搜索项试图提高搜索速度。

而应当根据具体的情况,结合一定的技术常识进行判断,而不是想当然地设计方案。

5、考虑特殊场景应对机制
特殊场景很多,比如:逆向操作、空值、并发等。
以并发为例,后台的业务人员虽然不多,但是也常常会出现多个用户同时操作同一个数据的情况。
比如:两个客服都看到了同一个待编辑订单,于是两人都要进行编进,碰巧时间相同,那么这就是会出现并发冲突。
这种问题不仅会造成出错的风险,而且对业务人员是一种重复操作,浪费时间。
因此如果遇到这样的场景,产品经理设计方案的时候就跟业务沟通,可能业务的一个简单的分组就化解了这种问题。
又比如做推送机制的时候将数据分别推送给两个客服,或者直接将订单数据分组,不同组的客服分别处理自己组的。
作为产品经理,需要在方案的时候告诉特殊场景或特殊操作,然后具体的处理机制由开发设计。

6、了解业务
每个行业都有外人不熟悉的信息盲区。
比如跨境业务的“时区”转化问题为例
跨境网站如果抓取订单,海外的平台采用的时区和我们的并不一样。并且某些平台在不同国家站点所采用的时区也不一样。
所以在抓单时需要把订单所属的时区转换成北京时间,才能根据北京时间把订单抓回来。

了解后端产品知识之后这些就很容易,推荐一本书籍:



7、A/B方案对比,取最优方案
举一个案例:A系统需要用到手续费,手续费比例是由业务自己配置的。
在做这个需求的时候,了解到另一个系统已经有这套配置功能了,并且已经有了正常的手续费数据。那么A系统是继续在自己系统新建一个配置功能,还是创建接口从对方系统获取现成的呢?
分析:这个问题的关键在于两种方案哪个综合性价比更高。
接口获取案看似简单,但存在系统的耦合性,需要进行跨系统的联测;而新建看似复杂,但是只是一个简常规的规则配置,无需联调测试。因此,最后采用新建配置规则的方案。
这说明:表面上看起来省事的方案,可能真实执行起来反而会麻烦。因此产品经理要充分思考,A/B方案对比后做出选择。

---END---

资料时刻
1、《交互自查表》一份excel共5个sheet

获取方法:

Step1:分享本文/点赞/在看

Step2:对本公众号【产品参赵】发送消息“自查”,等待返回百度云盘的下载链接。



2、如果觉得不过瘾,看看下面这些大厂文档:



获取途径:

加入星球,无限更新


——推荐阅读——

‍‍系统对接,产品经理视角的9千字总结:接口、otter、log4j、SFTP、MQ……

电商商品搜索:需求方案和实现原理(“搜索产品经理”传送门)

B端产品经理 对接第三方API,可能有多坑!

产品参赵
垂直行业SaaS产品十年,书籍《TOB产品之美》《后端产品经理宝典》《产品经理修炼之路》作者
 最新文章