美团商品平台化之路—关于架构原则的思考

从2015年初到2018年末，已经在美团点评做了4年商品系统。稍微总结一下。

2019/1/3

 

＃业务快跑、平台慢跑＃

1.业务快跑

2015年初开始做泛商品系统是为了做ktv预订探索，背后写了一套通用点的商品系统。记得第一版商品系统上线、我做得很高兴，但老板跑过来帮我复盘，“为什么这个项目延期这么久”。额，延期了两周！

我第一次那么吃惊，干得那么沉醉却得到这样的反馈，被泼一盆冷水很深刻。当时的背景是原点评要将ktv团购升级为ktv预订、做mvp，典型的业务快跑方法论。早两周交付就能早两周拿到在线的测试数据。

 

那我用了什么理念开发呢？把它当成孩子，给它我认为最好的东西。简洁、易组合的api，全栈式批处理，三套独立的商品领域对象，制作/线上表与服务分离，去ddd、最简洁的代码等等。从技术角度，去实现多了支撑ktv预订业务需要的系统能力，很纯粹的就是想写好。后边反思，做业务支撑要掌握trade off，做为业务方在业务初期要尽量让业务快跑，产品和系统应该都用迭代的思想去做事。

2.平台慢跑

业务快跑真的对吗？头两年在业务团队做商品系统，后两年在平台团队做商品系统。得出一个新认知：平台系统要尽可能的慢跑、冷启动。一味跟着业务快跑味道就不对了。

 

Platform Fist

投资平台基础设施还是投资新业务时机，这本质是看哪一种产生的ROI更有价值，它的判断跟行业市场、公司规模、战略、组织、kp强相关。

 

行业增长较快的机会点、时机很重要，平台基础层少做点、业务上层多做点。假如本身新业务的逻辑就不对头，平台应该多投资源做厚些、复利。创业公司活着最重要，业务不仅要快跑、还要拼命跑。

可以分享下阿里做共享事业部的时机。那时淘宝商城做失败了，技术leader认为商城的商品系统更吊、这应该是支撑阿里巴巴商业的基础，跑去跟CEO老陆讲，老陆干销售的、却听懂了，拍板用商城的商品系统。一个业务做失败了、另一个业务很大很成熟，但技术系统的决策逻辑跟业务之间不是绝对的。

 

大多数公司业务体量决定了组织上的话语权，无论是产品、技术、销售等资源，还是他们背后的工具。平台系统的决策逻辑不是哪个团队人多，哪个业务体量大，哪个技术老板职级高。平台系统的决策逻辑应该是从技术本质出发，它的核心系统能力及先进性是否更好支撑公司的未来。阿里在有了两个BU、几百个人，业务要多元发展，系统就选择了平台化、打破了技术的组织墙。

今天淘宝的CTO负责了大零售、云、中台、蚂蚁等的技术。所有的技术应该都应该被一个头所负责，且与产品地位相当、有独立决策权。要不然高科技企业就是纸上写写。本质上是科技在驱动商业。

 

“Platform First”！平台不能被业务牵着鼻子走。平台系统要按计划经济走，哪些是核心能力、哪些价值大，这是基本的判断。

 

Platform Slow Enough

platform first是方向决策，platform slow enough是开发节奏。平台研发也应该是迭代思维、一点点来，业务支撑不可能覆盖所有的需求。“慢”主要指两方面：

 

一、平台能力尽可能按计划经济走。不可能一下子业务支撑100%到位，开始可能连20%都不到，不能一味支撑“业务快跑”。阿里业务中台的客户满意度kpi就占15%，初期就是要挨骂的，前台开发、产品都会骂你。没魄力、求全求大反而做不好平台，平台的第一要务是苦练基本功，做强设计、做好代码。平台一开始最好冷启动，尽可能降低客户预期。越偏前台的功能优先级可以越偏后。

 

二、平台建设速度不要一味求快、更要求质。抽象程度、可扩展能力、稳定性等这些核心能力要同步发展。可扩展性决定平台未来成长的极限，系统抽象决定着现在能力的极限。稳定性在系统质量里是最关键的因素，平台抖一抖影响面很大。

 

＃批判性思维、认知业务＃

做业务、感触最深的是：业务理解多深刻、平台能力就有多强大。举一个领域解耦的例子。最开始点评团购商品系统耦合着结算信息（佣金率、结算方式）活动信息（开始时间、结束时间）、以及前端控件信息，商品制作发布耦合着审核流程等。

 

做商品系统平台化的时候，问自己最多的问题是：商品跟这些真的有关系吗？可不可以没有？强关系、还是弱关系？

 

我们最终去掉了商品与方案的耦合。从商品领域去掉了结算信息，推动结算方式落地在了客户维度，结算佣金提供了更多的维度的计算，支持类目、方案维度，也支持客户白名单、商品维度佣金。这些都是技术牵头、驱动产品，从无到有的在做事。

 

再举一个重销售端的例子。一个团单最早被称之为方案（方案是与商家开通合作的签约信息），团