产品场景:自动化与手动
场景,并不是互联网独有的事物,在我们生活当中随处可见“场景”,只是我们是否能够意识到,能够认识到这些场景的存在。
当我们在说“场景”时,到底是在说什么?
于我而言,场景是发生某个事件的相关环境,我们思考场景,从场景当中判断某事件是否合适,也从场景当中判断会发生什么样的事件。
而场景,并不是互联网独有的事物,在我们生活当中随处可见“场景”,只是我们是否能够意识到,能够认识到这些场景的存在。
最近几天,陪着家人在医院做一些身体检查,过程当中,发现了一些有意思的场景,在这里与大家做一下简单的分享。
奇怪的电梯
这是一家很不错的医院,每天来往的病患特别多,每一位护士都非常忙碌,我们所在的位置是住院部18楼,一共有24楼,这栋楼有12座电梯,一到饭点,上下电梯往往要排很长的队。
奇怪的地方便在于这12座电梯的控制系统是独立的,也就是一组按键仅能操作一座电梯,这导致每次上下电梯,我们都需要将所有电梯都按上一次,这让我很不适应。
我们在商场,在办公楼,以及电梯公寓里遇见的电梯大多数的控制系统是联动的,也就是一组按键,可以操作多个电梯的系统。
这个现象引起了我的好奇,也就有了接下来的探讨:医院为什么采用独立的电梯控制系统,而不是使用联动的电梯控制系统。
在我们接触到类似A和B之间进行选择判断的命题时,第一步要做的事,便是单独分析A和B。
或者说认识一下A和B各自的优缺点,再通过这些优缺点特征,还原该选项适应的场景。
两种系统
联动系统用互联网的话来讲,就是自动化系统。
当用户触发“我要向上”或者“我要向下”的请求时,由中央控制系统进行调控,将指令传达给距离用户最近,能够最快速响应用户请求的设备。
而独立控制系统,就是我们的人工控制系统。由用户扮演人工角色,主观判断哪座电梯距离我最近,我需要操作哪座电梯,用户可以凭借自己的想法,准确操作某一座或多座电梯。
联动系统相对于独立控制系统而言,是将人工判断和人工选择转变为程序判断、程序选择,从而实现“自动化”的能力。减少用户的操作成本,同时让设备的运行效率更高。
人工系统里,按照人们的心理特点,单独操作一座电梯通常没有办法满足人们的安全感,这种不安来自于两种不确定性。
- 其一:目标设备可能处于满载状态,即使最快抵达,我也未必能上去。这是基于根本诉求的不确定性,人们的根本诉求并不是要求电梯抵达,而是对电梯的使用诉求,我们想要乘座电梯,而不是呼叫电梯。
- 其二:尽管这是距离我们最近的电梯,但我们无法确认过程当中是否有其他楼层也会呼叫电梯,以及该电梯在每个楼层之间的等待时间。这是基于等待时间的不确定性,相信我们都经历过电梯长时间停在某个楼层。
基于以上或者更多的不确定性,会导致人们大概率会同时呼叫多座电梯,也是投资心理的风险均摊意识。
人工系统给到了用户极大的控制空间:允许用户对多个设备发起操作指令,实际使用过程中,同时呼叫多座电梯的事情也非常普遍,尤其是高峰时间。
我们的焦虑感、紧迫感都会让我们在不经意间,做出这样的行为。这就会导致资源耗损的情况发生,且是一定会发生。
当我们对多台设备发出呼叫指令时,都会被这些设备所响应。而我们真正使用的设备却只有一台,其他的设备将不会被使用。这样的资源耗损,即是低效的,也是有负面影响的。
呼叫设备,但不使用设备,首先是浪费电费且会影响其他乘客的时间,如果电梯每一层都停靠,不考虑体能的情况,电梯的速度并不会比走楼梯快多少。
直到现在为止,自动化系统依然是时代所趋。我们平时所谈及的智能化本质是对自动化的更进一步的要求。
正因为如此,当我看见了一个依赖人工操作的具有独立控制系统的电梯群时,才会觉的非常诧异。
这所医院在这个城市口碑非常好, 医生,护士还有设备资源也是非常成熟和正规的,一共有4座住院楼,最高的一座有24层。
正是这也一个大医院,正规医院,有财力、有人力、有物力,但却使用了一个相对老,相对不那么友好的电梯操作方案,为每个电梯构造独立控制系统。
表面上,其实很难理解,我只能认为,这里有一些特殊的原因。
如果我们想在生活当中,提炼自己的产品能力,那么大家有必要记住这句话,所谓的“事出反常必有妖”,毕竟产品从来不局限于互联网。
场景分析
为什么电梯的手动操作系统现在依然受到医院青睐呢?这是我思考的重点问题,而要回答这个问题,就需要我们深度的分析医院使用电梯的场景。
我们已经知晓这所医院的人流量极大,住院楼有24层,搭配12座电梯,护士,医生,护工忙的不可开交,这表示医院的病患极多。
对于电梯而言,也就是人流量极大,在我的刻意观察下,每天的饭点(午餐,晚餐)电梯几乎属于饱和运营状态。低楼层的病患因为满载的原因几乎无法乘坐电梯,即使非饭点高峰期,电梯也常常处于满载状态。
我们是在医院的18楼,每次呼叫电梯,基本都是距离满载不远的状态。
人流量极大意味着电梯的呼叫与响应始终处于高频状态,高频状态存在一个我们平时极少关注的特性:高风险。
对于产品而言,用户规模与服务器响应频率成正比关系,用户规模越大,服务器响应频率越高频,BUG也就越多。
100人使用产品,BUG率1% ,也就只有1个BUG,如果是100万人使用产品,即使是BUG率依然是1%,但BUG数也会增长到10000个。
何况,高频使用相对于低频使用而言,具有更高的BUG触发率,请求之间的冲突,以及用户个性化的使用,都会增加BUG的触发率。
在医院场景里,自动化系统将会被更高频的使用,所有的请求,呼叫,指令都将汇集在一起进行处理,这就会导致风险增高,BUG触发率增高。
分离的电梯操作系统,将用户的请求拆分成了12份,每个电梯独立处理自己的业务,降低了操作系统的使用频率。
如果高频使用等于高风险,为什么办公大厦更多的使用自动化系统呢?对于高峰期而言,办公大厦的电梯使用率相对于医院而言只会更多。
实际上24层以上的办公大厦也是做了分流处理,尽管没有将每一座电梯分别控制。但通常会分成高层电梯与低层电梯两组控制系统(或者更多),彼此之间互不干扰。
医院与办公大厦都属于人流量极大,呼叫、请求、操作极高频的使用场景,两者之间必然还存在某种根本性的因素,导致前者使用了分离式的电梯操作系统(人工操作),后者使用了联动式的电梯操作系统(自动化)。
实际上我们在判断风险时,是一套复合条件的综合判断。
除了事故触发率,还有其他维度的衡量指标,有的事故触发率尽管极高,但却不需要过多处理,而有的事故触发率尽管极低,但却需要更坚定的处理。
在事故触发率(BUG触发率)的背后,还有严重度作为判断依据,也就是当事故发生以后,该事故的严重程度,我们能否接受该事故的发生,是勉强接受,还是坚定的拒绝。
此时,我们要假设事故已经发生了。
我曾在上班期间遇见电梯故障的事故,我所付出的代价是徒步20楼,走楼梯来到了公司,毫无疑问,我迟到了,但受到影响的并不是我个人,许多同事都只能通过楼梯上下班。
对于被困在电梯里的上班族而言,势必会影响自己的工作进度,有的也许会影响到任务的交付,合约的签订。
简单来讲,我们的时间,收益都将会因为电梯故障而受到影响,当然我们的心情也会变得糟糕,生命的不安全感也会被完全触发。无可赖何之下,我们只能选择玩玩手机,等待救援。
对于医院而言,电梯发生故障以后,将会影响患者的救治。
在医院里,电梯的乘客多数是病患与病患的家属。这两类人大概率以病患为核心,为病患奔波。
除开相对闲散的家属使用,许多时候牵扯到寻找医生,拿药,办理各种手续,有时,也会牵连到更换床位(住院楼)。
通常电梯事故并不会危机人们的生命安全。但在医院里,电梯异常一方面会影响患者情绪,瞬间的动荡,两者都会加重患者的病情(伤情),更重要的是,时间上的停滞,将会延误患者的救治时间。
我们实在难以想象,一个急症病人,被困在电梯里延误了最佳抢救时机,还有刚做完手术的病人,被电梯骤停产生的冲击导致缝合的伤口崩裂的情景。
医院电梯一旦出现故障,将会危及人们的生命安全,这远比我们迟到,扣工资,甚至远比我们的一个合约签订更加严重。
或许还存在更多的场景特点、内部因素,但仅仅是高风险触发数、高风险触发率以及事故严重度,已经是极大的倾向于分离式操作系统的使用了。
如果联动式电梯操作系统(自动化)能够提供针对高风险触发数、高风险触发率以及事故严重度这三个问题做出了的确切保障,消除人们的顾虑。
我想依然有许多医院使用了联动式操作系统,毕竟相对于概率问题而言,联动式操作系统确实更加高效,用户体验也更好。
在这之前,大部分医院,并不会用患者的生命安全承担风险。实际上,我们在做互联网产品时,也常常使用人工操作系统来代替不成熟的自动化系统。
人工操作是一种保守方案,尽管效率低,但足够安全。
引申的互联网案例
自动化处理还是人工处理,并不是一个绝对性的竞争性问题,并不是谁比谁好,谁淘汰谁的问题。
两者都有其适用的场景,都有其独特的特性。
自动化处理,将繁琐的计算处理都交给了系统完成,效率和使用体验远超人工处理。实际上,社会的进步正是一个又一个的自动化的演变过程。但其较高的研发成本,维护成本是我们必须面对和承担的。
同时自动化处理较高的出错率尽管比人工处理更低,但并不是没有,甚至会产生许多人工处理所不会产生的问题,而我们的人工智能也远不足以灵活的处理发生的事故。
人工处理,在现在的互联网依然存在很大的使用面积,尤其是在高效带来的价值并不足以支付实现高效所需要支付的成本时,我们更倾向于使用人工处理的方式来完成业务。
对于一些“一定不能犯错”的环节,也充斥着人工处理的使用。
人工智能是自动化的进阶形式,本质依然是自动化处理的底层思想,而许多事情是当下电脑所无法处理的。比如:人们的生命,财产的支配,以及一些情感判断,这些都不是系统能代替我们完成的事情。
在互联网里,也充满了许多这样的案例,这里简单和大家分享几个我们常见的场景:
1. 支付
支付宝推出了小额免密支付,在我们购买金额较小的商品时,不需要输入密码,这其实就是按照金额大小将我们的支付行为拆分出了自动化场景与手动化场景。
在于设置的金额范围内,系统认为该风险是系统可承担的,便采用了“自动验证”的方式实现“免密支付”。
而对于较大的金额,则需要由用户“手动验证”的方式实现“验证支付”,也就是我们要输入密码或者相关的验证码才能完成该笔业务。
2. 内容审核机制
对于内容型产品而言,早期通常采用人工验证的方式。因为内容较少,导致验证的价值并不足以平衡自动化内容审核机制的研发,而在内容数量急剧增加后,内容验证的价值得到了提升,也就有了自动化审核机制的系统。
今日头条,微信公众号等大的内容聚合平台必定存在特定的自动化审核机制,我们经常会看到的一些现象,比如公众号被封,文章被删除,大概率是触发了自动化审核机制。
3. 电商的发货系统
除了个别的大电商实现了自动化填单,发货的能力以外,许多中小电商依然是人工审单的方式完成订单业务的闭环。
许多年销量过亿的淘宝,京东的大卖家,在对接ERP系统时,也是人工与自动化结合的使用。
对于正常销售的商品,不容易出错的商品,会使用自动化填单系统。但对于一些活动商品,特殊的商品,就会是人工客服对每一笔订单进行审核,手动触发审核通过以后,系统才会进入“已发货”的状态。
更多的年销量没有过亿的卖家,基本都采用的是“人工审单”的方式开展业务,一方面是自动化的成本比人工成本更高,另一方面是自动化系统不够成熟,依然存在许多问题和风险,这些是中小卖家所不能承受的风险。
这也是为什么淘宝的大商户,往往会组建几十人规模的客服坐席的原因,(审核订单是他们的主要工作之一)。
好了,这次的逻辑练习就到这里了,最后,我想再和你聊聊。
互联网的产品从来不是孤岛,现实生活中处处存在产品逻辑的身影,只是需要我们去发现,去思考。
#专栏作家
枯叶,微信公众号:产品经理充电站。人人都是产品经理专栏作家。近9年经验的产品经理,擅长社交、社区、细分群体挖掘。
本文由 @枯叶 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
作者暂无likerid, 赞赏暂由本网站代持,当作者有likerid后会全部转账给作者(我们会尽力而为)。Tips: Until now, everytime you want to store your article, we will help you store it in Filecoin network. In the future, you can store it in Filecoin network using your own filecoin.
Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: