导语：B端业务场景专一化、业务背景复杂，业务方提的需求一般都较为明确，如“我想要一个….功能” 但产品经理在判断和设计需求时时往往摸着石头过河，没有可以衡量判断的标准，如果能借助生活场景经验应用在决策中，会让思路豁然开朗，也对自身判断有了可预知的底气。

产品经理最重要的工作是什么？——做决策。

对于1～3年的B端产品经理，面对业务需求，经常需要判断：

这个业务提的需求该不该做？做或者不做带来的收益和风险是什么？有比原需求更好的解决方式吗？未来的扩展性有哪些？

B端不像C端，可以依据数据反馈做决策。

B端产品经理在工作中最常做的是主观判断决策，这个感觉就跟摸着石头过河很像，如果产品sense不够好，很容易被需求方提的需求带到一条思维的小路上，虽然修好了小路，但是只能给部分人走，失去了扩展性。

表现形式就是后面系统架构愈加杂乱，功能点散没有结构性，功能效果藏在代码逻辑里，对后人和用户都是黑盒子。

如何才能快速发现问题的本质，判断需求的合理性、设计方案的可行性呢？运用抽象思维很重要。

下面我介绍一种我自己常用的方法——抽象类比法

抽象类比法，是把事物的表象抽离提炼为一种通用的模式，这种模式可以直接套用在其他不同的场景中直接应用或扩展。

而生活化场景的抽象好处在于生活场景联想门槛低，易接触到。同时生活场景的流程模式在得到过广泛的应用和验证，是值得信赖的经典模型。

下面给大家介绍下，我借助生活场景模型解决的一个B端产品的任务调度难题。

一、问题背景

在首篇文章中提到过，我重构了一个风控数据测试系统，系统的核心功能是数据的批量匹配。

数据匹配的逻辑是：

把批量样本文件以一次任务的形式，向不同产品的API接口发起批量的调用请求，收到响应后将接口返回的数据回写入一个文件中。

如下图：

这个功能的视觉效果跟多任务下载文件有些相似，不同的是，由于底层API接口有并发数的限制，也就是资源是有限的，因此任务的匹配速度就受到了限制。

此前，系统可以支持最多10个用户的任务同时进行，各个任务的并发资源数是按当前任务数等分的，如下图：

即：单任务并发数=总并发数/当前任务数，即任务越多，每个任务的进度就越慢。

除了受到并发数影响，不同任务的匹配时长还受到下面几个因素的影响：

• 样本量级不同（不同任务量级跨度大，50条～500w条）
• 调用产品数量不同（不同任务间数量跨度大，1个～50个）
• 不同产品接口的请求响应时间不同（如：评分类产品的请求耗时通常较长）

当然，并发资源是权重最高的因子，如果并发数提升了，整体任务效率都是同比增长的。

其他背景：

• 出于公平性和API底层的考量，一个用户如有多个任务，在发起后，同一时间只能一个任务在进行中，其他任务均为等待中。
• 匹配列表为唯一数据权限公开的模块，可供所有用户查看当前系统的任务匹配和资源占用情况，以便了解自己的任务是否需要排队等待。

二、改造前的问题

因为原流程资源是均分制的，也就是对所有任务一视同仁，不区分任务的紧急程度、样本大小等因素，按时间次序将任务依次放进匹配通道中，如果此时10个匹配通道均已占用，那后面的任务就都需要等待。

任务高峰期，系统上最多有50个任务在等待中，最长一个任务从发起到匹配结束花了将近3天的时间。

大任务测不完，小任务测不上；10个通道持续满载，任务堆积严重。是这个核心功能最大的问题。

系统用户（分析师）找我反馈的次数也不少，都是希望我能给他们插队的：

• “我这个是付费测试，你们不给优先处理吗？”
• “我就50条样本，能让我先测下不？”
• “我的任务紧急，客户明天就要，能不能插队呀”
• …

大概这样的严重拥挤情况持续了1周左右，我意识到务必要做出改变，在并发数有上限的情况下，如何实现资源的最大化利用，这应该是需要精细化策略设计的问题。

三、问题分析

既然决定要改原有的逻辑，如何设计才合理？难道要像用户所提的，增加一个插队功能？管理员可以改变任务顺序，可以随意把后面的任务放置前面？

当然不行！

这是一个与调度秩序有关的问题，假如说开了这个口子，且不说系统技术逻辑复杂度加重，而是从常理的公平性角度想：

• 把一个等待中的任务放在匹配队列中，必然会影响一个匹配中任务
• 把任务提到等待队列的最前位，也影响了后面其他人的等待中任务

这些都是不公平的，不论怎么做，都是影响了其他用户的利益。

如果每个人因为想因为要加速都来找管理员开这个口子，那系统的匹配功能将失去秩序，操作频繁时，系统来不及更新状态，可能会影响调用结果的准确性，风险性极大。

