#商业快跑，平台慢跑#
1.业务运行快速
2015年初，我开始做泛商品系统，目的是探索KTV预订。 我在幕后编写了一套通用商品系统。 记得产品系统的第一个版本上线了，我很高兴，但是我的老板过来帮我审核并问：“为什么这个项目拖了这么久？” 嗯，推迟两周了！
我还是第一次如此惊讶。 我喝醉了，但得到了这样的反馈。 给我泼冷水真是太深刻了。 当时的背景是，袁殿平想要将KTV团购升级为KTV预订，成为MVP，这是典型的商业快跑方法论。 如果提前两周交付，则可以提前两周获取在线测试数据。
那么我在开发时使用了哪些概念呢？ 像对待孩子一样对待它，给它我认为最好的东西。 简单易组合的API、全栈批处理、三套独立的产品字段对象、生产/线上表和服务分离、去除DDD、最简单的代码等。从技术角度来说，实现更多支持KTV预约业务所需的系统功能，纯粹是因为我想写得好。 回想起来，在做业务支持的时候，一定要掌握权衡。 作为业务方，我们在业务前期一定要尽力让业务跑得尽可能快。 产品和系统应该用迭代思维来做事。
2.平台慢跑
快速开展业务真的正确吗？ 前两年在业务团队做产品系统，后两年在平台团队做产品系统。 达成了新的认识：平台系统应尽可能地点动和冷启动。 仅仅跟随业务并快速运行感觉是不对的。
拳头
投资平台基础设施还是投资新商机的本质是看哪一个能产生更有价值的投资回报率。 其判断与行业市场、公司规模、战略、组织、KP密切相关。
当行业快速发展时，机会和时机非常重要。 我们应该少做平台基础层，多做业务上层。 如果自己的新业务逻辑不对，平台就应该投入更多的资源，做厚一点，产生复利。 对于初创公司来说，最重要的是生存。 企业不仅要跑得快，更要跑得苦。
您能分享一下阿里巴巴打造共享事业部的机会吗？ 当时，淘宝商城失败了。 技术人员认为，商城的产品体系比较好，这应该是支撑阿里巴巴业务的基础。 于是我就去找CEO老鲁聊。 老鲁是做销售的，但他了解并决定使用商场的系统。 商品系统。 一项业务失败了，另一项业务规模庞大、成熟，但技术系统和业务的决策逻辑并不是绝对的。
大多数企业的业务量决定了组织的话语权，无论是产品、技术、销售等资源，还是背后的工具。 平台系统的决策逻辑不是哪个团队人多、哪个业务量大、哪个技术老大级别高。 平台系统的决策逻辑应根据技术的性质以及其核心系统能力和先进性是否能够更好地支撑公司的未来。 阿里巴巴现在有两个BU，上百人，业务需要多元化，所以系统选择平台化，打破技术的组织墙。
如今，淘宝CTO负责大零售、云、中台、蚂蚁等技术。 所有技术都应该由一个负责人负责，与产品具有同等地位，拥有独立的决策权。 否则，高科技公司只是纸上谈兵。 从本质上讲，技术驱动业务。
“第一的”！ 平台不能由企业主导。 平台制度必须遵循计划经济。 这是对哪些是核心能力、哪些是具有巨大价值的基本判断。
慢的
首先是方向决定，慢的是发展节奏。 平台研发也应该基于迭代思维，循序渐进，业务支撑无法覆盖所有需求。 “慢”主要指两个方面：
1、平台能力尽量遵循计划经济。 不可能一下子提供100%的业务支持，一开始甚至可能连20%都没有。 我们不能盲目支持“生意快”。 阿里巴巴中台客户满意度KPI占比15%。 前期会被骂。 你会被前端开发和产品骂。 如果你没有勇气、力求完美、做大，你就做不出一个好的平台。 平台的首要任务是苦练基本功，加强设计，做好编码工作。 最好一开始就冷启动平台，尽可能降低客户的期望。 更前景的功能的优先级可以进一步靠后。
2、平台建设不要一味追求速度，而要追求质量。 抽象层次、可扩展性、稳定性等核心能力必须同时开发。 可扩展性决定了平台未来增长的极限，而系统抽象则决定了当前能力的极限。 稳定性是系统质量最关键的因素，平台抖动影响巨大。
#批判性思维，认知商业#
做业务时，我感受最深的是：对业务理解越深，平台能力就越强。 举一个域解耦的例子。 最初，大众点评团购产品系统耦合有结算信息（佣金费率、结算方式）活动信息（开始时间、结束时间）、前端控制信息。 产品的生产、发布与审核流程等相结合。
在做产品系统平台化的时候，我问自己最多的问题是：产品真的和这些有关系吗？ 没有它可以吗？ 强关系还是弱关系？
我们最终将产品与解决方案解耦。 结算信息已从产品领域移除，结算方式提升至客户维度。 结算佣金提供更多维度的计算，支持品类和计划维度，以及客户白名单和产品维度佣金。 这些是技术主导和驱动的产品，从头开始。
让我们再举一个以销售为中心的例子。 团购订单最初被称为计划（计划是与商家开通合作的签约信息），团购订单被称为供应链，主要针对促销场景。 2013年至2015年，美团和大众点评打起了团购大战。 双方依靠销售一一开拓新城、签订独家合同、分销货品、记录订单。 他们降低佣金，甚至为大客户提供担保。 团购的很多功能都是为销售CRM打造的，对效率和速度要求很高。 团购产品定位为优惠套餐。
随着2016年后团购市场的变化，如果继续依靠销售一件单品来记录团单，销售成本将会非常高。 2015年启动的泛商品体系从一开始就是面向商户侧的。 商户端的特点是轻，因为商户需要简单的操作。 后来又增加了销售端，大部分后端接口、功能、页面都得到了复用，销售端的逻辑和商家是一致的，因为我们理解销售更多的是一个辅助的角色。 我们不再将产品称为解决方案，也不再将产品管理称为产品供应链。 O2O产品的本质是：结构化的CMS+灵活的销售形式。 CMS是增加元数据描述和存储的可扩展性，灵活的销售形式是加强价格、库存、销售规则。
关于item的结构b/c。 大众点评和美团在产品上都偏向于B/C架构。 B端称为产品供应链，它与C端（数据、逻辑）会有很大不同。 b/c场景将产品的基础层进行了分离，就像一个完整的人被分割成了上半身和下半身。 这种做法更多的是一种固定思维。 过去是快做的，是这样做的； 以前是这样，现在也是这样。 “存在即合理”，缺乏平台化的建设性思维。 产品基础层的边界包括产品生产、发布、销售场景的闭环。 数据可以是一份、两份、甚至三份，但它们都封闭在产品基础系统中。 产品基本体系不分B/C。 它应该整合产品功能。 从这个基本点出发，将产品数据流通和管理的成本降到最低。
这里最重要的教训是：批判性地思考商业，多思考，并问自己为什么。 市场变了，认知也要变。 我们不能遵循旧制度的思维。 无界限地思考问题。
#平台最低认知业务#
作为平台，选择技术方案首先要考虑的原则是LNP（Least，最少感知原则）。 通俗地说，就是平台方尽量不去感知接入方。 让我们举一些常见的场景。
功能开发场景。 如果函数可以标准化，则可以将它们抽象为多个公共包，并提供默认为包的能力。 使用默认方案，这样平台端和业务端就没有开发量，也不需要配置。 “闻得鸡叫狗叫，却永远不能互动，直至老死”是平台发展的最高境界。 这需要对业务有深刻的理解，并且有抽象通用包的能力。
“每个人都生活在一个富足、和平、安宁、欢乐和满足的世界。 来不来，来不来，对他们的生活根本没有影响。 每个人都活在当下并享受当下。 一时间，我听着窗外鸡鸣狗叫，头顶飘着白云，微风徐徐，生怕有不速之客打破了这美好的时刻。”
数据交互场景。 尝试由平台侧制定标准，建立数据层进行隔离，由业务侧驱动&; 这样，平台方不依赖任何接入方，依赖非常干净。 如果要感知，尽量不要使用spi(rpc)。 spi(rpc)会让访问方的依赖变得非常复杂。 扩展点（jar）方式虽然恶心，但是比spi(rpc)好。 更好的。 还有一种是插件+框架的结合，部署到实例中，但这对资源成本和技术中间件提出了很大的挑战。 当然，依赖平台是一回事。 这种依赖是稳定的。
逻辑判断的场景。 产品系统有很多条件分支用于逻辑判断。 过去，我们依赖非常详细的类别。 现在，只要能依赖更大粒度的产品类型，我们就依赖产品类型（团购等产品类型，美容/美甲等品类）。 如果可以做黑名单，就不要做白名单。 大多数场景使用黑名单来屏蔽特殊逻辑，也有少数场景使用白名单来控制入口和授予权限。 简而言之，如果你能写大逻辑，就不要写小逻辑。 如果你能写出粗略的逻辑，就不要写出详细的逻辑。
我们必须尽一切努力实现LNP。 请注意，配置也是一项非常昂贵的成本。
#要做万能胶，必须有大局观#
什么是整体观？ 我做产品，但我需要知道产品的上下游依赖关系，不仅要将它们与CRM、审计、营销、搜索、广告等数据和功能连接起来，而且至少要跳高一步。 理想的状态是拓展新业务的能力和营销标准已经默认有了，搜索能力也有了。 用户可以通过搜索关键词来定位产品，如果喜欢的话还可以推荐更多符合用户喜好的产品。 。 。 。 。
再往前迈一步，平台方至少要和其他合作伙伴站在同一个频道上，了解商业价值。 当我们刚开始做一个平台的时候，我们认为和其他平台连接就足够了，我们之间的连接是标准化的。 我们要做的事情较少并标准化它们，但其他平台仍然需要安排和开发。 可能只需要半天的功夫，一两个月这个过程就没有了。 平台方应该以终为始，有共同的价值观和全球视野，这样才容易拿出整体最优的解决方案。 我快而你慢。 双方都极其贫困。 这不是平均值。
往上跳两级，就可以从用户的角度理解商业价值。 比如说我做产品、做营销的时候，我要考虑商家是什么行业、什么产品形态、有什么样的需求。 一旦弄清楚并与营销平台对接后，大家就更容易选择更适合的方案。
什么是万能胶？ 通用胶水让人想起脚本语言。 胶水的本质是连接和再创造。 说实话，当一个平台与另一个平台对接时，总会有活跃的一方。 例如，线上产品交易系统更适合以产品为中心，带动售前场景，让数据流淌到各种线上营销场景。 这时候产品中心就必须起到万能胶的作用，为营销定制大量的适配器接口，为搜索定制大量的适配器接口。 大宗商品交易系统以商品系统和交易系统为两个轴，带动核心系统和外围系统。
万能胶会有大量的开发和维护成本，又脏又累的工作。 一旦做到了，一个大的平台能力就有了一个中心来驱动，效率可以提升几倍、十几倍。 从全局来看万能胶，必须找到一两个中心来承担起连接其他中心的责任。
#方法论、仪器和活力#
方法论相对薄弱。 如果你相信它、思考它、运用它，你就会有体验和感悟。 在过去的四年里，我只记得软件架构方法论的“SOLID原则”，而我反对所有像DDD这样的东西；
更简单地说，“高内聚，低耦合”； 更简单地说，就是“边界”。
这里第一点是关于方法论的，因为我希望大家少一点方法论，多一点实际。 理论与实践不存在冲突。 技术中有很多被炒作的概念，每个人都应该尽力去理解本质。 不懂也没关系，一步步练习就可以了。 如何练习呢？ 我只持有几个方法论，比如SOLID、GRASP，或者“简单”、“边界”，短短几个字，但其实就够用一辈子了。 关键是要用它。
工具化。 工具网上讲的很多，比如元数据、配置、组件化和拼接、模块化、服务化、规则引擎、流程引擎、UI工具、前端模板等等。不讲具体细节，我想讲的是啥工具的本质是什么？ 本质是提高效率，提高生产力。 如果你能让代码写代码，就不要让人写代码。 如果你能用工具代替人，人就会被工具代替。 这也是UNIX的哲学之一。
活力。 最后我要讲的是平台系统的活力。 人、动物、植物都是有生命的，而机器和代码却是冰冷的，没有生命力。 阿里巴巴业务中心副总裁宣楠在《面向不确定性的软件设计的一些思考》中提到，阿里巴巴的平台体系已经完成了工具化阶段，现在需要走向核心思维。 你本质上在说什么？
电商有很多平台，包括用户中心、产品中心、营销中心、交易中心、金融中心等，有了这些中心，前端接入端还是很痛苦的。 看似功能齐全，但使用起来却非常复杂。 就像新手去华强北组装电脑一样。 CPU和主机是什么？ 接入平台的复杂度可能比接入方搭建的还要高。 这么多中心如何协调？ 因此，提出核心思想。
我来解释一下核心思想。 我是第一个接触操作系统的人，认为POSIX标准接口是内核最伟大的部分。 它本质上是与用户空间的标准通信接口。 不过，这几年想想，这只是大家看到的一层皮而已。 标准通信接口无法解决操作系统功能的本质问题。
UNIX 有很多哲学。 我选了以下两条，用一句话概括：“整体大于部分之和”（亚里士多德）。 UNIX是Micro（微服务），LINUX是（），但之所以采用LINUX是因为“整体大于部分之和”。 从这一点来看，它们有一些共同点。 如果这些平台被孤立成插件，它们就会失去统一指挥的能力，换句话说，它们就会失去活力。
为什么后来出现的LINUX最终统一了操作系统市场，而不是一开始就被设计得非常模块化、插件化、微服务化的UNIX？ 这值得深思。 如今，微服务火热且浮躁。 我们需要真正清楚地思考系统想要提供什么。
比标准化更强大的是，这些平台形成了统一的生命形式。 举个例子，如果你订购了一款新产品，所有平台都能立即感知到吗？ 一旦感觉到，这些平台就可以自动发起决策，系统之间互相通信后就可以创造出新的产品？ 现在对计划、产品、交易和结算等产品概念的理解与变量名称和值不一致。
这需要这些平台的紧密耦合、更高层次的抽象和统一指挥； 但这并不一定需要一个统一的指挥官。 只有整体大于部分之和，系统才能超越原子和还原论，使每个平台系统都充满生机和活力。 我们仍然应该深入研究各个子系统的抽象概念细节，重点关注这些系统之间的强联系以及它们是否统一和紧密耦合。
最后引用一段话来谈谈两个核心的哲学差异：
UNIX
即使是 UNIX 的 a 和 , no 或 idea 也能很好地工作。 ，是什么使得它是使用的。 不可能在 a 中失败，其核心思想是 a 的力量更多地来自于中间而不是来自于。 许多 UNIX 确实可以使用 , 但是，使用其他 , 和 工具。
在UNIX中
UNIX 的大部分功能都来自于易于使用的风格，更重要的是，易于与其他操作系统兼容。 这种风格一直是使用工具，更多的是关于如何适应以及如何使用它们，而不是关于它们如何使用。 [...] 这种风格基于使用：使用 或 in 来完成一项工作，而不是手工、自行或一次性完成。
莱纳斯谈论
当我开始写Linux的时候，有一个关于如何写的问题。 问题是你必须使用 -style 。
比如Linux，就是分为用户空间和空间。 space 是代码所在的位置，where 是 for -level 的位置。 、 、 、 I/O 、 、 ：其他依赖照顾的核心。 低级代码将 , 转换为 a 。
一组更多种形式的 、 、 和 ，以及一些低级 I/O。 更少 - 其中许多都进入用户空间。 A 是 、 的一种方式，因此端口 to will。
因此，当我在 1991 年从事 Linux 工作时，我来自 . 你看，这就是当时的情况。 ，我是a，当时我感觉(a)是，(b)是超过，(c)是超过。 在现实世界中速度很快，所以当时花了很多时间来制造它，这样他们就可以像 . 有趣的是，如果您阅读这些内容，您会发现，虽然它们是他们的，但实际上那些相同的也可能是他们的。
事实上，这让我认为这是一个旨在更多的。 我不认为这些是。 他们是 。 或者 。 我的意思是非常真实的。 这个话题来自于当时的话题。 在实验室里，你要么是，要么根本不是。 甚至NT也是如此。 虽然 NT 团队知道最终的结果，但他们知道必须口头上承认这个想法。
我从来没有感觉到太多。 从 20 世纪 60 年代末开始，这个话题就一直存在，但并没有看到如此多的话题。 从某种程度上来说，他们是对的：Linux 的诞生和诞生在 20 世纪 70 年代初就已经很流行了； 之后一直到一些自我。
如果您想要代码，那么您就不是一个层。 你刚才 。 ，制作是浪费时间。 这就像一辆快速的汽车和上面的轮胎。 消除必须要快的一件事的想法是——。
还有比这更多的事情。 但其中很大一部分是目标。 其中大部分的目的是为了实现一个理想，想出一个与任何人一样的理想。 有了 Linux，我就不必设定如此崇高的目标。 我在现实世界中，不是。
