B端PRD的逻辑

方案产品经理不再只说我要xx(我不在乎潜台词是如何实现的)xx,逻辑是……(我已经想透了潜台词)。

方案设计更多地体现在逻辑规则与整体结构的契合度上。糟糕的方案往往会使开发过程反复拉锯,事半功倍。

需求与方案的融合对团队和谐、产品拓展大有裨益!是产品经理价值的体现之一。

来聊聊<宝典,后端产品经理>核心之一:中后端需求方案(PRD)注意事项。

一、想好计划,适当叙述

怎么在PRD表达区间不能交叉?

1. 案例

在一个Excel在导入功能的要求中,导入的内容是不同重量范围对应的成本计算规则。因此,在需求文档中,不允许重量范围交叉。

2. 如何描述

描述一:同一规则的任何两个数据的重量范围不能交叉。

点评描述一

看起来比较需求化,但实际上有一个问题,就是没有定义什么样才算是交叉。

因此,需求描述不清楚。

如果产品经理认为交叉是一个白痴问题,没有必要定义它(实际上是这样),但如果开发的代码写错了,标杆就会不一致。

换句话说,产品理解这句话,开发也理解这句话的意思,测试也理解,但并不能保证每个人的理解都是一致的。

描述二:假设重量范围是同一规则的任意两个数据a-b、c-d,那么若出现a<e<b、a<f<b、e<b<f、e<a<f任何一种情况都被视为两个重量范围的交叉。

点评描述二

它比描述1更具体、抽象和定义。但事实上,我们遇到的情况是,开发自己混淆了自己。最后,开发看描述3,然后写清楚代码。

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

点评描述三

与描述2相比,描述3的本质是相同的,但你会发现,改变了一种简单的描述方法,避免了先入为主的限制,为开发留下一些空白,并且可以不遗漏地思考自己的代码。

二、注意服从Web页面设计常识

在一个页面上,我们看到不同的元素被放置在不同的位置,就像被切割一样。

这是由于HTML页面元素的坐标本身就是定义的,所以在规划页面时要遵循或使用这些规则。

比如:在表单中,当你想在二维栏中添加一行描述时,如下图所示的设计有点模糊:

B端PRD的逻辑性:这6个案例你怎么看?(附电子书)

因为页面的这个位置就像两列表,截图注释的内容显示在一个表中。

因此,开发会感到困惑:您是想将新区域重新插入制作成一维单元格,还是在原表中分两列显示?

三、结合业务场景灵活设计方案

举个例子:客户级规则设置功能,参数多,每个参数大于、等于、介于三种情况。

常规的设计思路是不同的参数分开存储,也就是一条完整数据要分多条存储。

比如,“id如果为001规则选择三个参数,将出现三行数据,每行数据应考虑四组数据关系(大于、大于等于、小于、小于等于)。如下所示:

B端PRD的逻辑性:这6个案例你怎么看?(附电子书)

这种设计导致字段多(列多),每个规则都会随着参数的增加而增加行数。

因为这些规则应该传递给另一个系统来识别和操作,所以它们看起来更冗余和沉重。能更简单吗?

根据进一步的研究,该功能计算的数据本身存在结果偏差。因此,精度要求不高。

因此,在与业务用户重新沟通后,优化的数据存储方案是:每个参数使用一个列,每个列的值约定两侧为闭合范围,并用逗号分开。

如果业务用户想表达超过100,写100.01,也就是说,大于100大约等于大于等于100.01同样,小于80.01大约等于小于等于80.00因此,只需简单地说明以下存储结构(注意逗号是取值区间的分割符号):

B端PRD的逻辑性:这6个案例你怎么看?(附电子书)

结论:尽量使用简单的设计方案。回到问题的源头,结合业务场景灵活设计。

四、不要想当然

具体体现如下:

1. 设计页面搜索项

设计页面搜索项,搜索条件的数量与搜索速度没有必然的线性关系。

有时候将筛选条件细化,即增加筛选项,反而可能加快速度。

这与表中筛选字段的索引、数据量和数据存储的结构有关。

2. 结合技术常识

查学生姓名前先选班,查询速度会比不选班快一点。

因此,在设计方案时,我们不能试图通过减少搜索项来提高搜索速度。我们应该根据具体情况和一定的技术知识来判断,而不是理所当然地设计方案。

五、考虑特殊场景应对机制

特殊场景很多,比如:逆向操作、空值、并发等。

以并发为例,后台的业务人员虽然不多,但是也常常会出现多个用户同时操作同一个数据的情况。
比如:两个客服都看到了同一个待编辑的订单,所以两个人都要编去。碰巧时间是一样的,所以会有并发冲突。

这个问题不仅会造成错误的风险,还会浪费业务人员的时间。

因此,如果产品经理在设计方案时与业务沟通,业务的简单分组可能会解决这个问题。

另一个例子是,在制定推送机制时,将数据给两个客户服务,或直接将订单数据分组,不同组的客户服务分别处理自己的组。

作为产品经理,在计划中需要告知特殊场景或特殊操作,然后开发设计具体的处理机制。

六、了解业务

每个行业都有外人不熟悉的信息盲区。

例如,跨境业务的时区转型为例

如果跨境网站抓取订单,海外平台采用的时区与我们不同。而且有些平台在不同国家的网站上使用不同的时区。

因此,在抓取订单时,需要将订单所属的时区转换为北京时间,以便根据北京时间抓取订单。在了解了后端产品的知识后,很容易推荐一本书:

七、A/B比较方案,取最佳方案

举一个案例:A系统需要手续费,手续费比例由业务自行配置。

在做这个需求时,我了解到另一个系统有这个配置功能,并且有正常的费用数据。A系统是继续在自己的系统中创建新的配置功能,还是从对方的系统中创建接口?

分析:这个问题的关键在于两种方案中哪一种综合性价比更高。

接口访问案例似乎很简单,但有系统耦合,需要跨系统联合测试;新的看似复杂,但只是一个简单的常规规则配置,不需要联合调整测试。因此,最终采用了新的配置规则。

这说明:表面上看似省事的方案,实际执行起来可能会很麻烦。所以产品经理要充分思考,A/B比较方案后做出选择。

相关新闻

联系我们

联系我们

888-888-8888

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

邮件:admin@example.com

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

关注微信
关注微信
分享本页
返回顶部