那既然这样，如何思考才能有效解决这个问题？

我们需要拨开表象看本质，抓住问题的主要矛盾，防止被用户的诉求带偏。

如何抓住核心矛盾？我们可以借助抽象类比的方法。

四、抽象类比

这个问题的本质是流量调度，那么联想生活场景，哪些场景跟流量有关？

是不是能想到“人潮涌动、排队检票”的场景？进而联想到机场、火车站或景区门口的景象。

我们拿机场举例，将实际事物与系统场景进行类比：

• 样本可以比作旅客
• 样本量大小可以比作一个旅行团的大小
• 任务数可以比作安检通道的个数
• 每个任务的并发数，可以比作每个安检通道内可以同时做检查的工作人员数（人数越多安检越快）
• 每次匹配的产品多少可以类比为旅行团的行李（行李越多安检越慢）

综上所述，能确定基于流量场景的调度设计可参考抽象后的“安检口”模型。

那机场安检口是怎么解决流量调度问题的？

• 「针对普通用户」普通旅客走常规安检口，常规安检口数量有一般有多个。
• 「针对高级用户」VIP旅客走VIP安检口，解决VIP旅客对时间要求高的问题
• 「针对特殊用户」长期开放快速通道安检口，为残疾人等需要关注的旅客提供便利
• 「针对紧急用户」当旅客着急赶飞机时，可以在机场工作人员的允许后，走快速通道安检口

上面四种解决问题的逻辑恰好跟我上面收集的用户反馈情况对应上了

• “我这个是付费测试，你们不给优先处理吗？”——高级用户问题
• “我就50条样本，能让我先测下不？”——特殊用户问题
• “我的任务紧急，客户明天就要，能不能插队呀”——紧急用户问题

这刚好是所有流量场景中最常遇到的三种问题，它们的应对办法分别是：

• 按重要性对资源进行有差别划分
• 特殊情况给予特殊资源倾斜照顾
• 紧急非重要情况给予通融的机会

五、方案设计

有了上面的生活场景参考，我们具体到系统的功能逻辑里，在“安检口”模型的基础上，考虑到了并发资源最大化利用的问题（不能让资源空着不用）我是这样设计的：

首先，我们假设系统匹配任务的总并发数为N：

1. 「重」解决付费工单要求提高优先级高的需求

• 【任务分类】根据测试目的把工单分为两种：高优先级工单（付费测试）、低优先级（免费测试）
• 【评估配比】计算历史任务中，高优先级工单与低优先级工单的数量比，为1:7，这个比例跟上面的「高级用户」场景相似，都是重要的事物，量少；普通的事物，量多。
• 【套用模型】故类比安检口「高级用户」模型，遵从二八法则，将原有的10任务通道分类，最多2个高速通道、最多8个普通通道。高优先级任务走高速通道，低优先级任务走普通通道。高速任务如超过2个顺位走普通通道，后续按次序自动补位进入高速通道。
• 【动态分配】当平台仅有普通任务时，假设任务数为x，此时每个任务的并发数为N/x。当此时出现高速通道任务，任务数为y，系统自动划分N/2并发数支持高速通道，因此每个高速任务最少有N/4个并发数，这一步是为了保护高速任务的进行效率。此时低速通道任务并发数自动减半变为N/2x。
• 【资源释放】高速任务一般任务数量少，速度有保障的前提下匹配的时间短，故在高速任务完成后，将自动释放N/2的总并发数，归还于普通任务。

2. 「轻」解决量小高频的小样本快速测试需求

• 【量级分类】考虑到约80%的用户在全量样本测试前都需要用小量样本做验证测试，要保证验证测试的敏捷性，故需要增加量级分类。如，200行以内的样本，为小样本任务。200行以上的为普通任务。
• 【独立逻辑】类比上述安检口「特殊用户」模型，小样本任务走专用通道单独排队，不与普通任务同时排队。且因量级小平均一个任务仅需1～3min，故不需要判读任务优先级等情况。
• 【额外资源】基于小样本每次量级小，对底层基本无压力的情况，我向架构组成功了申请在原有并发数N的基础上，额外增加N/10的并发，一般情况下只给小样本任务单独使用。
• 【快速通道】因为小样本任务高频，约占40%的总任务量，且匹配快速，故设置小样本任务通道数为最多为5，在假设小样本任务数为m的情况下，每个小样本匹配时的并发量最少可为N/10m，这样基本上用户一提交小样本测试就能直接进入匹配队列中，降低对小样本验证的等待焦虑。

3. 「急」解决紧急普通任务的加速需求

