深度拆解滴滴|业务操盘手如何决策复杂问题？如果有一天 我老无所依

作者｜有思想的芦苇

任何一家公司在进行业务战略的制定和规划时，经常会从界定和解决一个问题开始。比如，滴滴、Uber，当初解决的就是出行难的问题；支付宝，要解决的是在淘宝电商的陌生人相互转账的信任问题。

那么，面对一个较为复杂的初始问题，该如何做出商业决策（是要去做，还是不做，以及做的话怎么做），是每个业务操盘手在和老板对话，进行业务交流的时候，需要重点关注的。

在搞清楚这个事情之后，我们才会在接下来的一系列行动中，找到自身的定位和价值。

如果企业CEO做出决策不是拍脑袋，而是根据一套科学的理性分析，通常是这样一个逻辑：

先定位要解决的问题（在此之前，可能是一系列的市场研究，战略分析，不再本书的探讨范围），然后根据问题建立一个业务模型假设；

企业要解决的问题往往是较为复杂的，因此会把一个整体业务模型，按照某种逻辑分而治之，划分为几个局部的业务模型 ；

紧接着，制定一个业务的规划，分别去验证这几个局部模型是否能够跑通或交付；

最终，通过得出的数据，验证当初的问题是否能够解决，或再次进行迭代修正对问题的定义。

举例来说，滴滴对问题的界定是如何基于地理位置的移动应用技术，如何让人们的出行更容易。

如果这个问题再进一步界定，就是先聚焦在出租车行业，用户打车难。为了验证这个问题是否可以有效解决，滴滴需要建立一个“供-需-连”的业务模型。

在供给端，滴滴需要先招募司机，能够在滴滴平台进行接单。最初，滴滴希望找到和出租车公司进行合作，但发现一开始难以撬动，转而直接和出租车司机进行谈。

后来，又逐渐发展出网约车，和自营车辆等。在连接端，主要是面向用户的打车软件和司机端的接单管理软件。

同时，连接端的背后是滴滴研发的一套平台派单调度算法。如何根据司机和用户的地理位置，进行效率最优的匹配，并规划司机的行车路线等。

在需求端，滴滴根据各种场景，满足不同用户的打车需求。最早，滴滴切入加班时间晚，打车难的场景。围绕中关村软件园附近进行推广，吸引刚加完班的白领通过滴滴进行叫车服务。

这个整体模型还是相对比较抽象的，如果要能够落地的话，还需要对整体模型进行分而治之，层层拆解成一个一个的局部模型，直到变成最小可执行的单元，以求得在每个局部战场获胜从而赢得业务全局的胜利。以供给端为例，最重要的数据指标是“日在线人均完成订单数”。

日在线人均完成订单数 =日完成订单目标 / 日在线司机数 =在线司机数 * 抢单率 *抢单成功率 *人均完成抢单数*完成率 / 在线司机数 = 抢单率 *抢单成功率 *人均完成抢单数*完成率

从以上指标，我们至少要完成几个模块的搭建：司机的招募机制，确保可以BD过来足够多的司机，保证在线司机数。

司机的激励和分账体系，通过动态定价和即时奖励，让越来越多的司机愿意到滴滴平台去接单，提高抢单率。平台调度与路线规划，保证司机可以准确定位接到乘客，并完成订单，提高完单率。围绕这些指标，我们可以搭建出在供给端的局部业务模型。

类似，围绕用户端，也需要搭建相应的从流量获取到用户转化、留存的局部业务模型。当模型搭建完成以后，就可以定规划、策略来分步骤实施了。

滴滴作为网络平台，具有供给端和需求端的“跨边”网络效应。即，越多的司机可以吸引越多的用户，同时越多的用户也可以吸引越多的司机来平台接单。但是在项目的一开始，在网络效应的启动时期往往是非常难的，企业也很难有足够的资源去同时发展供给端，和需求端。

于是，在规划上，面临的一个问题就是，先发展供给端？还是先发展需求端？

滴滴给的答案是供给端（出租车司机）。

