精益产品与流程开发》连载十一
第三章 观察开发活动中的浪费（2/4）
散乱失序（Scatter）
时间都花费到哪里去了？为什么看起来，总是不能在正确的时间知道我们需要知道的知识？为什么研究显示，大多数工程师把他们大部分的时间花在了寻找信息上？
答案正是散乱失序。
我们都很熟悉散乱失序，就是那些由于扰乱了知识有序流动的行为，其后果是导致知识的效用降低。从根本上说，散乱失序干扰了高质量的团队工作所需要的精妙互动。以下是一些开发活动中的常见情景，一些传统的反应，以及它们创造散乱失序的方式。（注意：我已经在下表的最后一列里放入了精益对于每种情景的反应。如果这里的某些主意让你觉得不合理，或者难以理解，请不用担心。你将会在后面学习到这些内容，所以我暂时也不对它们进行深入的讨论。）
情景 传统的反应 散乱失序效应 精益的反应
1 . 进展状况比较糟糕 重新组织 阻断了互动的知识 找寻根本原因
2 . 项目落后于计划 增加更多的开发人员到团队中 打乱了原有的沟通秩序 主管人员定期介入
3 . 采购人员在寻找供应商方面较慢 更频繁地给采购人员打电话 分散了采购人员的精力 找寻和解决根本原因
4 . 开发的产品总是存在失效的情况 在开发流程中增加更多的任务和检查环节 分散了开发人员的精力 发现和解决根本原因
5 . 客户想要一些新东西 增加一个很匆忙的开发项目 使资源处于超负荷状态，制造了更多失效的可能 平稳、有节拍地创新
6 . 在制造系统方面存在问题 让制造工程师一直待在项目里，直到系统能够妥善运行 下一个项目得不到制造工程师，问题重复出现 以多套方案为基础的并行工程，实行人员从工厂到开发团队的轮换
对上表的一些详细解释：
1．重新组织要求相关人员学习新工作的特殊要求。更为重要的是，这使得他们需要重新了解沟通的关系网络，理解如何与整个系统相适应，并重新创造共同工作的实际流程（而这往往和官方流程有所出入）。（当然，组织变革有时是需要的，但是传统组织高估了其益处，却过低估计了其成本，原因在于他们并没有意识到变革对知识流动秩序的干扰性影响。）
2．增加更多的开发人员到一个团队中，通常会使进展更缓慢，因为新的开发人员无法快速、有效地融入到团队的交流和沟通中来。
3．通过干扰别人能够获得更快的回应？对于干扰者来说是如此，但对于其他人来说，回应会变得更慢。因为放下一个工作去做另一个工作,将会降低效率。工作负荷的波动和对快速反应的需求（例如，未经计划地在不同活动之间转换，重新确定优先次序等）,会给组织和个人带来干扰。物料在错误的地方搁置起来；灵感和数据丢失了；人们总是感到愤怒和疲惫。
4．给已经超负荷工作的开发人员增加更多工作，只是意味着更多的工作将会落后，或者开发工作将需要花费更长的时间。既然每个开发项目都是独特的，增加那些在之前项目中曾经有助于避免缺陷的任务，也许在下一个项目中并不奏效，于是，增加出来的任务变成了干扰。
5．不定期地增加项目，会导致工作环境的显著波动。在上次工作中适用的知识需求，在这一次工作中会失效，于是工作人员不得不追寻知识、变更优先次序、超负荷运转，并花费更多的时间来追赶进度。整个项目的产出下降；而且，因为落后于竞争对手，会有更多的项目被增加出来，项目的需求会进一步上升。
6．产品正式发布投产后，制造工程师仍一直留在项目中，意味他们无法参加到下一个项目中。这样，下一个项目由于缺少制造工程师的支持，可能也会遭遇相似的损失。
散乱失序效应往往是个死结，是个使事情变得越来越糟糕的恶性循环。当由于组织混乱而造成“事情落后于预期”时，开发人员需要花更多的时间用于“救火”，回应其他人的信息需求，自己也要寻找信息，还要打扰其他开发人员以请求回应。所有的事情都因此而变得一团糟。
既然没有什么事情能按计划进行，高级经理们就努力用各种手段企图控制局面，比如重组，施加强制的规则，要求更多的汇报、任务以及对问题立即作出解释等。因为没有什么事能够保持稳定足够长时间，以等得到实际结果方面出现积极的反馈，所以，人们不得不花更多时间，做各种样的事情，以使得事情看起来好些——作更多详尽的演讲和产生更多详尽的、解决问题的想法。最糟糕的是，那些在混乱环境里最成功的人自然而然地被提升到了权力的高位，在这些位置上，他们同样会鼓励他人也按照自己的“成功模式”去做事。
由此而来，结果就是公司变得更散乱失序，更多的时间被用来创造浪费，更少的时间被用来创造价值。
动手做：停止增加散乱失序
很多散乱失序是由直接的管理行动导致的，你可以什么也不做，就立刻减少它！
举例来说：
- 停止重组；
- 减少突然通知下属，要求信息；
- 对“起火”作出干扰最少、但有效的反应。如果“扑火”是某人的工作的话，让他去做就可以了；
- 停止发送和回复大量的电子邮件或者语音邮件；
- 增加项目的时候要反复思量；
- 停止对你的开发流程增加正式的结构（任务、检查和报告）。
散乱失序导致的大麻烦，是丧失了能真正使得机器和公司成功的微妙互动。大多数单个的工程任务，相对而言是直线型的。任何具有扎实工程资质的人都能阅读一本书（或者一张权衡曲线表），并照着做。但是对于一个职位的新人来说，他可能并不了解整个系统中微妙的人员与技术互动，对它的整合也难有贡献。举例来说，阿布拉姆斯M1坦克设计团队的成员们告诉我，项目中只有两名成员曾经参与过坦克设计。毫无疑问，坦克的每个子系统都是技术上的奇迹，阿布拉姆斯是世界上速度最快、武器装备最好和最致命的坦克。但它作为一个系统而言则问题重重：过于笨重了，而不能轻松操控；经常性地发生故障，而且维修起来非常昂贵；令人难以置信的高油耗。
通常，散乱失序效应的一个根本成因是传统的管理假设——我们能够通过程序手册、组织结构图和管理指令创造出组织结构（秩序）。实际上，组织里的非正式架构（诸如社交网络、行为模式以及规范）是组织运转中同样重要甚至更为重要的一部分。[ 要了解关于正式和非正式组织结构的更多学术研究成果的彻底总结，参见W. Richard Scott and Gerald F. Davis, Organizations and Organizing: Rational, Natural and Open Systems Perspectives, Upper Saddle River, NJ: Pearson Prentice Hall, 2007; 尤其是第2、3和6章。]秩序必须通过人与人之间的互动才能出现，而这需要花些时间。
散乱失序有两种重要的、与之相关的浪费：沟通障碍和对不良工具的运用。
沟通障碍
沟通障碍直接阻止了知识的流动，它们包括：
- 实体障碍，诸如距离、不兼容的计算机格式等。
- 社会障碍，诸如公司里的“等级系统”和阻碍沟通的管理行为。
- 技能障碍，诸如人们不知道如何将数据转换成为可用的知识。
- 信息通道。
这里是一些详细的解释：
实体障碍从不兼容的计算机格式开始，最显著的障碍需要最具技术性的解决办法，而且没有永久的解决办法，起码在行业里对开放标准的承诺变成现实之前是没有的。我们可能还会增加人的语言和纯粹的地理距离造成的障碍。许多公司目前正在因为追求更低的工程人员成本而将开发活动转移到海外，而这样加剧了这两大问题。社会障碍使得大部分公司浪费了机械安装修理工、技术员和生产作业员的经验，因为拥有大学学位的人不知道如何听取他们的意见。（我曾经说过，与大学教授讨论，许多时候并没有让自己学到什么。这曾让我的大学同事不高兴。但是我从来没有拜访一个机械车间后一无所获的感觉。）正式的规则，或者非正式的态度，使得工程师远离生产车间或者工厂，而操作员和机械修理工则远离工程活动。类似地，在很多公司里，最好的工程师的时间都花在搬运纸头文件、坐在会议室里开会，以及传递来自于一线工作的工程师的信息。因为他们现在是“经理”，而不再是工程师了。他们的知识会快速退化。而且许多公司对于报告坏消息持惩罚的态度，所以人们不愿意报告坏消息。“不是在这里发明的”综合症，经常阻止外面的知识进来。
通常，有资历的机械工程师对几何的描述缺少技能和工具，所以他们用语言解释给CAD操作员。他们不知道如何将知识转换成为简单的文字和图画形式，因此，会议成倍地增加。
信息的传递需要通道，典型的情况是以纸的形式。这样，来自于打字机和复写纸的剩余物，产生了来源于同样数据的重复、迟到，甚至相互冲突的副本。
动手做：开始打破沟通的障碍
问问任何跨职能的开发小组，“是什么使我们不能在正确的地点、正确的时间获得正确的知识？”你将会得到比自己以为的更多意见。实施一些快速而简单的解决办法，但记得要回过头来向这个小组通报你是否采取了行动。
为了减少距离障碍，在你的客户所在地进行设计和建造。为了减少社会障碍，让每个人每个季度在工厂里工作一天。教导工程师们如何画草图，将CAD作为一项工具，而非一种职业，提供给工程师们。用电子化的知识库替代原来的信息流通渠道，使得人们能够按照需要从中提取知识。不良的工具
为什么某些公司的开发流程看起来最为细致而详尽，开发方面的麻烦却最多？部分原因是由于，这些书面流程要求开发人员使用没有效率的技术。我们在这里需要做些根本原分析。毕竟，这些流程通常是由有经验的开发人员制定的，其中的大部分步骤是为了防止一些灾难再次发生。为什么开发人员受到这么多细致的规矩限制，而经理们仍激烈地抱怨问题不断地出现呢？
传统公司发现，“对于只有一把锤子的开发人员，任何事情看起来都像一个钉子。”问题越多，就有越多的标准任务。不久，人们开始图方便，例如，照抄旧的FMEA（失败模式和效果分析），运用有限元模型不是为了理解应力的分布，而只是为了得到一个强度数据，甚至捏造商业事实。于是，更多的失败产生了。管理层开始感到很受挫折，要求实施更多的交叉检查、报告和任务。开发人员忙得更加苦不堪言。这时，开发流程已经进入一个死结状态：他们越是“改进”这个流程，失败得就越惨。
下一步，传统公司试图从流程中消除一些任务。而大灾难也就接踵而来，因为这些任务是基于一定的原因而被加上去的。举个例子，NASA（美国航天局）以“更廉价、更小、更好”为目标的一系列项目，导致了一系列可怕的失败。
这就是为什么，每次我想要和丰田的开发人员确认到一个标准的流程时，他们总是说“一事一议”的原因。针对已知的问题，丰田人设计出一套通过权衡曲线（我们将在第六章里讨论）来保存已获取到的知识的方法，而同时预计到新的问题仍会出现，需要不断开发与之相适应的新的分析和测试方法。丰田只是将最少量的预计到的知识加以标准化，然后要求人们保持学习的态度。
在下面的几章里，我们将要一些核心的精益开发实践方法，它们将使你能够达成一个有条不紊的、有效的流程，而同时允许（实际上是要求）开发人员去根据具体情况，逐个决定可以用哪种最有效率的途径来创造知识。这里有几个例子：
- 建立对结果的清晰责任，而不是流程跟进，建立起流动和拉动的管理。然后，你就能承受让你那些原本看来详尽的流程在开发人员的庆祝声中消失。
- 教导开发人员如何将数据转换成为可以再次使用的知识。要求他们努力通过设计来阻止问题的发生，而不仅仅是通过仿真或测试来发现问题。
- 通过价值聚焦来指导大家进行标准化，最基本的规则是，每个人都有责任按照有效的方式来工作。
在此期间，运用第52-53页上的流程图来挖掘你的流程，以获得有用的信息，同时鼓励开发人员承担起运用最好的工具获取所需信息的责任。为了说明如何运用流程图，我们将用它来分析和改进传统开发中的一个标准工具——失败模式和效果分析（FMEA）。丰田很少运用正式的FMEA。相对应地，它建立了围绕权衡曲线表的开发流程，权衡曲线表回答了我们定义的问题。你可以运用同样的分析流程，去识别和消除你的流程中各种由不良工具带来的浪费。
我希望你正开始看到，散乱失序和与其相联系的浪费（沟通障碍和不良工具的运用）源于按照传统思维“正确地做事”。当我们向前看到更多的浪费时，你将看到同样的情况。
动手做：开始消除浪费
通过举办一些研讨会和运用流程图，着手开始消除开发流程中那些浪费的步骤和工具。这是一个好方法，帮助你的开发人员将注意力集中在将要获取的知识，而不是完成等待检查的任务。你将看到立竿见影的好处，以及对精益更有自信。
从当前存在的程序中探寻能增值的矿藏[这一页必须和下一页排版在相对的两页。]
右页的流程图可以被用来评估当前存在的程序，来看看它们对开发活动增加的价值。我们将使用FMEA作为案例来说明。从最左上方开始，FMEA回答以下问题：
1.产品或流程会如何失败？
2.每种失败的概率是多少？
3.后果会有多严重？
4.有什么计划来阻止或检测可能的失败？
5.（在某些公司）产品失败的概率和后果是否低于一个关键的风险水平？如果不是的话，那么开发团队不能通过“门评估”。
回答这些问题是否会增加可用的知识？是的，回答第1到4个问题会增加。但是第5个问题，如果将FMEA用来评估团队的绩效，看起来更像是“舍本逐末”（bend the needle），破坏了有用的信息。
对于问题5沿着“否”的箭头向右移动，我们意识到，这个问题的用意是再次向管理层保证，“产品和流程是安全的”。管理层需要学习如何更直接地评估产品的安全性，办法是，盯住部件和绩效数据，问工程师们他们如何确保自身所做的那部分工作是安全的。
现在，继续看表的其余部分，也就是第1到第4个问题。它们是否是最重要的问题？第1个显然是。但是失败的概率和确切的后果？只有当我们是为失败而设计时才是重要的！
更重要的问题是：
什么导致了失败？
在什么条件下，产品会失败？
什么样的设计条件可以防止失败？
这些问题引导我们去寻找一个更好的，而且不会失败的设计方法。对这些问题，获得准确的答案会容易很多，因为估计失败的概率是非常困难的，部分原因是，对于一个良好设计的产品来说，失败概率是如此之低。墨菲法则（Murphy’s law）则显得更容易和更安全——任何可能出错的事物都会出错——因此，要努力设计那些不会出错的东西。
