B端产品经理如何利用笼统类比法做战略设计？

zy77zy

编纂导语：在B端零碎的一些特殊业务场景中，也存在着战略设计，将糊口场景运用于战略设计零碎中，可以播种纷歧样的成果。本文以糊口场景模型为根底，剖析如何利用笼统类比法进行战略设计，但愿对你有所帮忙。

战略设计不单存在于C端产品中，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的总并发数，出借于普通工作。

【量级分类】斟酌到约80%的用户在全量样本测试前都需求用小量样本做验证测试，要包管验证测试的矫捷性，故需求减少量级分类。如，200行之内的样本，为小样本工作。200行以上的为普通工作。【独立逻辑】类比上述安检口「特殊用户」模型，小样本工作走公用通道独自排队，不与普通工作同时排队。且因量级小均匀一个工作仅需1～3min，故不需求判读工作优先级等状况。【额定资源】基于小样本每次量级小，对底层根本无压力的状况，我向架构组胜利了请求在原有并发数N的根底上，额定减少N/10的并发，个别状况下只给小样本工作独自使用。【疾速通道】由于小样本工作高频，约占40%的总工作量，且婚配疾速，故设置小样本工作通道数为至多为5，在假定小样本工作数为m的状况下，每个小样本婚配时的并发量至少可为N/10m，这样根本上用户一提交小样本测试就可以间接进入婚配队列中，升高对小样本验证的等候焦虑。

【提速审批】与在机场安检口，普通旅客赶飞机需求通过安检人员的赞成能力走疾速通道的状况类似。普通工作个别只能走普统统道，但紧迫状况下，假如想减速必需通过领导审批，证实你是真实的紧迫。有了审批这一步会增加非真正紧迫的提速需要，避免公共资源被分歧理占用。
【人工管制】管制工作是不是提速的按钮权限在办理员这里，没有间接做成对接线上审批流的缘故有两点。
但愿在上线后视察用户使用成果，看看通过革新后是不是还有工作提速的需要。办理员评价会让这个流程更可控，好比以后就有2个高速工作在进行中，高速列表占用，就算审批完结也不克不及一下子解决问题，这里需求报酬决策的维度更多。【工作降级】普通工作手动提速后，会给予更多并发资源。在这里设计的是，假如提速胜利，可与高优先级工作同享高速通道，通道数仍旧最大为2个，如以后已占用则仍旧在普统统道等候。（权重与高优先级工作齐平）
4. 解决部份接口的降速需要
这是一个根底架构组基于办事平安斟酌给咱们提的需要，一小部份产品的接口底层机能无限，不反对过大并发调用，因此在本次需要中，统筹了部份接口降速的需要。即当工作中泛起某些接口时，间接进入小并发池中婚配。

【并发调配】零碎在高速通道、普统统道、小样本通道的根底上，统筹了慢速通道。慢速通道的总并发数为总并发数的1/6（按照需求限流的接口能接受的最大并发数赋值的），即为N/6个并发数。从普通工作的并发数中划分出来，如普通工作的并发数为N，则有低速工作时普通工作并发数为，5/6N。【通道同享】慢速工作能够了解为自愿限流的普通工作，故与普通工作同享8个通道数，当8个通道在占历时，第九个工作无论是普通工作仍是低速工作均进入等候队列后面说了，经过历史数据的统计剖析，得出高速工作的需要占比为1/8，大少数状况下，不会泛起高速工作数大于普通工作数的状况。
多数状况如：以后普通工作为0、高速工作为1时，照此前逻辑将启用高速通道，此高速工作的并发数为N/2，但此时的最优解应是高速工作独享全部并发资源N。故需斟酌到这类状况，并减少前置规定。
为了明晰的找到前置规定，我在下方用了枚举法，假定普通工作数（x）、高速工作数（y）、低速工作数（z），便可得出当{ 0 = x y =2 } 时，零碎不启用高速通道，是资源最大化利用的最优解。

六、上线成果
这个战略降级的版本上线后，用户反馈很好。我在页面减少了兽性化的婚配阐明，便于用户了解革新后的资源调度准则。上线后这么久，没有一个用户对革新提出质疑或者支持，我以为是模型在底层提供了公道性保障，给用户有形中进步了相熟感，用户的接收和认可度较高。
同时再次面对问题时，零碎都有相应的战略去应答：高优先级的工作能享用高速、小样本测试能疾速失掉验证、紧迫工作泛起时也能有提速的口子，完全解决了流量调度中常见的三种问题。均匀工作耗时从十一8min降到了41min，婚配时间增加了近2/3，婚配效力是以前的3倍。顶峰期工作拥堵的状况在上线后也失掉了无效的减缓，用户满意度天然也就晋升了。
七、总结
B端平台类产品，用户多为公司外部员工，在产品设计中假如能使用战略伎俩，晋升资源综合利用率，进而增加使用耗时，晋升用户效力，是产品赋能业务和进步用户满意度的一种无效形式。
由于业务场景的繁杂多样，在B端产品经理在设计计划时，没有像C端产品同样有竞品能够参考。但咱们能够对问题进行深挖，多想一想这个业务流程的实质究竟是甚么要解决甚么事（好比下面剖析的流量调度问题）。
总结一下，当遇到不知如何设计的问题或者不肯定计划是不是正确时，能够这样做：
搞清问题实质，联想理想场景中实质相反的糊口模型，切中时弊找到中心矛盾点所在。借助理想场景中同质问题的解决方法，融入以后产品计划中，拓宽产品设计思绪。参考理想场景的实际成果，预计以后计划成果是不是合乎理想模型，确认产品设计的公道性。糊口场景模型，是在理想糊口中被人有数次验证过的能解决问题的无效伎俩。而产品设计的实质，也是解决问题。写这篇文章是想分享本人在任务中解决问题的思绪，但愿大家在任务时，无妨多尝试笼统类比法，多想一想事物的实质。这样，能使繁杂问题简略化，让咱们瞬间恍然大悟！
作者：Fancy刘，现某金融科技公司B端产品经理。
本文由@Fancy刘原创公布于人人都是产品经理，未经许可，阻止转载。
题图来自 Unsplash，基于CC0协定。

华人澳洲中文论坛

热图推荐

B端产品经理如何利用笼统类比法做战略设计？

发表回复

zy77zy
关注TA

图文推荐

华人澳洲中文论坛

热图推荐

B端产品经理如何利用笼统类比法做战略设计？

发表回复

zy77zy 关注TA

图文推荐

zy77zy
关注TA