2023年B端产品经理如何做有把握的决策

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.「急」解决紧急一般任务的加速需求

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

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

盼望在上线后观看用户使用效果，看看经过改造后是否还有任务提速的需求。管理员评估会让这个流程更可控，比如当前就有2个高速任务在进行中，高速列表占用，就算审批结束也不能一下子解决问题，这里需要人为决策的维度更多。【任务升级】一般任务手动提速后，会赐予更多并发资源。在这里设计的是，假如提速胜利，可与高优先级任务共享高速通道，通道数照旧最大为2个，如当前已占用则照旧在一般通道等待。（权重与高优先级任务齐平）

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

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

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

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

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

6.小结

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

六、上线效果

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

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

七、总结

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

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

总结一下，当遇到不知如何设计的问题，或者不确定