导语：B端业务场景专一化、业务背景复杂，业务方提的需求一般都较为明确，如“我想要一个….功能” 但产品经理在判断和设计需求时时往往摸着石头过河，没有可以衡量判断的标准，如果能借助生活场景经验应用在决策中，会让思路豁然开朗，也对自身判断有了可预知的底气。
产品经理最重要的工作是什么？——做决策。
对于1～3年的B端产品经理，面对业务需求，经常需要判断：
这个业务提的需求该不该做？做或者不做带来的收益和风险是什么？有比原需求更好的解决方式吗？未来的扩展性有哪些？
B端不像C端，可以依据数据反馈做决策。
B端产品经理在工作中最常做的是主观判断决策，这个感觉就跟摸着石头过河很像，如果产品sense不够好，很容易被需求方提的需求带到一条思维的小路上，虽然修好了小路，但是只能给部分人走，失去了扩展性。
表现形式就是后面系统架构愈加杂乱，功能点散没有结构性，功能效果藏在代码逻辑里，对后人和用户都是黑盒子。
如何才能快速发现问题的本质，判断需求的合理性、设计方案的可行性呢？运用抽象思维很重要。
下面我介绍一种我自己常用的方法——抽象类比法
抽象类比法，是把事物的表象抽离提炼为一种通用的模式，这种模式可以直接套用在其他不同的场景中直接应用或扩展。
而生活化场景的抽象好处在于生活场景联想门槛低，易接触到。同时生活场景的流程模式在得到过广泛的应用和验证，是值得信赖的经典模型。
下面给大家介绍下，我借助生活场景模型解决的一个B端产品的任务调度难题。
在首篇文章中提到过，我重构了一个风控数据测试系统，系统的核心功能是数据的批量匹配。
数据匹配的逻辑是：
把批量样本文件以一次任务的形式，向不同产品的API接口发起批量的调用请求，收到响应后将接口返回的数据回写入一个文件中。
如下图：
这个功能的视觉效果跟多任务下载文件有些相似，不同的是，由于底层API接口有并发数的限制，也就是资源是有限的，因此任务的匹配速度就受到了限制。
此前，系统可以支持最多10个用户的任务同时进行，各个任务的并发资源数是按当前任务数等分的，如下图：
即：单任务并发数=总并发数/当前任务数，即任务越多，每个任务的进度就越慢。
除了受到并发数影响，不同任务的匹配时长还受到下面几个因素的影响：
当然，并发资源是权重最高的因子，如果并发数提升了，整体任务效率都是同比增长的。
其他背景：
因为原流程资源是均分制的，也就是对所有任务一视同仁，不区分任务的紧急程度、样本大小等因素，按时间次序将任务依次放进匹配通道中，如果此时10个匹配通道均已占用，那后面的任务就都需要等待。
任务高峰期，系统上最多有50个任务在等待中，最长一个任务从发起到匹配结束花了将近3天的时间。
大任务测不完，小任务测不上；10个通道持续满载，任务堆积严重。是这个核心功能最大的问题。
系统用户（分析师）找我反馈的次数也不少，都是希望我能给他们插队的：
大概这样的严重拥挤情况持续了1周左右，我意识到务必要做出改变，在并发数有上限的情况下，如何实现资源的最大化利用，这应该是需要精细化策略设计的问题。
既然决定要改原有的逻辑，如何设计才合理？难道要像用户所提的，增加一个插队功能？管理员可以改变任务顺序，可以随意把后面的任务放置前面？
当然不行！
这是一个与调度秩序有关的问题，假如说开了这个口子，且不说系统技术逻辑复杂度加重，而是从常理的公平性角度想：
这些都是不公平的，不论怎么做，都是影响了其他用户的利益。
如果每个人因为想因为要加速都来找管理员开这个口子，那系统的匹配功能将失去秩序，操作频繁时，系统来不及更新状态，可能会影响调用结果的准确性，风险性极大。
那既然这样，如何思考才能有效解决这个问题？
我们需要拨开表象看本质，抓住问题的主要矛盾，防止被用户的诉求带偏。
如何抓住核心矛盾？我们可以借助抽象类比的方法。
这个问题的本质是流量调度，那么联想生活场景，哪些场景跟流量有关？
是不是能想到“人潮涌动、排队检票”的场景？进而联想到机场、火车站或景区门口的景象。
我们拿机场举例，将实际事物与系统场景进行类比：
综上所述，能确定基于流量场景的调度设计可参考抽象后的“安检口”模型。
那机场安检口是怎么解决流量调度问题的？
上面四种解决问题的逻辑恰好跟我上面收集的用户反馈情况对应上了
这刚好是所有流量场景中最常遇到的三种问题，它们的应对办法分别是：
有了上面的生活场景参考，我们具体到系统的功能逻辑里，在“安检口”模型的基础上，考虑到了并发资源最大化利用的问题（不能让资源空着不用）我是这样设计的：
首先，我们假设系统匹配任务的总并发数为N：
【提速审批】与在机场安检口，普通旅客赶飞机需要经过安检人员的同意才能走快速通道的情况相似。普通任务一般只能走普通通道，但紧急情况下，如果想加速必须经过领导审批，证明你是真正的紧急。有了审批这一步会减少非真正紧急的提速需求，防止公共资源被不合理占用。
【人工控制】控制任务是否提速的按钮权限在管理员这里，没有直接做成对接线上审批流的原因有两点。
【任务升级】普通任务手动提速后，会给予更多并发资源。在这里设计的是，如果提速成功，可与高优先级任务共享高速通道，通道数依旧最大为2个，如当前已占用则依旧在普通通道等待。（权重与高优先级任务齐平）
这是一个基础架构组基于服务安全考虑给我们提的需求，一小部分产品的接口底层性能有限，不支持过大并发调用，因此在本次需求中，兼顾了部分接口降速的需求。即当任务中出现某些接口时，直接进入小并发池中匹配。
前面说了，通过历史数据的统计分析，得出高速任务的需求占比为1/8，大多数情况下，不会出现高速任务数大于普通任务数的情况。
以上设计思路，参考了机场安检口的旅客优先级规则，同时结合实际业务需求场景，在保证并发资源高效利用的原则下，运用抽象类比法将原有的“数据测试等待时间长的问题”抽象为“流量池问题”，引入的5种调度策略，一口气解决了原流程“轻/重/缓/急”的四种任务调度难题。
这个策略升级的版本上线后，用户反馈很好。我在页面增加了人性化的匹配说明，便于用户理解改造后的资源调度原则。上线后这么久，没有一个用户对改造提出质疑或者反对，我认为是模型在底层提供了合理性保障，给用户无形中提高了熟悉感，用户的接纳和认可度较高。
同时再次面对问题时，系统都有相应的策略去应对：高优先级的任务能享受高速、小样本测试能快速得到验证、紧急任务出现时也能有提速的口子，彻底解决了流量调度中常见的三种问题。平均任务耗时从118min降到了41min，匹配时间减少了近70%，高峰期任务拥挤的情况在上线后也得到了有效的缓解，用户满意度自然也就提升了。
B端平台类产品，在产品设计中如果能使用策略手段，提升资源综合利用率，进而减少使用耗时，提升用户效率，是产品赋能业务和提高用户满意度的一种有效方式。
因为业务场景的复杂多样，在B端产品经理在设计方案时，没有像C端产品一样有竞品可以参考。但我们可以对问题进行深挖，多想想这个业务流程的本质到底是什么要解决什么事（比如上面分析的流量调度问题）。
总结一下，当遇到不知如何设计的问题，或者不确定产品方案是否正确时，可以这样做：
生活场景模型，是在现实生活中被人无数次验证过的能解决问题的有效手段。
而产品设计的本质，也是解决问题。
写这篇文章是想分享自己在工作中解决问题的思路，希望大家在工作时，不妨多尝试抽象类比法，多想想事物的本质。这样，能使复杂问题简单化，让我们瞬间豁然开朗！
作者：Fancy刘，现某金融科技公司B端产品经理。
本文由@Fancy刘 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。