12｜法则五：如何提升一个架构设计的外部适应性？

“先开一枪”这种事情，在软件行业还是挺多的，一般流程为： 1、有了一个好点子； 2、快速找几位优质用户沟通； 3、如果某用户特别认可，快速研发一个基础版上线试用； 4、如果用的好，再找一波用户试试推广； 5、如果购买意愿都很强烈，就整合销售、售前、产品、研发要正式出1.0版本开始打单了。 其中任何一个环节有问题，这一枪就结束了。 技术很牛但惨烈的例子其实挺多，比如： 1、有些技术优秀的产品自身难以推广；比如，当年屏幕之争的时候，等离子屏幕在各种技术效果上是吊打液晶屏的，在显示效果上液晶连传统CRT屏都比不上。但最后，液晶屏大行其道，等离子屏由于价格太贵、无法用于移动产品、产品力不足等原因，逐渐退出市场； 2、有些逆行的产品知难而上，比如阿里做社交、百度做支付、腾讯做微博，哪有技术差的，战略意义很大，明知很难必须搏一把； 3、有些扎堆创业的产品脱颖而出太难，之前百团大战，到共享经济，到社区团购，最后拼的根本不是技术； 4、国内外政策导向很重要，从之前的P2P、到区块链、到近期的各类培训机构、还有美国对华为等公司的制裁，但都很难受； 5、产品本地化能力差，导致水土不服的，比如亚马逊，eBay，还有其他流量前几的网站； 6、市场被新技术替代的，比如柯达、黑莓、Yahoo等，在原有领域技术领先，但被新技术抢占了市场；

> 我见到比较好的办法是把绩效考核仅仅与业务结果绑定，而把技术线晋升与长期的技术体系建设绑定。 晋升答辩的时候是看业务结果还是看技术难度呢？业务结果往往不取决于技术人员，业务/产品经理晋升的时候那业务结果去答辩显然没有问题，但是技术人员的晋升答辩往往会遇到这样的两种情况： 1. 评委说我做的这个事情虽然业务结果很好但是没有啥技术难度，没有体现出晋级的技术能力 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。

技术的业务理解就是对业务特征的理解,并不是侵入产品和运营里面去改变产品和业务的形态。选择合适的“特征值”来做回归算法,通过数据的转换提供给业务和产品决策，思路确实开拓了。 我理解业务特征应该是分为几类: 1. 了解行业的上下游,提升上游供给侧的质量和效率,提升下游的消费转换。 2. 熟悉业务的全生命周期,从入口到跳出整个行为链各个行为的分析，分析每个产品步骤的转化。通过数据决策和技术调优减少损失提升转化。 3. 能看到商业模式的发展方向、行业动态、规模变化。做一些技术上的提前量，预先卡位。

回答下思考题2 还是之前分享过的策略系统重构的事情，原来的大方向是通过高频调控+丰富的手段，将运力资源集中于优质商户上，将平台在有限资源下的利益最大化。针对这个大方向，我重构了系统，提高了系统的吞吐量，对模型做了抽象，可以让新的手段快速接入。 结果后来的环境变了，市场份额下降，单量数据难看，所以公司的整个方向变成了提高单量，不允许抑制商户的运力资源，运力资源不足的问题让运力方自己解决。而我的系统也成了众矢之的，要求降低调控频率，手段能下则下，能轻则轻，之前的技术规划没用了。 关于问题3，我想提一下自己的看法。我觉得小范围试错时，最先的那一枪不一定非要从系统开出，可以考虑在不动用开发资源的前提下去做尝试。这样依赖会更少，实施起来跟容易，等有了一定的数据基础后，再申请开发资源会更容易。比如我之前在未来配送团队做的智能柜配送，这个事情刚开始的探索只是在办公楼下摆几张桌子，然后人工统计单量，访谈骑手，柜子是后面迭代出来的方案。

我分享一个有意思的事，关于业务理解的～。 刚进入到现在这家公司的时候，突然有一个月发现绩效被扣了4%，然后我找领导谈话，了解一下原因。领导跟我说这4%是因为过度的给测试同学讲业务逻辑和具体的实现逻辑了，导致浪费了测试同学的工作时间，建议我再遇到类似的情况，让测试同学直接找产品经理，而不要直接跟测试同学讲业务逻辑和具体的落地实现方式！不知道老师对这个事怎么理解(⁎⁍̴̛ᴗ⁍̴̛⁎)。

要是我是那个老财主，就应该反过来思考，怎么样让身边的人都富裕起来。

希望可以能多分享一些To-B业务的经验。有些内容听下来，更偏互联网的业务。但是现在还是有很多企业是内部的项目，使用SAP、Salesforce等传统的大型系统。对于这一类大型的生态系统，我们作为架构师站在企业的角度应该思考些什么呢？是否可以替换掉这些系统呢？谢谢~

这原则应该同样可以应用到微服务拆分里去了

回答课后题：（仅个人观点，欢迎反驳讨论） 1.以供应链为例。随着新零售的发展，履约诉求也在不断变化，对供应链系统的挑战也就不断增加。如何快速提供履约能力满足新的履约诉求就成了技术带来外部适用比较重要的场景（我认为智慧供应链不在通用而在包容）。对应的技术手段就是提供一套开发平台（能力服务化+基于扩展点快速落地行业定制），支撑横向的服务化的供应链平台能力+垂直的行业定制共同迭代产品（先定制后沉淀）。带来的价值，不好说。这件事难在共识和协作，开发平台本身更多是提效的价值（前者决定能不能做，后者只能决定做的快慢）。 2.站在销售渠道的视角，品维度的供应链系统会不会就是一个失败案例？我们看到电商卖所有，却少有听到说品类有私有属性的，货放在管理与履约的场景不只是货（仓管理视角，比如电器需要对应的质检能力。配送视角，比如大家电还需要上门安装的能力）。如此来看，货的管理和履约也许品牌方更合适，当下也有一些品牌方在尝试做一盘货，既有利于库存周转也有利于落销量数据，便于做客户销量计划和自己的生产计划。如此一来，销售渠道方与品牌方就不再是货权转移的关系，而是基于合同的销量分佣+履约服务条款（品牌方保证送货时效啥的）。底层的货权概念没了，上层的供应链系统自然也就不合适了，比如要转变成以监管考核+分佣为核心。 3.先打一枪常有，打完能不放炮的不多。mvp开始大家都知道，但后面要不要做大，很多时候箭在弦上不得不发。（数据有虚实，评估有偏向，利益在里面，长期博弈下多是相互帮衬）