讲讲策略产品（上）
写在前面
策略产品经理就如同常见的 AI 产品经理、增长产品经理一样，曾经一度流行，然而却名不符实。
名不符实的关键不在于策略产品经理价值不大，而是与 AI 产品经理、增长产品经理一样，背着这个 title 的做什么的都有，没有任何可比性。就像一个段子，来自东西南北中五个地区的福建人开会，表面上都在说福建话，但互相压根听不懂。把国内叫策略产品经理的拉一起开会，估计也根本聊不到一块去。
那话说回来，策略产品经理到底应该是什么角色？有的人会把策略产品经理跟功能产品经理对比，认为“水下工作”就是策略。做功能和做策略看似解耦，实则不然。要解决一个完整问题，表面是交互和视觉，背后一定是策略，才形成完整的功能；比如说派单，就是一个完整功能，光做接单页面毫无价值，也很少见靠谱的团队会把“页面”和“策略”完全分开做。
有的人会说，有“复杂策略”工作内容的就是策略产品经理，比起体验产品经理来，策略产品经理更关注背后的复杂逻辑。这也有问题。首先，怎么定义“复杂”？其次，绝大多数产品经理实际都是在做策略。“怎么吸引用户”、“怎么提高转化”，也需要复杂的逻辑。比如，要让抖音的用户持续刷下去感受不到时间，这是体验产品经理还是策略产品经理做的？要让淘宝的用户愿意购买，这是谁负责的？
还有人说，“接触算法和技术策略”的是策略产品经理。这种定义就完全没意义了。谁见过 Python 产品经理？见过 C 语言产品经理？以下游实现方式来命名职能，毫无道理。况且，产品经理的核心价值是在做出好的产品方案，而不是“熟悉算法实现”，这样会误导许多新人入坑，后来发现自己只是技术的“文档助理”。
因此，策略产品经理本就是不严谨的说法，不要看到自己的title是策略产品经理，就去报个策略产品经理的课。增长策略、交易策略、营销策略、商业策略…… 之间几乎没有共通点，还不如把策略两字去掉更准确。
总结下策略和产品经理的关系，应该是：策略是产品经理实现产品价值的手段，而不是结果。有时候增长、用户体验、商业化等等，才是结果。
策略产品经理看起来高大上，但也容易变成文档经理；看产品经理的核心价值，要看做的策略课题有多难。
说了这么多，是想先定个基调，然后讲讲一些有策略成分的产品课题，给一些“策略产品经理”提供思路，让许多还蒙在鼓里的“策略产品经理”了解下如何做类似工作。
下面以外卖派单策略为例，讲讲我如何思考外卖派单这件事的。（不代表任何公司或产品。）
外卖的派单指的是，平台收到订单，派发给骑手。基础逻辑看似很简单，可以模仿出行行业，就把订单给“最近的骑手”。不过，这样对吗？
外卖派单的目标
跟几乎所有派单/匹配系统一样，就是追求效率最大化。那对于外卖派单来说，目标是什么？
可以跟网约车对比。网约车的所有派单都是以“与用户距离”为主的，这是因为乘客的耐心和体验（不考虑预约单），是与网约车多快能到强相关的。
然而外卖派单基本已经养成了用户预期，就是30-60分钟送达，并非是越快越好，因此往往应该是“保证送达准时率”。（这里可以提一句，如果对乘客的预期管理足够好，网约车也可以由“越快越好”变成“越准时越好”，减轻派单压力，比如排队功能就是这个目的。）
在说“保证送达准时率”的时候，我们并没有讲到是保证这一单的，还是保证全局的，这也有很大差别。比如，在极端情况下，一个订单是派往偏僻位置的，这时候我们派给了某空闲骑手，大概率会浪费运力；如果考虑全局情况，可能要牺牲这一个订单的准时，来换取更多订单的准时。
于是我们的目标可以确定为：全局准时送达率最优。要达到这个目标，有很多问题要解决。
个体预测与全局预测
个体预测指的是，我们拿到一个订单 O1，找到一个骑手 R1，来尝试判断下他们匹配后，大概花多少时间完成。全局预测，则是基于个体预测的方法，在O1、O2、O3… 和 R1、R2、R3 … 直接做反复地尝试，算出最好的情况下，是怎么分配的。
可以把个体预测想象成一张张卷子，我们要先找出评分标准；全局预测就是考虑怎么给不同的同学发不同的卷子，最好是物理学得好的能拿到物理卷子，数学学得好的拿到数学卷子…… 作为一个心算能力超常的班主任，在脑海里演算无数遍后，找到整个班级的分数最优化的分配方法。
刚才提到了，个体预测的核心就是找到计算时间的方法。先说时间预测，时间有几个部分构成：骑行时间、取餐时间和送餐时间。
时间预测：骑行距离
时间预测最基础的，当然是要通过骑行路线做出骑行距离的预测，进而能判断出时间。
目前各地图的骑行导航已经做得相对完善，偶尔会遇到修路和大门不通等信息更新不及时的情况（比驾驶导航有时慢得多）。
时间预测：取餐时间
你可能觉得取餐时间嘛，骑手到店不就拿走了，几分钟的事儿，容易预测。实则不然。
取餐时间背后有个巨大的约束条件，就是商家的出餐时间。出餐时间又会受许多条件的约束：
餐品类型。快餐汉堡这样的餐厅，出餐很快；而煲饭或者炒菜就要慢得多。
餐厅效率。视不同餐厅厨师的效率而言。
餐厅订单量。恶劣天气，或者促销活动，节假日等等时候，餐厅订单量会大幅变化，影响出餐。
出餐时间一直是外卖行业的老大难问题。美团由于线下手机支付的门店铺得足够广，能够获取餐厅订单量的数据，会略准确一些。而绝大多数影响因素是很难获取的，比如厨师请假；或者很难预测的，比如促销会多来多少顾客。
取餐时间一旦拉长，可能会造成连锁反应。骑手后面的所有订单都可能受影响，造成大面积送餐延误。
时间预测：送餐时间
取餐难预测，送餐只是用户拿个外卖而已，总不会有太大问题了吧？也不好说。
且不说用户有时电话无法接通（从平台视角看是高发事件，外卖平台通常都是接近10%的比例），还比较容易出现的是，送餐环境导致的送餐时间过长：
小区北门关闭，只能绕南门
高峰期电梯人太多；不允许骑手用客梯，只能绕货梯
去 4-7 楼没有电梯
小区/学校/园区不允许骑车进入
……
同样的，送餐时间拉长也会造成连锁反应。
要做好送餐时间预测，可能要把以上各种因素做好记录和判断。比较简单粗暴的方法是，根据历史数据，标注某些地址为“送餐难”的地址，接到订单后，预测时间时加长送餐时间。
拼单
跟网约车中拼车是一个品类不同，在外卖配送中，几乎没有不拼单的外卖骑手。这是成本结构和拼单效率导致的（外卖单个订单送餐太便宜、拼单效率高）。
这就增加了不少难度，主要是计算复杂度，尤其在刚刚提到过时间预测原本就有失误风险的情况下。
在做个体预测时，要对于骑手已有订单的路径，加入两个节点，再计算新路径花费的时间。这两个节点只有先后顺序要求，理论上可以插入任何节点中间（你可以试算下排列组合的数量）。
平均拼单都是5、6单，就意味着是在10、12个节点中插入2个节点，反复尝试计算。这还只是计算路径距离的时间，还要考虑出餐时间和取餐时间。
因此，每次插入两个节点，对于这个骑手来说，他在这两个节点之后的所有节点时间都要变化。这就要对比每个时间节点跟限定的取餐时间、送餐时间是否相符。
抽象到这个层面，基本就是一个建模问题了。把各种约束条件列好，设定目标，就可以做预测计算。
区域热度预测
回到最开始提到的“全局准时送达率最优”，以上的模型没有解决例子中提到的问题：万一派到偏僻的地方，让运力效率太低怎么办。
这就要引入热度预测，即不仅仅判断一个订单派给一个骑手，对骑手们已有订单的影响，还要判断对未来要来的订单的影响。
预测有两个方法：规则法，即凭经验人为划定一些区域，往这些区域去的订单，都做一定的降权处理；统计法，即看历史数据，哪些区域的订单对骑手效率的影响比较大，做降权处理。
（我在点我达参与的热力区域预测的演示页面，视觉稿）
未来订单预测
热度预测解决不了更复杂的一些随时间影响造成的问题。
假如在某个区域，西南方出现了一个订单O2。这时候候选骑手是小蓝和小紫，这时小蓝身上已经有了去西方的订单O1，而小紫是清闲的。（在本例中，简化订单只有一个节点。）
派单系统通常会觉得给空闲的小紫更加高效。就当下来看，也的确如此。
不过，很快在东边就出现了三个订单，O3、O4、O5。这时候，小蓝和小紫都已经在西边了。按照距离看，他们只能这么再去接单。甚至对于O5，由于太远，可能就都接不到了。
再回到一开始，我们假如能预测到，东边会出现一些订单，也许就可以考虑把O2也给小蓝，让小紫继续待命。
接下来，东边的订单，小紫就可以顺路接完了。
这样就不仅仅在“空间上”做到了全局最优，在“时间上”也一定程度做到了全局最优。
不过，这对于订单预测能力的要求太高了。在密集的区域可能还容易预测（就假定各个方向的订单均匀出现），在订单比较稀疏的区域，就非常难做预测。
另外，刚刚的例子里，东边的订单明显是“串起来”的，是天然的优质拼单，因此对订单派发效率有信心的系统，可以暂缓派单，不要来了订单就立马派出，而是等到有一些拼单苗头呈现出来时，再把同方向的可拼订单一股脑派出。
前文也提到了，外卖配送时效性是有一定弹性的，所以若能结合一定的预测做暂缓派单（比如稀疏区域就不需要），可能也能提升不少效率。
优化计算性能
对于一个订单跟一个骑手的匹配，尚且要考虑一大堆因素，考虑多个排列组合；在这之上，还要考虑多个订单和多个骑手的匹配，也有许多排列组合。这其中，诸多影响因素，都是实时变化的，如骑手定位、路线拥堵、出餐情况、热度变化…… 可想而知，大多数情况下计算性能都会出现瓶颈。甚至连从地图接口取骑行距离的频次，都会是性能瓶颈。
除了增加服务器、提升计算性能等工程师可以去优化性能的方法，对于产品经理来说，也能够从很多方面协助优化计算性能。
常见的方式是，用一些低成本的判断方法，排除掉大量无效的计算。
比如，刚刚提到的节点插入时的计算。虽说原则上可以插入任意节点间的位置，但有些节点明显可以不考虑，如：
距离超过 Xm 的节点
插入与要求时间间距小于 Ymin 的节点（也就是插入快超时的节点前）
再比如，可以先用粗略的“直线距离”代替具体的“骑行距离”来大致计算一轮，排除掉明显不合适的骑手，再做一轮更具体的路线规划和计算。
这些工作看似是工程师相关的，但实际上会与业务场景紧密结合，有的计算过程可以简化、略过，有的则不行。必须在理解用户、场景和业务的前提下判断。
派单与抢单
外卖配送在过去的某些平台长期都是抢单模式。抢单模式从本质上看，其实就是做到了“个体效率最优”，而无法做到“全局效率最优”。
因此逻辑也很简单，在系统派单的预测不准确的时候，即“全局效率最优”甚至“个体效率最优”很难保障的时候，抢单模式就会比派单模式效果好，
举个例子，某个城市的地形复杂，地图信息不完备，地址的POI系统也很不完善，导致大量的计算错误，还不如骑手自己判断得准。那在这种场景下，抢单就会比派单更优。
或者，某片区域的餐厅出餐时间波动太大，按照系统预设的路径去走，会出问题。骑手跟店家核对时间，可以先去送其它订单，再回来取，能更好地完成订单。
另外，点我达之前还做过一个抢派混合的尝试，是从骑手满意度的视角看的。由于对骑手而言订单是有不同价值的（价值除了订单表面的配送费，还有配送成本，以及接下来接单的可能性，像冷区订单价值就低），因此对于明显价值不错的订单，就用派单形式派出；而有一些价值不佳或不明确的订单，派出取消概率很大或容易招致骑手不满，就放到抢单页面给骑手抢。这是从骑手视角考虑的匹配效率最高。
预测修正
刚提到了，对绝大多数预测方法而言，都可以归为规则法和统计法。在理想条件下，我们可以搜集到所有必要的大数据信息，然后设定规则，比如影响系数，来做预测和计算，这样一定是最准确的。
而现实情况下，从单个骑手的配送时间预测，到全局的配送效率预测，影响的因素绝大多数都难以获取，因为外卖配送本就是极重线下的业务，场景变幻莫测，除非是赛博朋克或黑客帝国的世界，恐怕无法做到事无巨细信息化。
因此，解决外卖配送问题的方法通常还是统计法，以及基于统计法的修正。当然中间某些环节，偶尔也会增加规则修正。
比如，我们先有一个策略模型版本 D0.1，基于这个版本，我们当天的送达率是 90%。我们去看 10% 没有送达的情况下，绝大多数是什么造成的。这时可能发现，出餐时间不准造成的损失占比最高，于是我们就看，在策略模型 D0.1 里，出餐时间是怎么算的。出餐时间预测的不准有很多种可能，找到预测和真实情况间的差值，然后寻求优化方案。得到了 D0.2，再去观察和优化。
这是目标拆解的方法论了，这里不再赘述。
-未完待续-
新书上市，敬请开卷：