# 29 自我愈复系统 一名员工冲进人事部，愤而辞职。次日，他和他的老板有些尴尬地解释道，其实整件事情是一桩再愚蠢不过的误解。可能撤回他的辞职申请吗？处理这类事情的员工看到这不够完整的事务还处于混乱之中。无论是谁设计了终止处理的流程，其实并未意识到撤销的流程。但是，很容易看到是什么让一切回到正轨：瞧，我们可以把整个文件丢到废纸篓中，就好似它从来不曾存在过；接着，我们清除掉最后的工资检查单，跑到 Harry 桌前，在他看到取消保险的表单之前赶紧拿走…… 这个系统就这样自身治愈了。有时候，系统背离了最初的设计；有时候，横空出现的设计是有必要的。那些让系统运转的人们总是忙于修复系统。事情总是如此。 ### 确定性与非确定性系统 当你对之前全人工的系统进行自动化时，系统会变成确定性的。新系统只能响应制造者设计的那些显式的命令。于是，自我治愈的能力就丧失了。任何需要被响应的要求都必须预先设计进去。如果需要治愈这样的系统，就只能在系统运行环境之外来处理。维护人员只能对系统进行分解，添加一个乃至更多新的计划好的响应来对其进行重建。 从一种视角看，去除掉混乱不可控的自我修复能力，是自动化的积极一面。系统会首先被“恰到好处”地规划，在运行时不需要再修修补补。但显而易见，这一做法可能花销很大。自动化工程师花费了不少时间去臆想一些很少会发生的情形，或者是旧的依靠人的系统从未被预先考虑，除非真正发生才响应的情形。如果新系统管理的业务随机变化达到一定程度，系统自动化就是一个错误。确定性未必有利，系统会被迫持续不断地进行维护。 非确定性系统之所以能够毫无痛苦并优雅地（有时候甚至无须成本）完成自我修复，是因为组成系统的人熟知根本的目标。一旦新的形势出现，他们可以立刻获知什么行动才是有意义的。或许到某一天，我们可以教会计算机了解系统需要达成的目标，而非为了达成目标而采取的行动，但目前这还是超出了我们的能力范围。这里的要点在于：让系统变为确定性会导致它失去治愈自身的能力。 在某种意义上，你工作或管理的组织就是一个系统。它是互相协作的人为达成某种目标的过程的混合物。当前，流行的讨论话题是怎样让这样的系统变得更为确定。这就为我们带来了关于方洼学的讨论。 ### 方法学的隐蔽含义 对大多数组织来说，令人疯狂的事情是整个组织的品质取决于组织的员工。如果我们能绕过这个自然限制，即使雇用的是平庸而无能的人，也能打造良好的组织，岂非更好？没什么比这更容易了吧——我们唯一需要的就是一种方法学（请大张旗鼓地渲染吧）。 方法学是一种通用的系统原理，阐述了思想密集型的工作该如何管理。这种方法学可以被大书特书，编纂为著作来细述其细节，包括在何时采取何种步骤，而不用考虑是谁在什么时间什么地点去履行这些方法。编撰方法学的人们都很聪明。落实这些方法的人则可能是笨伯。他们从来不需要开动自己的大脑，所有能做的就是照本宣科，沿着一条如《绿野仙踪》中描绘的黄砖小路(Yellow Brick Road)，就像快乐的小梦境人(little Munchkins)，从工作开始到成功结束。方法学会做出所有决策；而大家什么决策都不用做。组织就这样完全变得确定化了。 就像其他系统一样，由人组成的团队也会丧失自我愈复能力，到了一定程度就变得确定。结果，团队成员可能会沿着毫无意义的方向前进，单凭这点我们就能断定他们什么都做不好。几年前，我们对一个失败的项目进行了事后复盘，我们让每值项目成员写下自己在项目过程中的观察。他们是在自己家里隐蔽地完成记录的，而且我们也向他们保证了只有我们两个咨询师能够看到他们的记录。其中一位项目成员告诉我们，他的观察如下： 三月份，我们已经进行了接近两个月（更高地要求运用其中某项技术）。我看不到这在什么方面能帮助我们，但 George 不停向我们保证这是有用的。他说我们应该相信这个方法学，船到桥头自然直，到最后，一切都能迎刃而解。 当然，事与愿违。项目成员是最熟悉项目范围的人。如果给定的方向对他们没有意义，方法就不会奏效。 大型方法学与小型方法学之间存在巨大差异。小型方法学是完成某项工作的基本途径。它并不存在于哪一本高文大册，而是存在于执行这项工作的人们的脑海中。这样的方法学包括两个方面：定制的计划（特定于手边的工作）和使计划有效的必备技能。人们很少会反对小型方法学：没有它，工作就无法开展。然而，大型方法学则迥然不同。 大型方法学试图进行集中式思考。所有有意义的决策都必须由方法学的构建者做出，而不是由真正做事情的人来决定。支持该方法学的人士会给出一份长长的介绍预期利益的列表，包括标准化、文档一致性、管理型控制以及最前沿的技术。这些实例公开而明显地佐证了方法学，而隐蔽的情况却简单而又粗糙：项目成员不够聪明，不足以进行思考。 ### 疯狂的方法学 当然，要是你的员工不够聪明，没法想到该如何完成他们的工作，工作就会失败。没有什么方法学能够帮助你们。更糟糕的是，大型方法学可能会极大地影响那些完全胜任的员工，通过强迫他们工作在一个固定的模子里，从而确保 * 泥沼般没完没了的文案 * 少得可怜的真正可行方法 * 从来没有的责任心 * 消磨殆尽的热情 接下来，我们会评估这里列出的每种影响。 文案：大型方法学内容繁多，而且还在不断扩充（它们不得不因为新情况的出现而增加新“特性”）。一套大型方法学的著作占满书架的一排甚至整个书架也不为怪。更糟的是，它们鼓励大家去编写文档而不是开展工作。这些大型方法学对文档的痴迷应该源于偏执的防御性思考，类似这样的想法：“上个项目写了重达一吨的文案，结果还是失败了，真是一场灾难啊；所以，在这个项目，我们要写出两吨的文案。”在我们经济领域的科技板块中，过去几十年里总是暧昧地认为只要文案再多一点就能解决问题。或许，是时候引入如下的“异端邪说”了： 事无巨细的文档引入的是问题，而非解决方案。 方法：大型方法学的核心在于标准化方法的概念。若有上千种能够完成工作的好方法，选择一种来进行标准化或许是合理的。但在时下的技术萌芽期，对我们从事的多数工作而言，还处于缺乏完整方法的阶段。当出现真正的选择方案时，人们必须了解和掌握它们中的所有方法。对一种方法进行标准化，就是排除其他方法。这种观点认为知识弥足珍贵，我们应该珍惜使用。 责任心：要是某种方法学不生效，应归咎于方法学本身，而不是苛责于人。（毕竟，方法学可是把所有决策都做了啊。）在这种环境下工作，等于有了豁免令。人们愿意承担责任，但除非能够享有对等的自由来获得成功，否则没人愿意这样干。 热情：实施一种方法学的决策给每个人传递着同样的信息，没有什么比得知管理者认为自己的员工无能更让大家丧气的了。 ### 恶意合规问题 对于方法学的制定者来说，折磨他们的是，害怕人们对这些方法学视而不见。在很多组织里，这就是现实。更让人失望的是另外一种极端：大家并不忽略方法学，而是照本宣科，方法学怎么说，就怎么做，就算大家知道这样会浪费时间，生产出无用的产品和毫无意义的文档也会这样。这就是我们的同事 Ken Orr 总结的“恶意合规”。当方泫学上说，需要提供包含十八章的操作人员手册，开发人员就会去写一份，哪怕该产品被深度嵌入到一个引擎或者卫星里，压根儿不需要操作人员接触。当方法学上说，需要为每一条数据元素填写一份数据库存储位置，开发人员就会照办，哪怕这个系统根本没有数据库。 在澳大利亚，那里罢工占用的时间和工作时间一样长。罢工有一种特别的形式叫按规工作。工人们不会离开工作岗位，而是打开厚厚的工作程序指导书，然后说：“如果你不满足我们的要求，我们就一直按照指导书上写的规程来。”比如当空管这么干的时候，他们只能每 7 分钟降落一架飞机。如果医生这么做，简单的阑尾切除术需要一周时间。在多种经济环境中引入方法学就可能产生这样按规工作的行为。大家可能真的会一板一眼地按照方法学里写的来，工作就会被拖延到几乎停滞。 ### 鸡和鸡蛋 大多数方法学声称的好处实际是方法收敛的好处。在一定程度上，不同的人做同样的工作，若运用相同的方法且运用得当，确实存在一些优势。维护人员能够更快定位新产品问题，开发人员能够在新项目上加快上手速度，度量数据在不同项目上保持一致，各种缺陷也更容易被发现。方法收敛是一件好事情，但它并非唯一能达到收敛的途径。方法学通过制定法规来强制收敛，这就带来了不可避免的副作用，一边是维法者强力的推进，一边是脑力劳动者强烈的自主意识，毕竟，牛仔精神在新兴领域可是随处可见的。更好地达到收敛的途径包括： 培训：人们做他们知道该如何做的事。倘若你让他们知道方法的核心，他们就会去尝试使用。 工具：一些建模、设计、实现或测试的自动化工具能够让你得到比法规更多的方法上的收敛。 同行评审：在执行了有效同行评审机制的组织里（质量管理、走查、验收、技术研讨），自然就会有收敛的趋势。 只有当这种自然引导的收敛完成后，你才能去想着发布一个标准。在没有形成事实上的标准之前，是没有办法做声明的。例如，杜邦公司就存在对理论进行标准化的基础。在我们为这家公司提供咨询的那些年，他们的标准手册上对标准的定义是“完成一项重复任务并经过验证的方法”。手册进而解释了经过验证的含义是“在杜邦公司内部广泛并成功使用”。这对我们来说应该是常识，但这确实跟业内的普遍做法相反。业内的普遍做法是出去寻找新方法，然后在没有经过组织内任何试用的基础上，就强制为一系列标准。 ### 再论高科技假象 在工作环境中，对于大型方法学的痴迷是高科技假象的另一种表现。这来源于对技术的崇拜，相信只有技术才真正具有意义。即便是臆想出来的最完美的方法学，它为每一项活动都制定了正确的方法，也只能在科技上提供很小的帮助。即使完全没有指导，大家也不会总是做出错误的决定。无论什么样的技术优势，这一做法都会付出团队社会环境显著恶化的代价。 相反的做法是为每一种新措施实施一个试点项目。在试点项目里，不需要遵循已有的标准，并且团队不能用以前的标准方法来完成工作。标准要求至少工作部分的内容要采用非标准的方式开展。（例如，这在富士公司的一些部门似乎是不成文的规定。） 1932 年春，效率专家在霍桑西部电子公司进行了一系列实验来确定各种环境参数对生产力的影响。他们尝试了增加照明亮度，发现生产力有所上升。然后他们调低了照明，发现生产力还在提高。他们感觉如果把灯全部关掉，可能生产力会一飞冲天。这里出现的情况在于改变本身可能并没有响应改变重要。大家渴望差异化，希望被关注，被新兴事物吸引。这个被总结为后来的霍桑效应。简单讲，就是说人们在尝试新事物的时候表现会更好。 针对生产力提升的相关论文做一个案例分析，你就会发现所有的生产力提升都源自于霍桑效应：毫不例外，当一篇鼓吹 X 方法能提升生产力优势的论文会在刚开始引入 X 时被报道。你大概从来不会听到研究分析 10 年前所做的“改进”是否还有价值，它们很可能已经没有价值了：这或许有点玩世不恭．但我们对所有生产力提升都来自于霍桑效应这一观点深表赞同。 为了让霍桑效应能够发挥作用，你不得不对法规采取非标准化。不管什么标准，实施时都应该简单而温和。加在你员工身上的所有标准加起来不应该超过 IO 页纸。（这不是白日梦；很多放弃了方法学规范的组织，到最后就是 10 页的标准规范。） 即使在这样的松散指导下，你还是应该准备好为特例让路。只有这样做，你才能创造出一个百花齐放、百家争鸣的开发环境。 当年毛主席在提出“百花齐放、百家争鸣”时可能并非真是这个意思，但我们坚信这一点。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.shiker.tech/ren-jian/di-wu-bu-fen-wo-tu/29-zi-wo-yu-fu-xi-tong.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.