管理上的判断和技术上的判断
本文是在一次讨论中，和别人讨论某个决策的判断依据的时候用到的概念。在时间有限的 讨论会议上这个概念不好展开，我下来把逻辑细化一下。
这个问题来自对一个设计方案（下面叫方案P）的判断，我们已经有子团队对这个方案进行 了很长时间的分析了。现在的问题是想判断一下要把这个方案落到实际的产品中，还有多 长的时间。
我给出的判断是：现在没有看到有效的可行的逻辑链，我连第一层设计展开都没有看见， 无法判断这个方案是否可行，我们根本不能把部署这个设计提上日程。
而另一位项目经理（下面称为a）给出的判断是：我们已经投进去三位博士，还有不少软硬 件各个领域的专家了，前段时间攻关，我们每天都在对齐进展，主设计师对这个还是很有 信心。我们可能可以考虑在一两个版本之内考虑实施部署。
谁的判断对？
其实我这里做这个总结，不是想讨论谁的判断对，因为既然是我写的，我当然认为我的判 断对，这毫无意义。我是想用这个例子来说明白，什么是抽象，和不同抽象上的逻辑链。
决策是一个函数，假设我们判断的条件的全集也就前面这些了，这个函数可能是这样的： ::
D=f(一级逻辑链是否有效展开，技术本身投入人力和资源，关键专家意见）
而我的判断是一个抽象，我不看资源投入，我只看某个特定的事实。把函数化简为：::
D= f1(一级逻辑链是否有效展开)
而a的判断也是一个抽象，他不看技术逻辑，也只看某些特定的事实。把函数化简为：::
D=f2(技术本身投入人力和资源，关键专家意见)
我把f1称为技术上的判断，f2称为管理上的判断。f1和f2虽然针对同一件事情，但他们的 抽象采样问题的属性不同，两者的逻辑链也就不同。软件架构中的分层，本质就是这么回 事。通讯需要发出去的的报文包含每个信息，但我们可以可以让应用层处理部分信息，会 话层处理部分信息，链路层处理部分信息。因为我们的“抽象”不同。只是分层是一个维度 的属性提取，而现实的架构设计中，抽象的维度远远不止一个维度。
所以不同抽象的各自在自己的空间中不断强调证据的重要性，没有什么意义。我前面提到 的会议中，我评价a的判断，我说你增加再多的逻辑，你仍在管理上做出的判断，但你这个 判断没有技术上的支持。我说的就是这个意思：我们的分歧不在于各自空间中的信息是否 足够，而是两者的判断哪个更重要一些，或者两者的权重如何权衡的问题。
纯粹从抽象上来说，这两者本身的属性就没有了，是无所谓谁对谁错的。但表面上我对的 机会比较大，因为我给定的是一个“反对”，而a给定的是一个“支持”，反对成功的机会通常 会比较大（因为成事通常很难），但如果从最终结果上看，那就不一定了，因为如果我放 弃了这个机会，可能就给整件事情放弃了一个机会，这样最终整个项目失败了。我表面上 的判断正确毫无意义，只是能给自己脱责而已。项目失败本身就是责，所谓脱责只是口嗨 。
这是又一个关于架构师不能看样子，只能看产品结果的故事。但这里不是要讲这样的故事 ，这里是要说明，架构决策到底是一个什么东西。我们做决策的时候，都觉得自己是给定 一个坚实的逻辑链，但所有这些逻辑链，不过是忽略细节以后的范围收缩，我们并不是得 到百分百的保证的。
有一级逻辑展开，确实是判断一个技术是否成功的依据，但谁说不能是设计师表达能力不 强，没法给“大家”说清楚，但其实这个技术确实是逻辑自洽的呢？
就算有一百个专家判断过，但谁说不能是这些专家只了解自己的实现，不了解使用环境的 用户的确切需求，做出一个他们心中的好东西，但其实用不起来呢？
前识者，道之华而愚之始也。
所有的提前判断，都是失去正确方向的开始。所以很多人，特别是从传统瀑布交付模型过 来的人，真心去体会高难度，长时间的项目，感受到那种无奈后，会觉得架构就像三体运 动，怎么都捉摸不透其中的规律。
但其实如果你接受架构不是一个稳定的长期结构，而是我们一边向前发展一边画完整的 Pattern的过程，就不会这么纠结了。恒纪元不能预判，但恒纪元来了，你赶紧把脱水的人 从山洞里挖出来，响应这个机会，文明还是可以往前发展的啊。大部分高难度，长投入的 项目，如果你非要在项目开始的时候就给定第一阶段干什么，第二阶段干什么，那你就没 有任何理由成功了。因为你就不相信恒纪元的来临时间是不可预判的。
| 补一句和这个上下文无关，但知道这个讨论上下文的都知道我说什么的：
| 这也是我为什么如此反对在这样的高风险项目中部署CI系统：CI系统是给
| 交付做的，是每完成一次修改就要上线的，如果你还没有进入恒纪元就开
| 始做这种事情，每次跑路就要先化妆，你早早就烧死了，还做啥？所以，
| 在研究型项目中弄CI这种重量级设施的，很会让人怀疑你已经跪下了，
| 不打算抗争了，开始为失败的时候做好“没有功劳也有苦劳”的证据了。
| 我跟你说，到最后我不会认这样的输出的，趁早别做这样的清秋大梦。
但如果你总站在现在的条件和机会上考虑问题，眼前的路常常还是很宽的啊——虽然我们仍 要面对无数的损失。这就好像错判一个恒纪元，要烧死一大片，但文明还是在延续啊。
好了，我要开始带盐了：如果你能接受我前面说的这个架构是什么。你就能明白我为什么 每次看到一个机会点，我第一件事就是反复对它进行各种角度的建模和质疑，因为这就是 架构师的工作。架构师不能一开始就给你保证，某条路能直通目标。架构师做的事情是团 队往前走突然看到一扇门了，他会用手电筒往里先照一照，看看地上有没有陷阱，对面还 有没有路，上面的屋顶是不是准备塌下来……然后决定进不进去。所以，“第一层逻辑链”才 如此重要。它确实是前识，也确实会误判。但它是成本最低的判断。架构是个动态排序算 法，架构师的工作是反复评估和集成团队向前走拿到的新信息，然后重新计算所有信息的 合力，进行重新决策。
团队要这样认知架构的工作和这个工作对你造成的影响，你才会能正确使用架构给你提供 的判断。架构也不能取代管理上那些流程匹配，人力模型管理，项目调度管理的手段，但 那些手段，也不能取代架构工作本身，同时，这些判断，最终都需要向最终的目标对齐—— 最后，这个还是一个架构工作。