12 法则五：如何提升一个架构设计的外部适应性？
你好，我是郭东白。
上节课我们讲了外部适应性这个概念，也强调了架构师的职责是通过架构活动为企业不断注入外部适应性，从而帮助企业更好地实现它的战略意图。
那么该怎么注入呢？
上节课在讲影响技术体系外部适应性的因素这部分，我们提到了挑战主要来自三个方面：企业的内部压力、企业的外部环境和企业的组织结构。这三方面的挑战，其实已经为我们指引了应对的思路。那么今天这节课，我们就来谈谈应对挑战的解决办法。
如何抵抗内部压力而为企业注入外部适应性？
企业内部压力的挑战，也有三个，分别是业务交付时间的压力、技术岗供给压力导致技术人员的稳定性差和设计短视的问题，以及考核带来的短期效应。
高速响应业务与技术的需求
交付压力，其实就是在一个高速迭代的业务中维持技术体系的外部适应性。
虽然大多数高科技公司都会在技术上做比较充足的人员投入，但业务和产品职能对技术的首要要求往往是在需求实现的时效上。这个态度非常合理，就像上节课提到的，商业机会稍纵即逝，高速响应机会是每个职能的本能。
所以我们真正要解决的挑战应该是，技术人员如何在高速响应业务和技术需求的同时，还能够保障技术体系的外部适应性。
正如我们在法则一（第2讲、第3讲）所讲的，必须依据目标做出正确的取舍。为什么要做取舍呢？根据我的经验，绝大多数的业务和产品需求只是一个小尝试，而并非战略性投入。对于这类业务尝试，响应的速度是第一优先级，只要不破坏外部适应性即可。
不过这里面还有一些挑战。首先，我们大都处在一个博弈的状态下：业务、产品和技术人员的职能内部和职能之间都在互相博弈。也就是，没有任何一个业务、产品和技术人员愿意主动承认自己的需求是个小尝试。大多数人都试图找出充足的理由去说服其他人，把自己的需求作为最重要的工作。
如果你有比较深度的业务理解，其实不难对业务尝试和战略投入做出区分，你甚至可以判断一个需求的商业价值和成功概率究竟有多大。你也可以与高层不断沟通，确认自己对业务尝试和战略投入的判断。在一个更高层级决策者的心中，他对两者应该是有清晰区分的。
对于业务尝试，我们需要以最低成本完成这么一个任务：从这个尝试中得出一个正确的结论。这种情况下你要做的就是在保障尝试结论有效性的前提下，最小化这个尝试对系统的冲击，因为大多数尝试是不成功的。
什么是结论的有效性呢？意思是说，如果把一个小范围的尝试放到更大的范围内，它的价值依然存在，方法依然有效，那就说明结论是有效的。它与产品的完整性，技术可扩展性、安全性、可维护性等等，几乎毫无关系。也就是说大多数时候，你在实现这类需求时，可以忽略多数横向问题（Cross-cutting concerns），把开发成本降低到极致。
事实上，结论有效性与实验环境有非常大的关系。比如说你圈选了哪些城市、什么目标人群、花了多少营销预算、在什么季节做投放等。很多做算法的同学都知道，有的团队经常发天花乱坠的战报，还有各种经过严格A/B测试后得出的转化增长的结论，但是最终这些本来独立的实验却很少有累积效应，甚至随着时间会逐渐衰减。这里当然有竞争、人群等复杂因素，但其中至少有一个原因：很多人都在试图挑选有利于拿结果的实验环境来做出结论。因此，哪怕是那些所谓的“成功”的尝试，其实结论有效性也要打个折扣。
所以，从架构设计的角度来说，我们要把大多数的尝试尽量封装到一个小的领域内。这个时候，多次的业务尝试不会随着时间而导致混乱，削减技术体系的外部适应性。做到这点，下面的这些架构原则非常重要。
第一，单一职责，指的是要把每个业务尝试尽量封装到一个单一模块中。好处是一旦尝试失败，就可以迅速把业务逻辑下线，避免影响整体的复杂性。
我的经验是，业务尝试在90%的情况下，都是不符合预期的。在这种情况下，符合单一职责的设计很容易下线旧逻辑。这么做很重要，你接手一个烂摊子的时候，肯定恨死那些不下线无效逻辑的前辈们了。打个比方：不下线失效逻辑，就是一个不冲厕所的行为！GitLab里面清清楚楚地写着：“某年某月某日，张三在此拉下一坨烂代码！”
第二，最小依赖，指的是整体架构设计要保障大多数业务尝试可以在业务层完成。如果每个业务方的需求都会侵入到底层的逻辑，那么每次尝试都会变成跨团队合作，这种架构会大幅降低业务尝试的速度。
第三，最小数据共享。一个正在尝试中的业务应该尽量减少与其他业务模块的数据交换，尤其是输出，这样才能最小化它的爆炸半径。否则该业务尝试的数据模型会污染到其他业务，在尝试失败之后对其他业务的影响也会很难剥离。
第四，最小暴露，指的是在业务尝试期接口不对部门或企业外部暴露，包括API、数据共享、事件、消息流等一切对外界造成影响的通信机制。
你可能会说：“我们公司不一样啊，我们的项目都是基于100%的科学决策，多数项目都是战略级项目。你这些原则是小步快跑的公司里才会用的，对我们不适用。比如我手头这个项目，就是CEO亲自指定的战略级项目！”
那我给你一个对战略级项目的简单判断原则吧：战略级项目应该在全公司层面明示，而且要维持足够长的时间。
所谓足够长，对于阿里、腾讯这样的大厂来说，至少是三年起。如果你的部门体量小，那至少也要一年起。所以如果你的业务方每月给你一个新战略，那你可以非常确定地告诉自己：这哥们儿分不太清楚业务尝试和企业战略，他的需求我还是要封装好。
华为创始人任正非有一句话，可以完美总结这个原则：“先开一枪，再打一炮。”也就是说，我们对业务尝试的技术设计，都应该先开一枪，尽量最小化变更范围（Footprint），直到结果让我们笃定到可以把这个项目上升成为企业的战略级项目了，才可以改变做法。顺便说一句，我认为华为的成功与这个原则有非常大的关系。
你如果能准确区分业务尝试和战略投入，也学会了对业务尝试的封装方法，那么对于战略投入，是不是也可以用同样的方法呢？
不是的。你如果真的碰到了三年一遇的战略转型，你的方法就不一样了。
这个时候，你的架构设计就会遇到一个很大的不连续性。这样一来，你的目标不是保障这次变更的最小爆炸半径，而是让战略转型做得尽量彻底，甩掉尽可能多的老包袱，使得未来的企业变得更灵活（至于如何做好战略级项目的架构规划，我们会在模块二详细描述）。
分析到这里，你就明白为什么我们特别强调要区分尝试和战略转型项目了，因为你的架构原则在这两个场景之下完全不同。对于后者，你的目标是要做彻底而不是做快。其实这也是一个区分尝试和战略项目的一个好办法。你可以问问业务方：“你是想让我尽快上线呢？还是让我花大量精力准备好一次战略大进攻呢？”我相信90%的情形下，你得到的答案是前者。
也就是说，大多数时候，保护技术体系长期的外部适应性和实现当下的需求一样重要，如果不是更重要的话。
应对交付和压力的挑战
当然，我们还提到技术岗供给压力导致技术人员的稳定性差和设计短视的问题。想减少这种问题，你作为架构师可以：
第一，提升对封装能力重要性的认知。你要帮每个做技术的同学认识到：我们都要有有效封装业务尝试的能力，这个能力最终会转化为提升技术的外部适应性的能力。这是一个技术人员的基本功，从你写代码的第一天就需要。只不过随着你的职业发展，你从封装代码逻辑，到了封装业务逻辑，最后到了封装业务尝试。一个程序员在日常工作中忽略这方面的能力训练，其实是个不明智的选择。
第二，建设复杂度控制机制。在这里，设计评审很关键。业务尝试也要有设计评审，而评审的一个固定环节就是逻辑、数据和接口的最小爆炸半径的设计。
第三，推行最小必要架构原则。在公司范围内推行奥卡姆剃刀（Occam’s Razor）原则。任何增加功能、引入复杂性的设计，都要做一个正式的评审，而简化的行为则不需要。
上面就是应对交付和压力的挑战的办法。下面我们就简单聊一下短期效应。
完善技术体系的考核
短期效应这种挑战，它的根因在于公司的激励机制不够合理。这个问题，架构师其实没有真正有效的抓手。这是制度上的问题，要靠改变公司的制度来修复。我见到的比较好的办法是，把绩效考核仅仅与业务结果绑定，而把技术线晋升与长期的技术体系建设绑定。
阿里在这一点上做得非常不错，尤其是P8和P9层级的晋升比较看重这一点。我觉得，大多数公司都可以借鉴这种做法。如果你所在的企业没有做到，那么你可以向CTO建议在晋升中加入与技术体系建设相关的考核，也可以建议逐渐增加这个考核维度的占比，比如从10%逐渐提升到30%，甚至是50%。
业务理解
我们刚才提到，你需要比较深的业务理解才能辨别一个需求的战略价值。这和我们上节课提到的一个互联网现象有关：在时间的压力下，不论是业务、产品人员，还是技术人员，都不会在完全看清楚市场后才行动。因此，处在最底层的技术体系，在外部适应性上就不太可能有充足的时间和精力去做到完美。这个时候，就需要技术同学有深度的业务理解，才能保障好技术体系的长期外部适应性。
业务理解这个概念到处都是。我经常看到技术同学晋升时展示自己的业务理解，就是把自己团队的业务讲一遍，或者重复一个业务Leader的宣讲内容，甚至有些同学的PPT还是从业务团队要过来的。这与真正的业务理解有着天壤之别。
什么是真正的业务理解？
我们通过下面这张图来解释一下什么是真正的业务理解：
在一个互联网企业，特别是小公司，业务、产品和技术同学需要一起去认识行业、市场和竞争等外部环境。这意味着每个职能的认知是同步的，是平行迭代的，是没有偏差的。
只不过你作为技术人员，要从技术视角去理解业务，并将自己对业务的认知转化成一个技术动作。而这个技术动作，最终会和业务动作、产品动作一起，将企业带到一个更好的生存位置上。这才是真正的业务理解，也是你独立于其他职能所创造的长期价值。
你会发现，这是你通过了解外部环境而获得的第一手的业务认知，而不是你从业务、产品同学那里获得的二手、三手的认知。从某种程度上来说，这是多个职能在做分布式的学习。在这个过程中，你只是一个技术锤子，在用技术视角去理解业务这个钉子。你不仅要看懂业务人员做业务、产品人员做产品。还要看出门道，最好能提出建议，以及最终预测出的结果。这才是你的业务理解。
所以说，一个架构师要拥有的业务理解的能力，是基于自己对业务深度认知之后的技术洞察，然后通过这个技术洞察来推动业务发展的能力。
拥有了这个技术洞察后，你甚至能从业务视角上看到业务机会，或者从产品视角上看到产品机会。再进一步，你的技术洞察才能为业务和产品赋能。最终，三个职能合力推动企业的发展，而不是三个职能单打独斗。这也是图中红线的真正含义。
其实技术视角和动作也不止一种，对架构师而言是架构抽象和架构设计，对数据工程师而言是数据建模和数据资产建设，对算法工程师而言是建模和算法调优。这些技术动作最终都会作用到业务层面上，从而创造出增长和新的业务机会。
案例指引
我们用上节课里提到的物流的例子，来具化一下技术动作。假设你通过架构抽象定义了物流服务供应商这样的概念，那么你对供应商的能力就可以做进一步的抽象和量化。
比如，你抽象出了这么四个维度。
- 容量：指某供应商对每个类型的服务所能提供的最大服务容量。这是一组与业务场景有关的度量，比如说多个小件包裹/天，多少次登门安装/天等等。
- 价格曲线：指该供应商的服务价格随着服务容量变化的关系。
- 质量曲线：指该供应商的服务质量随着服务容量变化的关系。
- 最小容量：指与该供应商维持商务关系所要保留最小服务的容量。
有了这些维度的度量和建模，你就可以设计一个调度引擎，使其在多个供应商之间做调拨，同时最大化服务质量、最小化成本。
而有了这个调拨能力，业务的运营也会发生变化。你可以不断量化和监控服务商的真实服务容量、服务质量曲线，同时对价格和质量曲线的预测做出调整。而业务方呢，也可以通过这组监控和对业务未来走势的预测，决定是否要对现有供应商组合做出调整。
一旦有了这些数字，业务方就可以有新的运营方法，比如说通过最低容量保障去刺激某个供应商扩大自己的服务容量，或者是提升他们的服务质量承诺。业务方甚至可以决定把某些质量监控直接返回给供应商，使得供应商能够主动响应质量分的反馈。
更进一步地，业务方可以开始度量和管理一个供应商的可运营度。也就是说，当业务方用一组规则驱动一个运营商做出容量或质量改变的时候，这个供应商响应这些规则的能力和时间延迟也可以被度量出来，这些度量就可以转化成一个数字化的可运营度指标，未来可以用来筛选有潜力的运营商。而这种数字化的运营方式，就是技术推动业务发展的一个案例。
这时候你可能要挑战我了，你是怎么一下子找到这四个维度呢？它们充分且必要吗？这些维度到了一个新行业还有效吗？
答案很简单。这就像你写代码的时候会做类和接口设计一样，是一个循环迭代的认知提升的过程。你做多了，就会看到一些常见的模式。这也是你作为一个架构师的经验所在。我也不知道这四个是否充分且必要，不过跑起来之后我就知道了。
或许你还会问，我作为架构师，难道首要任务不是提升技术实力吗？如果花很多时间来理解业务，那我的取舍是不是错了？长期这么做，会不会我的技术比不上做技术的，业务也比不上做业务的？
是的，一个架构师当然还是要以技术实力取胜。但你要想在架构师这个职业上走得更长远，就必须做好这样一个准备：比别人付出更多的努力，下更大的功夫来提升自己对产品的思考、对业务的理解。这是一个内卷的时代，你除了需要卷技术还需要卷业务理解，哈哈。
深度理解竞争环境
第二类挑战具体来说就是：在一个充分竞争的行业，大多数企业并不具备对外部适应性做长期规划的条件。针对这种情况，架构师该如何应对呢？
解法与我们前面讲的跨职能业务理解的过程类似。只不过这里更侧重于站在业务、运营、产品和技术的视角，不断监控和思考竞争对手，然后用技术手段做出应对方案。
先举一个利用技术来竞争的正面例子。在电商竞争中，最常见的就是对新买家的争夺。而新买家的常见行为就是比价，以至于有的电商平台会建设专门的新人专区，通过打折的方式来提升他们对平台价格竞争力的认可度。
那么这里就有很多技术视角的创新机会了。举个例子，你可以设计一个竞争对手的商品价格监控网络，确保自家专区商品的定价低于竞争对手。而这个监控能力又会衍生出大量新的技术机会，比如商家识别、商品识别、商品到SKU的建模、商品主数据、同款识别、图文相似性、合手价计算、竞争价格趋势分析等等。有些领域甚至复杂到需要多个博士学位的研发人员，甚至还可以发展衍生出一些对抗能力。
再举一个非正面竞争的例子。你开发风控能力对付费流量和新人做出识别，防止老买家或黑客团伙反复注册来薅羊毛。
这里的风控能力，又可以拓展到多个技术方向，比如通过深度学习来发现新的风控规则，就是现在比较热门的一个创新方向。乍一想风控似乎与竞争无关，但风控就像一个财主家的高墙。如果你的墙就是个木篱笆，一推就倒，那么贼就蜂拥而至。而和你形成竞争的、躲在砖墙后面的老财主，则平安无事。也就是说，打磨风控技术能够提升一个企业的相对竞争力，最终可以帮助企业提升外部适应性。
这两个例子的应用方向看起来很窄，似乎每个领域都要花不少时间和人力来搭建。从我个人的经验看，这属于比较正常的现象。一个竞争对手的出招，如果是靠一两个成熟的技术范式就能应对，那么这个竞争对手其实也不够高明，估计很快就会被淘汰掉。真正的高手出招之前，必然是经过了深思熟虑，肯定会防止被你一步绝杀。所以说，商业竞争是一个持续对抗的过程。
深度理解市场竞争环境还有另外一层含义，就是帮助你思考技术驱动业务的天花板，避免过分乐观。为什么呢？因为很多商业上的对抗属于消耗战，不可能无限期的打到底。这意味着很多技术动作带来的业务价值，并不能做大尺度的外延。也就是说，你利用技术招数来挖掘市场竞争中机会，是有限的。
我们还是用物流来举个例子帮助你理解。假设有几个物流供应商之间在进行充分的竞争：他们都有自己的冗余运力，都要用更便宜的竞价来获取额外的订单，来扩大自己的规模和市场份额。
在这个假设下，物流调拨系统可以在多个供应商之间肆意挑起并放大价格战，从而最大化你作为甲方的利益。
但事实上，不是任何一个市场都是充分竞争的。供应商仅仅会在一段时间内，通过烧钱来争夺市场份额。如果长时间亏钱，供应商也撑不住。
此外，供应商也不是随意受你摆布的。如果你在供应商之间做调拨游戏，而你的竞争对手却采取了完全不同的策略，比如保底单量、资金注入、股权交易，或者与供应商形成商业伙伴关系，以此来换取长期的、有保障的深度合作，那么你的策略在这个供应商身上肯定不奏效。
也就是说，供应商路由这样的技术手段，仅仅在某段时间、某个地区发生充分竞争的时候才有效。如果天时不对，你发明路由算法时竞争格局已定，那么头部玩家根本不会和你做动态竞价。哪怕做动态竞价，吃亏的也是你。
所以你一定要多和业务同学讨论，尤其是单凭技术视角做大尺度外延的时候，一定要论证有效性。
认知和组织冲突
最后一类挑战，就是研发人员的人性与企业的组织结构。
前者我们在法则二（对应第4讲、第5讲和第6讲的内容）里已经深入探讨过了，而企业组织如何影响外部适应性这个话题，其实与企业的文化环境有关。这个话题，我们会在接下来的法则六中深入探讨。
小结
这两节课我们讲了外部适应性的注入。作为一个架构师，处在一个主动的位置上做一件很了不起的事情：为企业注入技术基因来帮助它长期生存。
那怎么才能做到呢？
首先，你要有意识主动去思考如何注入外部适应性这件事情。
这个思考会引导你做有清晰业务价值的技术创新，从而为一个企业创造出经得起时间考验的架构设计，提供更持久的外部适应性。而能做好这一点首先要理解业务，然后才能找到价值点。当然你需要有深厚的技术实力，才能最大化价值挖掘。
不过，因为竞争和市场的作用，哪怕是逻辑上完美的尝试，最终往往仅在短时间内有效。也就是说，你对一个行业的理解必须持续提升，而你的创新也不能停止。
注入外部适应性最终是个循环往复的认知迭代的过程，也是一个试错的过程。靠尝试、靠创新，而不是靠祖传的招数。因为你的每一步尝试都在消耗企业的现金、时间成本、人力成本和心力，这就回到了法则三（对应第7讲、第8讲的内容）提到的最大化ROI的决策过程。所以你看，这些法则不是孤立的，而是相互勾连的。
未来我会在第二个模块，分享一些具体的招数。
思考题
- 你所在的企业或者是行业里面，由技术带来的外部适应的场景是什么？请你稍微解释一下你所在的行业，具体的场景，技术手段和带来的价值，以及维持这个价值创造的方法。
- 你有没有见到过一个失败案例，就像我们文章中解释的物流供应商逻辑一样，虽然从技术创新逻辑上非常清晰，但是某些假设却在商业环境的动态变化中失效了。为什么会是这样呢？
- 在小范围尝试上，也就是“先开一枪，再打一炮”的方法，你有成功案例可以分享吗？在技术上，你具体做了什么事情来提升整个事情的成功概率？
如果今天这节课对你有帮助，欢迎你点击课程右上角的分享并赚钱按钮，把课程转发给你的同事或朋友，大家一起交流、进步。我们下节课再见！
- neohope 👍（67） 💬（5）
“先开一枪”这种事情，在软件行业还是挺多的，一般流程为： 1、有了一个好点子； 2、快速找几位优质用户沟通； 3、如果某用户特别认可，快速研发一个基础版上线试用； 4、如果用的好，再找一波用户试试推广； 5、如果购买意愿都很强烈，就整合销售、售前、产品、研发要正式出1.0版本开始打单了。 其中任何一个环节有问题，这一枪就结束了。 技术很牛但惨烈的例子其实挺多，比如： 1、有些技术优秀的产品自身难以推广；比如，当年屏幕之争的时候，等离子屏幕在各种技术效果上是吊打液晶屏的，在显示效果上液晶连传统CRT屏都比不上。但最后，液晶屏大行其道，等离子屏由于价格太贵、无法用于移动产品、产品力不足等原因，逐渐退出市场； 2、有些逆行的产品知难而上，比如阿里做社交、百度做支付、腾讯做微博，哪有技术差的，战略意义很大，明知很难必须搏一把； 3、有些扎堆创业的产品脱颖而出太难，之前百团大战，到共享经济，到社区团购，最后拼的根本不是技术； 4、国内外政策导向很重要，从之前的P2P、到区块链、到近期的各类培训机构、还有美国对华为等公司的制裁，但都很难受； 5、产品本地化能力差，导致水土不服的，比如亚马逊，eBay，还有其他流量前几的网站； 6、市场被新技术替代的，比如柯达、黑莓、Yahoo等，在原有领域技术领先，但被新技术抢占了市场；
2022-01-11 - 阿甘 👍（16） 💬（1）
> 我见到比较好的办法是把绩效考核仅仅与业务结果绑定，而把技术线晋升与长期的技术体系建设绑定。 晋升答辩的时候是看业务结果还是看技术难度呢？业务结果往往不取决于技术人员，业务/产品经理晋升的时候那业务结果去答辩显然没有问题，但是技术人员的晋升答辩往往会遇到这样的两种情况： 1. 评委说我做的这个事情虽然业务结果很好但是没有啥技术难度，没有体现出晋级的技术能力 2. 评委说我做的这个事情虽然很有技术挑战也有很多技术亮点，但是业务结果不行，不应该晋升 难道要晋升必须又有业务结果又有技术亮点吗？ 请问老师是怎样看待这个问题的？有什么建议给到大家。谢谢。
2022-01-11 - 罗均 👍（11） 💬（2）
看到老师提到的“技术洞察”，想起当年看《How Google Works》里提到的technical insight，坚持靠拍马屁的“管理路线”，毅然走似乎在整车厂永无出头之日的技术路线......真是感慨万千！ 1. 汽车行业，所有深耕技术的工程师，都深深地感激特斯拉和国内造车新势力，因为他们的颠覆，汽车行业的软件类技术人员才有了更好的职业发展空间。作为竞争对手的员工，感觉特斯拉维持价值创造的方法，或许是Elon Musk清晰明确的strategy intent，attractive products + enabling self-driving。其中国内车厂特别忽略的，就是attractive products还有一个含义，就是优秀的品质。例如Elon Musk曾质疑比亚迪因为质量太差能否在中国市场活下去都是个问题，更不用说在global market了。所以学生认为，以科技驱动的明确清晰的strategy intent是维持价值创造的核心。 2. 最近华为造车比较火，特别是最近刚亮相的AITO，加持了可以与Tesla媲美的各类新技术+理想汽车已经证实了的增程式之道。然而总感觉缺点什么，华为对其代工厂小康汽车的操作，感觉上有点像老师本课中提到的对物流供应商的“摆弄”。学生是一个华为迷，之前在和华为的合作项目也非常开心。但是听国内车厂的人评价，都认为华为过于强势，完全不像对欧美客户那样友好和支持。因此，如果华为这款AITO再度失败的话，有可能是违反了老师总结的法则二——人性。在华为下面实际造车的人，如果内心不热爱自己所造的车，那么最终生产的车，也会缺乏灵魂。当然，还是希望华为这波可以成功。 3. 学生没有lead过大项目，感觉所有的工作都先打一枪，探明虚实后请炮兵团开炮（一般交给专业的供应商）。例如拿Linux电脑模拟车内系统，验证所有的sdk，可以大幅度减少sdk交付团队之间扯皮的时间乃至机会。如上次请教老师dashboard的问题，一般都是先通过大量的日志分析（基于对业务深度了解的数据建模尝试），通过离线数据构建metrics，反复与业务团队确认ROI effective的biz case后，才会请专业的大数据团队搭建实时dashboard。
2022-01-11 - 甘轲 👍（7） 💬（3）
技术的业务理解就是对业务特征的理解,并不是侵入产品和运营里面去改变产品和业务的形态。选择合适的“特征值”来做回归算法,通过数据的转换提供给业务和产品决策，思路确实开拓了。 我理解业务特征应该是分为几类: 1. 了解行业的上下游,提升上游供给侧的质量和效率,提升下游的消费转换。 2. 熟悉业务的全生命周期,从入口到跳出整个行为链各个行为的分析，分析每个产品步骤的转化。通过数据决策和技术调优减少损失提升转化。 3. 能看到商业模式的发展方向、行业动态、规模变化。做一些技术上的提前量，预先卡位。
2022-01-18 - Geek_sa2mt4 👍（4） 💬（1）
回答下思考题2 还是之前分享过的策略系统重构的事情，原来的大方向是通过高频调控+丰富的手段，将运力资源集中于优质商户上，将平台在有限资源下的利益最大化。针对这个大方向，我重构了系统，提高了系统的吞吐量，对模型做了抽象，可以让新的手段快速接入。 结果后来的环境变了，市场份额下降，单量数据难看，所以公司的整个方向变成了提高单量，不允许抑制商户的运力资源，运力资源不足的问题让运力方自己解决。而我的系统也成了众矢之的，要求降低调控频率，手段能下则下，能轻则轻，之前的技术规划没用了。 关于问题3，我想提一下自己的看法。我觉得小范围试错时，最先的那一枪不一定非要从系统开出，可以考虑在不动用开发资源的前提下去做尝试。这样依赖会更少，实施起来跟容易，等有了一定的数据基础后，再申请开发资源会更容易。比如我之前在未来配送团队做的智能柜配送，这个事情刚开始的探索只是在办公楼下摆几张桌子，然后人工统计单量，访谈骑手，柜子是后面迭代出来的方案。
2022-09-12 - 亚林 👍（3） 💬（2）
要是我是那个老财主，就应该反过来思考，怎么样让身边的人都富裕起来。
2022-04-24 - ivhong 👍（3） 💬（2）
我分享一个有意思的事，关于业务理解的～。 刚进入到现在这家公司的时候，突然有一个月发现绩效被扣了4%，然后我找领导谈话，了解一下原因。领导跟我说这4%是因为过度的给测试同学讲业务逻辑和具体的实现逻辑了，导致浪费了测试同学的工作时间，建议我再遇到类似的情况，让测试同学直接找产品经理，而不要直接跟测试同学讲业务逻辑和具体的落地实现方式！不知道老师对这个事怎么理解(⁎⁍̴̛ᴗ⁍̴̛⁎)。
2022-04-21 - Iris 👍（2） 💬（1）
希望可以能多分享一些To-B业务的经验。有些内容听下来，更偏互联网的业务。但是现在还是有很多企业是内部的项目，使用SAP、Salesforce等传统的大型系统。对于这一类大型的生态系统，我们作为架构师站在企业的角度应该思考些什么呢？是否可以替换掉这些系统呢？谢谢~
2022-04-21 - 杜秀清 👍（2） 💬（1）
这原则应该同样可以应用到微服务拆分里去了
2022-03-29 - Jxin 👍（2） 💬（2）
回答课后题：（仅个人观点，欢迎反驳讨论） 1.以供应链为例。随着新零售的发展，履约诉求也在不断变化，对供应链系统的挑战也就不断增加。如何快速提供履约能力满足新的履约诉求就成了技术带来外部适用比较重要的场景（我认为智慧供应链不在通用而在包容）。对应的技术手段就是提供一套开发平台（能力服务化+基于扩展点快速落地行业定制），支撑横向的服务化的供应链平台能力+垂直的行业定制共同迭代产品（先定制后沉淀）。带来的价值，不好说。这件事难在共识和协作，开发平台本身更多是提效的价值（前者决定能不能做，后者只能决定做的快慢）。 2.站在销售渠道的视角，品维度的供应链系统会不会就是一个失败案例？我们看到电商卖所有，却少有听到说品类有私有属性的，货放在管理与履约的场景不只是货（仓管理视角，比如电器需要对应的质检能力。配送视角，比如大家电还需要上门安装的能力）。如此来看，货的管理和履约也许品牌方更合适，当下也有一些品牌方在尝试做一盘货，既有利于库存周转也有利于落销量数据，便于做客户销量计划和自己的生产计划。如此一来，销售渠道方与品牌方就不再是货权转移的关系，而是基于合同的销量分佣+履约服务条款（品牌方保证送货时效啥的）。底层的货权概念没了，上层的供应链系统自然也就不合适了，比如要转变成以监管考核+分佣为核心。 3.先打一枪常有，打完能不放炮的不多。mvp开始大家都知道，但后面要不要做大，很多时候箭在弦上不得不发。（数据有虚实，评估有偏向，利益在里面，长期博弈下多是相互帮衬）
2022-01-19 - 阜鸟 👍（0） 💬（3）
尝试最大的挑战是：大部分尝试都是中性的，而删除代码则意味这对这次尝试的彻底否定，这对于业务和技术都是难以接受的。然后尝试的代码就会留下来，成为负债。除非有一天，业务和技术已经离职了。但如果离职了，在不知道这段代码用途的情况下，谁敢贸然删除代码？ 结论就是可能最好的办法就是几年一个周期的彻底重构
2022-02-05 - 术子米德 👍（0） 💬（2）
🤔☕️🤔☕️🤔 * 【思考（1）】：安防行业，最近两年最大的外部问题是芯片切换，从原本几个芯片方案，忽然间冒出几十个芯片方案，顺利对接这些芯片，充分发挥出这些芯片的加速引擎，有效规避每个芯片的缺陷，成为技术架构的外部适应性之一。
2022-01-21 - 杉 👍（0） 💬（1）
东白老师，你好！关于先开一枪再放一炮的做法我有个困惑，尝试性的业务如果确认可行，最终会确认加入我们的产品中，之前做的尝试性方案，有可能会因为相对隔离的设计，导致后期维护不易，这时候是要重新设计开发吗？这样会带来第二次开发的成本，相当于一个功能开发做了两次，不知道这种情况怎么处理比较好？ 还有个问题，跟业务比较相关，尝试性的功能开发，后期发现不是很合适，但还是有部分客户在使用，轻易下线感觉对使用的客户不友好，不下线又增加了维护成本，这种情况有没有比较好的取舍方法？
2022-01-11 - VoiceWitness 👍（0） 💬（1）
文中提到的案例，于我所在的企业内多物流供应商的决策机制一般是由产品同学确定或者在后期交由算法确定，在有大量算法储备的情况下架构师应该怎么发挥价值
2022-01-11 - 封志强 👍（1） 💬（0）
受益匪浅，谢谢老师
2022-04-12