B端产品面试技巧：业务调度设计的逻辑测验及分析

编辑导读：为了提高我们的思维能力，需要有意识地观察生活，并做一些产品思考。本文作者将以一道产品的笔试题为例，谈谈业务调度设计的逻辑测验及分析，希望对你有帮助。

个人一直觉得产品面试是一件非常有挑战的事情，今天选择从一个角度分享B端产品的面试技巧。

这是一道笔试的面试题，这道源自于老狗某日在等电梯时的突发奇想。

一栋楼内有N部互相关联的电梯，当任一楼层内的用户，按下呼叫键（上／下）后，系统对接载乘客需求的响应逻辑该如何设计，目标是让电梯实现高效且合乎我们日常使用体验。

这个问题，通常情况下，请作为笔试题，并给候选人至少30分钟以上思考时间。

老狗当初冒出这个想法的时候，自己考自己，花了几天时间才把逻辑给抽象出来，从我实际面试经验来看，如果这个问题在当面沟通时抛给候选人的话，实时能够描绘出逻辑的人，基本为零。

但这绝对是一个值得去琢磨的问题，对于提升自己的逻辑性有非常大的帮助。

这个问题的本质是什么？

这个问题本质上，我把它定义为“业务调度设计能力”。

在B端产品经理的专业能力树中，业务调度的逻辑抽象能力，我认为是极其重要的一项基本能力，带大家一起分析下这个问题。

最熟悉的场景，却不曾思考过的复杂逻辑。

问题中，包含了非常多的变量：

楼层数是变量；

电梯数是变量；

呼叫电梯的人，所处的楼层是变量；

呼叫电梯的人，往上/往下的需求是变量；

呼叫电梯的人，与电梯轿箱的相对位置是变量；

呼叫电梯的人，往上/往下的需求，与电梯运行的相对方向，也是变量；

目标是高效的接载逻辑，高效背后代表了以下诉求：

较低的使用能耗；

运行过程中尽可能多的进行接载送达；

满足整体的快速接载及送达；

在逻辑高效的基础上，确保逻辑架构的合理，便于扩展其他分支逻辑，比如：

考虑轿箱内乘客的体验，当前楼层距离呼叫楼层过近时，不能瞬间停靠，需要排除；

某一轿箱故障/检修时，需要排除；

某一轿箱满载时，需要排除；

某一轿箱长时间停滞时（被人卡门），是否要排除候选；

更多；

所以，如果你是电梯软件系统的产品经理，你认为接载的业务调度逻辑该如何设计呢？

一、如何设计？

业务调度的逻辑思考：

依据效率优先原则，优先考虑优先条件全部满足的场景。其背后的逻辑，与我们赶火车时的逻辑非常类似：当我们要从杭州去上海的时候，假设每趟火车的时长都一致的情况下，我们应该如何选择火车？

赶火车时的常理思维：

选择当前所有已发列车中，最快到达杭州站的火车且往上海去的，然后顺路上车是最快的。

相对我而言，虽然发车但反向开走的火车，我都会排除掉。

如果没有向杭州来且往上海去的运行中的火车，则我会考虑未发车的火车。

电梯场景下的业务调度设计：

电梯按下呼叫按钮瞬间，我们需要选出一个目标电梯来接载。在触发按钮的状态下，电梯可以分成“运行状态”，和“静止状态”两个分类：

为了节能，我们优先考虑运行中的电梯；

为了考虑具备接载的可能，选择距离最近，且顺向的电梯即为目标，若逆向直接纳入排除列表，再选择下一个距离最近的继续判断是否顺向……

若运行中的电梯，没有找到顺向者，则考虑静止状态的电梯；

为了节能，优先考虑距离最近的电梯且未被排除的电梯，即为目标；

若都没有合适的电梯，则系统等待当前电梯任务结束后，再重新判断；

核心解决思路：抽象出最关键的调度核心逻辑，同时考虑逻辑扩展的可能性。

二、供参考的个人答案

选出当前距离任务楼层最近，且，未被排除的电梯（被排除的可以状态很多：如满载超重、故障代码、人为卡门超时、维修暂停、节能暂停等……），判断是否有可选电梯；

若有电梯，则判断该电梯是否正在执行运输任务；

若是（执行中），则判断是否执行顺向任务；

若是（顺向），则将任务插入该电梯运行队列，实现接载（此处可以有扩展逻辑，如顺向，但距离过近则排除等）；

若否（反向），则列为“排除电梯”，并重新执行逻辑1；

若否（未执行），则将任务插入该电梯运行队列，实现接载；

若无电梯，则等待空余电梯通知，通知发生时，清空排除电梯清单，重新执行逻辑