道理也很简单，如果先发展需求端，烧钱让很多用户下载注册APP，但是由于缺乏供给，用户下了单没人接，无法解决用户出行问题，下次就不会再使用，用户就流失了。如果优先做供给端，即使出租车装了接单软件没有单，司机还是可以正常的跑线下的业务，通过接路边的乘客来满足日常营运需求。

当然，从时间段维度，还是要随着业务的增长，保持一个供给端和需求端的平衡。否则在其中一方就容易产生同质竞争（比如用户端人数多了，司机供给不足，会出现大部分人还是打不到车的情况），最终有损产品体验。

开始分步骤实施以后，就可以通过一系列的核心指标数据（如之前提到的人均日订单数），来验证当初模型假设的有效性，根据结果来进行调整。想想当年的滴滴与快的的打车大战，每天背后的阿里、腾讯追加的投资过亿进行用户和司机端的补贴，为什么会有这么疯狂的举动？

本质就是滴滴经过多轮的假设和优化，业务模型最终跑通了，且可以逐步达到稳定的交付的状态（据说当时阿里、腾讯也都重度投入了很多技术资源，帮助滴滴、快的重写后台程序，保证业务的稳定性），并在未来实现进一步的规模化，创造更多盈利的可能性。

回到一开始的科学决策的逻辑，需要强调的是，针对要解决的问题，一开始就建立业务模型假设至关重要。

很多同学会有个误区，认为刚开始我也不知道需要最终交付的产品或服务是什么，我怎么知道该如何搭建业务模型？或者，一开始搭建的业务模型大概率上就是错的，还有必要这样做吗？

答案是：即使是错的，也很有必要。如果在Day 1，我们没有一个假设的业务模型，那逻辑上其实是我们根本就没想清楚要怎么做，就容易想一个“没头苍蝇”，这里做做，那里看看。就好像老板说，希望你能把用户增长做上去，如果没有业务模型，你今天会说我们尝试下抖音直播吧，明天又说好像也可以尝试做下私域流量的转化。

反之，有了业务模型，我们就有了进行假设验证和迭代的基础。在验证模型的环节，我们也不是一味的执行，而是在做的过程中进行动态的验证，调整优化。如果模型跑不通，再去重新思考我们的假设。这样，即使之前失败了，我们也能够通过错误进行学习，提高对业务的认知。

作为业务操盘手或管理者，要具备动态管理的思维，不是静止，或一成不变的思路去看我们的目标和业务。

另外一种情况，尤其对于刚工作几年的职场新人来说，因为能力和知识的局限性，确实不知道一开始如何搭建一个业务模型假设。如果是这种情况，可以通过一些方式先帮助我们快速了解一个行业的状况，然后再根据搜集都的信息进行抽象建模。

（1）先去搜集和这个行业相关的一些关键词 ；每个行业一定都有自己的一些关键词，有时候也叫行业“黑话”。掌握这些关键词的定义，就找到了快速进入这个行业的钥匙。在之后的访谈或阅读相关资料时候，可以帮你扫清一些沟通和学习上的障碍。

比如，我在支付行业，我们经常会提到 “收单机构”、“发卡机构”、“卡组织”、“四方/三方模式”等。

如果是直播行业，经常会提到“爆款”、“引流款”、“场控”、“助播”“ATV （直播间平均在线人数）”等。

（2）找到3-5个专家，进行深入交流，并找出相同点。找到行业专家，是一个非常快速且高效的学习和提升对行业认知的方法。

约个下午茶，每个专家深入的聊1-2个小时，可以看看专家是怎么看待这个行业的，在他的认知中，这个行业的解决方案背后的业务模型应该是如何搭建的？然后从这几个专家的观点中提炼出共性的部分，应该就是一些行业的共识了。

有的时候，甚至你还可以跨行业找一些专家，看是否有机会借助别的行业的业务模型来解决你所在的行业的问题，这些都是有可能的。

