.. Kenneth Lee 版权所有 2022
:Authors: Kenneth Lee :Version: 0.2 :Date: 2022-09-07 :Status: Released
信心和建模问题
本文记录一个架构案例，重点强化一下关于信心和建模的概念。
最近加入了一个学习系统动力学的群，有人分享了一个案例，我发现这个案例特别适合用 于解释什么是“信心”和“模型”这两个概念，所以我记录了一下。
这个案例是这样的：有一个产品，原来的开发效率不高，管理层使用了一个新的管理方法， 我姑且称为“包产到户”：也就是原来是技术管理团队收到需求，判断好这个需求怎么做的， 然后分配给个人来做，但这些人做得没有热情，开发效率不高。现在他们修改成了这个“包 产到户”的形式，管理层收到这些需求以后，直接明码实价内部公开，谁来做，做好了就有 奖，有奖金，有考评等各方面的好处。案例的描述人说：“这样激发了整个组织的积极性， 开发效率带来了很大的提升。”
我是不信这个可能性的，我觉得“你这在玩呢？”，一个团队的资源从来都是有限的，收到 需求敢不按团队能力安排任务，让大家根据兴趣爱好来决定接不接？开发不用组织的？不 用进行架构控制的？这是什么理想世界啊？
描述人找了不少理由，比如有兴趣和没有兴趣的输出是完全不同的，还有设计成什么样， 合入版本的时候，还是有架构师进行代码评审的，等等等等。我觉得都没有说服力。
所以我最后总结说：我觉得这个你说的这个情形啊，和我对现实的认识是对不上的，我是 不信的，但因为你很有信心，所以我觉得很可能你做这件事是带来了你们开发效率的提升， 但你的归因和建模可能是错的。
这个“信心”的说法，让他有点不舒服，以为我说他骗人，他还想解释他们如何真实的提升 了效率。所以，我就解释了一下“信心”是什么意思：你听到了鸡叫，然后看到了太阳起来， 然后你总结了“鸡把太阳叫出来了”，这个归因和建模是不对的，但太阳起来了，是实实在 在的。这叫“信心”（本质是对结果的信心）。
再举一个更接近的例子：比如你做生意，开了个小餐馆，赚了不少，你发财了。你总结说， 能发财，主要是因为地点选得好。或者你总结说，是因为你孝顺长辈，所以祖坟冒青烟了。 你还可以总结说，主要是赶上祖国改革开放的春风，随便做点什么生意都能发财，等等。 这些原因不一定是主要原因，甚至不一定是原因，但你“发财了”，这个事情是实实在在的， 这就是你对这件事情的“信心”。
我们要做一个好的建模，有两个关键要素。一个是对现实认识的“信心”：不是每个人都能 有正确的信心的，比如有些被金融诈骗的人，相信就是有做“国家级大工程”的人看上自己， 非要用自己的钱投资项目，还保证赚100%，这种不是事实的东西，他听了也能很有信心， 还能给自己家里人推销这种项目，这种信心就很容易带来对问题的误判。
理性的人不容易误判上面这种信心，但现实中不少人会掉入第二个陷阱：错误归因。他们 赚钱了，项目成功了，对自己的成功很有信心，觉得无论如何归因，都错不到哪里去，希 望用这个模型作为他未来各种工作的指导。这同样会导致错误。
前面提到的这个问题，我一点点问这位案例提供者的细节，引导他比较开始的时候怎么样 的，人投在哪里了，后来是什么样的，人平时在干什么，收到的需求具体是写什么需求等 等。我判断他们可以成功的原因是这样的：
我这里捕获的模型，也不一定是正确的，如果我要真去控制这个产品，我还要进行更深入 的调研，但总的来说，我觉得后面这个模型更符合我对现实世界的观察经验。
但我这里不是要证明哪个模型是对的。我想用这个例子说明：其实对同一件事，如果归因 不同，建模不同，对系统的控制要素的抽取不同，我们会得到完全不同的结论和策略。
很多人学习系统思考方法，学习架构设计方法，都把心思放在了因果回路图怎么画啦，UML 图怎么画啦，这种问题上。很多公司内部的培训，教的也是这种东西。说架构师缺乏架构 设计能力，说产品经理没有系统思考的概念，然后教他们画因果回路图，建系统基模，画 鱼骨图，搞什么SOWT四要素，什么Use Case，什么类图……这些都是在舍本逐末。所有的高 层抽象，真正的难点在于你把什么特征抽象上来，正确判断是什么控制那些细节的关键因 素。没有这个，整天弄些什么哪种情况叫增强回路，哪种情况叫调节回路，什么系统四要 素，如何表示组合，如何表示聚合。这种都是在拿概念去证明概念，对现实没有什么帮助。
在我提到的这个群中，有一位同事的总结说得特别好，他说：“我从一些讨论中闻到了中世 纪经院哲学的味道。从概念到概念，居然论证成功了。你可以想到‘存在一个超越人类的伟 大存在’，于是，上帝成立”。
我们一旦脱离了对现实本身的抽象，就概念谈概念，就架构谈架构，这些高层抽象的结论 就没有意义了。
所以，我觉得，如果我们刚开始学习做设计，宁愿不要学那些什么UML，什么DFD的知识 （至少不要把那写东西看作是架构）。你就就事论事：因为我要做什么功能，所以我要如 此如此，这般这般。这样你反而不会陷入到“发明上帝”的陷阱中。如果你实在需要一点哲 学上的帮助，更实用的知识可能是《矛盾论》，整个《矛盾论》全部是例证，给您证明的 只有一个观点：要抓住事物的主要矛盾和矛盾的主要方面。我看一些来自不同作者的红军 的军事理论的书，我看到很多都是直接从这个观点开始建模，就是去找某件事的控制要素 是什么。比如打仗，我们的意图是消灭敌人，敌人不想让我们消灭，这两者构成一对矛盾， 不断改变矛盾两方的力量变化，就控制了矛盾的发展方向。然后我们讨论我们战胜敌人的 要素，什么是主要矛盾，武器？信念？哪个在我们过去的战斗中发挥了关键作用？某场战 斗为什么我们胜利了？某场战斗又为什么失败了？……这种简单直接的分析问题的方法，有 效指导了实际的工作，而不是讨论那么多专有名词，说半天，对不上事实，变成了“教条主 义”。
所以，我个人是觉得，如果要入门架构设计，系统思维，不如从学习《矛盾论》和《实践 论》开始，说到底，改造世界的经验，才能指导改造世界。这个地方是没有捷径的。
这里再记录一个类似的例子，有人总结CPRI这个接口为什么可以成功，为此画了一个因果 回路图。他提取的要素是这样的：
这些要素提取上来，加上它们的因果关系，说这是这件事情的因果回路。道理都可以解释 得通，比如说减轻无线基站的体积和重量，就可以降低TCO，从而增加了部署……这有道理吗？ 严格说，这是“有道理”的，但这种道理只能“解释”，不能指导实践，因为实践的时候我们 并不是因为这个原因决定上马CPRI接口的。
我所理解的CPRI的过程，很大程度上是这样的：在一些国家（特别是欧洲），民众不能接 受在自己家附近看见基站，所以在这些地方部署基站不得不把基站藏起来，但要把整个基 站藏起来很困难，供电散热都不能做上去，所以要切一刀。在成本和可行性约束下进行各 种可能性的判断，最终选择仅把天线拉远这个设计。
这个判断模型中，关键的判断要素根本和什么体积重量这些要素没有直接关联，或者说， 考虑关键问题的时候，那些都不是第一考虑要素，如果当时要增大基站的体积来保证拉线 的距离，工程师会毫不犹豫选择增大体积。
或者说，如果不是有这个民众对基站辐射有这种情绪上的执念，这个特性说不定就根本不 会做。难道你又解释说：幸亏没有做这个工作，所以今天才成功了？
说到底，我们必须真的去分析事情本身的矛盾和矛盾的主要方面，否则就一些无关紧要的 要素来讨论道理，就会沦为纸上谈兵。用《矛盾论》的观点来说，这就是要避免：主观性， 片面性和表面性。主观性避免只看道理不看事实（比如教科书说基站和天线是一个结点， 就觉得两者不可分离），片面性是避免只看矛盾的其中一方面（比如只看原告不看被告， 只看地主不看雇农等等），表面性是避免看事情呈现的样子，不考虑呈现这个样子的原因 （比如人吃饭是因为饿，不是人天生喜欢吃饭）。我们总从这些角度来分析我们所总结的 矛盾，我们就更容易知道我们是否看到的是主要矛盾。