【提速审批】与在机场安检口，普通旅客赶飞机需要经过安检人员的同意才能走快速通道的情况相似。普通任务一般只能走普通通道，但紧急情况下，如果想加速必须经过领导审批，证明你是真正的紧急。有了审批这一步会减少非真正紧急的提速需求，防止公共资源被不合理占用。

【人工控制】控制任务是否提速的按钮权限在管理员这里，没有直接做成对接线上审批流的原因有两点。

1. 希望在上线后观察用户使用效果，看看经过改造后是否还有任务提速的需求。
2. 管理员评估会让这个流程更可控，比如当前就有2个高速任务在进行中，高速列表占用，就算审批结束也不能一下子解决问题，这里需要人为决策的维度更多。

【任务升级】普通任务手动提速后，会给予更多并发资源。在这里设计的是，如果提速成功，可与高优先级任务共享高速通道，通道数依旧最大为2个，如当前已占用则依旧在普通通道等待。（权重与高优先级任务齐平）

4. 「缓」解决部分接口的降速需求

这是一个基础架构组基于服务安全考虑给我们提的需求，一小部分产品的接口底层性能有限，不支持过大并发调用，因此在本次需求中，兼顾了部分接口降速的需求。即当任务中出现某些接口时，直接进入小并发池中匹配。

• 【并发分配】系统在高速通道、普通通道、小样本通道的基础上，兼顾了慢速通道。慢速通道的总并发数为总并发数的1/6（根据需要限流的接口能承受的最大并发数赋值的），即为N/6个并发数。从普通任务的并发数中划分出来，如普通任务的并发数为N，则有低速任务时普通任务并发数为，5/6N。
• 【通道共享】慢速任务可以理解为被迫限流的普通任务，故与普通任务共享8个通道数，当8个通道在占用时，第九个任务无论是普通任务还是低速任务均进入等待队列

5. 针对少数情况的前置规则先行

前面说了，通过历史数据的统计分析，得出高速任务的需求占比为1/8，大多数情况下，不会出现高速任务数大于普通任务数的情况。

• 少数情况如：当前普通任务为0、高速任务为1时，照此前逻辑将启用高速通道，此高速任务的并发数为N/2，但此时的最优解应是高速任务独享整个并发资源N。故需考虑到这种情况，并增加前置规则。
• 为了清晰的找到前置规则，我在下方用了枚举法，假设普通任务数（x）、高速任务数（y）、低速任务数（z），即可得出当{ 0 <= x< y<=2 } 时，系统不启用高速通道，是资源最大化利用的最优解。

6. 小结

以上设计思路，参考了机场安检口的旅客优先级规则，同时结合实际业务需求场景，在保证并发资源高效利用的原则下，运用抽象类比法将原有的“数据测试等待时间长的问题”抽象为“流量池问题”，引入的5种调度策略，一口气解决了原流程“轻/重/缓/急”的四种任务调度难题。

六、上线效果

这个策略升级的版本上线后，用户反馈很好。我在页面增加了人性化的匹配说明，便于用户理解改造后的资源调度原则。上线后这么久，没有一个用户对改造提出质疑或者反对，我认为是模型在底层提供了合理性保障，给用户无形中提高了熟悉感，用户的接纳和认可度较高。

同时再次面对问题时，系统都有相应的策略去应对：高优先级的任务能享受高速、小样本测试能快速得到验证、紧急任务出现时也能有提速的口子，彻底解决了流量调度中常见的三种问题。平均任务耗时从118min降到了41min，匹配时间减少了近70%，高峰期任务拥挤的情况在上线后也得到了有效的缓解，用户满意度自然也就提升了。

七、总结

B端平台类产品，在产品设计中如果能使用策略手段，提升资源综合利用率，进而减少使用耗时，提升用户效率，是产品赋能业务和提高用户满意度的一种有效方式。

因为业务场景的复杂多样，在B端产品经理在设计方案时，没有像C端产品一样有竞品可以参考。但我们可以对问题进行深挖，多想想这个业务流程的本质到底是什么要解决什么事（比如上面分析的流量调度问题）。

总结一下，当遇到不知如何设计的问题，或者不确定产品方案是否正确时，可以这样做：

1. 搞清问题本质，联想现实场景中本质相同的生活模型，一针见血找到核心矛盾点所在。
2. 借助现实场景中同质问题的解决办法，融入当前产品方案中，拓宽产品设计思路。
3. 参考现实场景的实际效果，预计当前方案效果是否符合现实模型，确认产品设计的合理性。

生活场景模型，是在现实生活中被人无数次验证过的能解决问题的有效手段。

而产品设计的本质，也是解决问题。

写这篇文章是想分享自己在工作中解决问题的思路，希望大家在工作时，不妨多尝试抽象类比法，多想想事物的本质。这样，能使复杂问题简单化，让我们瞬间豁然开朗！

作者：Fancy刘，现某金融科技公司B端产品经理。

本文由@Fancy刘 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。