举个例子，很多国家的移动支付应用，都是借助分布全国的线下网点，实现城乡汇款服务的（用户A先把钱通过线下网点存到移动钱包，然后进行P2P转账。用户B收到到账通知后，再找到附近的网点把钱取出来。有点类似我们早期邮政的电报汇款，取款凭证不是移动支付钱包，而是电汇单而已），然后通过银行间网络进行城际间的资金结算。

这就意味着，移动支付公司需要搭建一套针对线下业务的运营和激励机制，实现现金从不同线下网点，到银行不同区域城市分行的资金搬运工作。这背后的业务模型，其实和快消品（如联合利华、宝洁）的分销逻辑是非常相似的。只不过这些快消品公司搬运的是牙刷，牙膏这样的日用品，而移动支付公司搬运的是现金。

（3）找到行业相关的3-5本专著进行学习。如果你很难约到专家的时间，也不妨让他们推荐一些行业相关的书籍，或到书店去看，找相关专著。

不是要一本一本读，而是要看哪些章节的内容是不同的专著都会反复提到的，这些是需要认真阅读和消化的行业通识。比如，提到营销，就会有4P理论；提到战略，会有波特五力 ；提到运营，会有AARRR模型等；

如果能找到一些介绍行业历史的专著或付费类音频课程，也可以帮你非常快速的认识这个行业是如何发展起来的，当时是如何从0到1 进行破局的。对于个人学习和成长也是非常好的读物。比如，提到我所在的支付领域，我会推荐三本书 《支付战争》、《隐形Visa》以及《美国运通：强大金融帝国的创造者》。

（4）实践出真知 ，实践出真知，实践出真知。重要的事情说三遍！如果以上方式你都试过了，还是没办法搭建一个完整的业务模型。那就多去到业务中实践吧，在落地过程中不断进行思考和总结归纳。

有关如何搭建整体业务模型，和局部业务模型的部分，还会在后续的章节进行详细介绍。

这里，先假设我们把相关模型搭建以后，接下来就是要进行执行验证的环节。

如果我们在做的是一个新的业务，甚至没有行业参考案例的话，在验证的环节，需要有的思考是，由于企业的资源总是有限和不足的，如何以最小的资源投入为代价通过产出可行性的交付物达到验证效果。在一些创新理论里面，又叫MVP，即最小可执行产品。

比如，大众点评在一开始上线一个在线订座功能的时候，它们不会马上先上个在线系统去和一家一家的商户做软件的集成。这个改造可能还会涉及到硬件的部分，难度可想而知。

取而代之的是，点评的产品经理一开始只是上了一个“在线订座”的按钮，如果客户点击了某个商家的在线订座功能，产品经理就会立刻收到通知，然后手工打电话过去和商家确认，再以短信的方式告知客户订座结果。

当这样运行一段时间，发现客户确实有在线订座的需求后，再去优化整个业务模型，通过后台系统的优化和对接，从而保证整个链路的稳定交付。

因为之前海外的工作经理，我经常接触一些海外的创业者。有一个案例也非常令人印象深刻。

这个创业者希望做类似Uber的共享出行。但是当地没有那么多的出租车或家用车，但摩托车非常的流行。他们就希望打造一个“摩托车版”的Uber。到底这个能否解决当地的叫车问题呢？这家创业公司一开始没有拿到融资，也没有资源去开发摩托车的派单系统。

于是，他们想到一个MVP的方案。先去BD 一些摩托车，然后每天通过excel的表的方式登记摩托车在接单前的位置。

同时，如果客户有叫车的需求，可以通过whatsapp 或facebook （类似国内的微信）进行留言，提供自己的位置等待接单。然后他们的运营人员会打开excel表进行人工匹配最近的供给端在哪里，完成订单的交付。同时更新摩托车完成这个订单后的状态和位置。通过这样低成本的方式，他们快速验证了这个需求，并获得了稳定的增长。

当单量达到一定程度后，他们也赢来了第一轮的投资，这个时候就开始投入资源，搭建整个派单系统和用户端的APP软件。

最后，留个思考题。可以想下，在你的日常工作，或所在的行业，是否可以通过先交付一个MVP产品，进行业务模型的验证呢？欢迎和我交流。