销售部门、高级经理或者报价团队定下合同，而项目经理和其他团队成员必须执行它。
经理们为开发团队制定决策（如要达到什么样的规格）。
无用的信息
时间花到哪里去了？为什么开发人员花费到增值活动中的时间只有20％？
由于散乱失序，许多时间被花在寻找有用的信息上。更多的时间则由于交接脱节，而用于制造、寻找和接受无用的信息。
如果某条信息不能有助于对客户的了解或者其他集成工作，不能有助于创新，或者不能为一个好的决策提供基础，那么它就是无用的。无用的信息不能帮助改进营运价值流，但会被创造出来，是因为有人想要它。
交接脱节常常会引起无用信息的产生。开发人员拥有知识，实施具体的工作。经理们有责任，并需要信息以控制局面。一旦出现问题，经理们需要更多的信息。很多开发工作的目的反倒产生了那些无用的信息，目的只是使经理们相信局面仍在掌控之中，同时避免或转移可能的指责。
此类无用的信息有一些例子：
大多数以PPT形式做的演示报告。
进程报告：开发人员庄严地宣称，他们正在按照计划进度工作。
完全形式主义的FMEA（失败模式和效果分析），没有产生出新的知识。
还有一些无用信息的产生，是因为某些工作人员的喜好，而不是为了公司的盈利。例如：
有些工程师喜欢做一些没完没了的优化，对于这种情况甚至有一种说法：“干掉工程师后，才能发布产品。”
创新的产品并不比旧产品更加盈利。（在一个实际案例中，经理问道：“旧的控制电路已经满足客户的要求了，为什么你还要设计一个新的？”工程师回答：“我已经设计过那个旧的了。”）
减少无用信息的浪费
开始的一些步骤是比较容易的。只需要：
问问开发人员，他们被要求提供哪些无用的信息？
应用在讨论散乱失序浪费的流程图中，取消并替代那些无用的信息。
引入新的管理概念和系统，发挥效应，这是最难的一部分。
等待
许多公司曾经发生过这样的情况：产品线出现了太多的问题，以至于不得不加快运转。于是他们组建一支精干的团队，让他们放下各自手头的工作，将他们搬到同一个地点，无须遵照标准流程行事。毫无疑问，这个团队的速度会是平日的两倍。但这些公司发现，他们很难重复这些流程。一旦重新强调遵循标准流程时，进展就会变慢。然而我们知道，丰田确实遵循一套标准流程，并没有将所有人搬到一起，或者是让开发人员仅专注于某个项目，但每个项目上丰田都能以两倍的速度进行。为什么？
向交接脱节的浪费开战（2）
因为传统的项目计划、组织和控制方法——计划评审技术（program evaluation and review technique；PERT）、关键路径图（甚至有时被修改为“关键链”方法）和分阶段实施——引起了等待的浪费。顺序化的思维——在项目启动之前先完成——是PERT的关键所在！所以，即使并行工程的口号已经喊了十年，为公司带来的好处也相对有限，最重要的原因就是，PERT工具原本就与并行工程的目标相违背！
顺序化的思维在产品开发工作中并不重要！很难发现开发活动的上游工作非得在下游工作开始前完成不可（而下游工序往往不能在上游工序结束之前完成，但这又能说明什么问题？）这正是产品开发和制造之间一个重要的区别，也是开发和建筑之间的重要差别。而PERT图之类的方法，原本是为类似于建筑工程的项目管理而设计的工具。
顺序化的思维创造了一个批量的流程，规定一个特定产品的决策和学习都必须在某一段时间里同时发生。这导致：
减慢了流程的速度，因为在开始行动前等待的时间比需要的长。
创造了单方向而不是多方向的信息流动：上游工序不能从下游工序得到足够的信息。
上游工序的开发人员比下游工序的开发人员拥有更多的权力，导致了质量问题。
引起工作负荷的大幅波动，从而导致了散乱失序的浪费。
例如（结合图27理解）：
工程部门在设计之前必须等待产品规格确定，然而规格往往不合理，结果是要么使设计工作困难，导致成本和质量问题；要么无法在设计过程中一次完成。
制造工程部门在设计生产系统之前要等待产品设计方案完成。也就是说，产品工程师不得不按照老的制造系统的特点设计产品——在某种程度上就像为了这个制造系统而设计一样，这阻止了产品设计和制造系统设计的联合创新和优化。
在制造工程部门确定制造系统之前，工厂处于等待状态，不参与制造系统的开发工作。
流程的后期才选择供应商并参与——这阻止了产品、子系统和供应商制造系统的创新和优化。
图27传统的顺序式开发过程
对于不断变动的工作负荷，有些公司试着用任务排程的方式来管理，而有些公司甚至不去尝试。但那些任务排程的文件在墨水还没干的时候就被扔在一边。由于开发活动中有太多的不确定性，批量化的思维导致了可怕的资源冲突。
后面我们将会发现，精益开发的概念（如以多套方案为基础的并行工程以及拉动/流动计划）使得更大程度的并行工作、多方向信息流以及均衡化的资源需求成为可能。
减少等待的浪费
开始动手吧。邀请跨职能部门的同仁们一起研究。问问大家是否遇到过等待的浪费，在时间进度图上标出这些信息，问问他们为什么等待。
不幸的是，答案几乎总是“因为我非常忙，这还不算很糟糕”。你将需要拉动、流动以及节拍的工具，才能将你的公司从灾难的模式中解脱出来。
主观臆测
到这里，我们已经考察了导致非增值时间的许多浪费——散乱失序和交接脱节的浪费。这些浪费同时有可能造成许多有缺陷的产品。散乱失序，因为正确的知识没有应用在正确的地方，所以引起缺陷。交接脱节，因为做决策的人和做工作的人没有所需要的知识，也引起缺陷。但是还有另外一个主要的缺陷来源。为什么大多数项目都超出资金和时间的预算呢？为什么大多数公司在产品制造开始到全速量产的过程中会遇到如此多的麻烦呢？
向交接脱节的浪费开战（3）
这是因为主观臆测的浪费。
这种浪费是因为没有数据就做决策，传统开发的概念通常只要求估算。
确定产品性能参数是传统开发的第一步。然而，所有的性能参数都是客户需要和实际允许情况间的一种妥协。项目开始之初，客户不知道他们想要什么，开发人员也不知道实际允许什么，除非基于旧的数据。所以，项目开始时设定性能参数是主观臆测，这样常常会造成错失市场机会、成本过高或严重的质量缺陷等问题。
图28是我尊敬的一位MIT的教授画的传统流程。在该流程中，首先选定概念设计方案，将其详细化，并努力去证明方案的可行性。当无法满足要求的时候就进行修改。这意味着项目最关键的决策——基本概念设计方案的确定，不得不在没有很多数据时就拍板定案。
这个团队也许永远不能发现他们所选的概念设计方案是否恰当，只能在项目结束时看到结果，但往往事与愿违，选择的概念设计方案并不够适用，因此不得不匆忙地尝试其他备用方案。最可能的情况是成本增加了，质量必须妥协，时间也超过了计划。
图28传统的开发流程
“顺序而下”（waterfall）和“V”型开发流程首先设计整个系统，然后再设计其子系统。这种方法允许进行相对独立的子系统设计，但意味着阻碍了子系统之间的衔接。在系统设计中，关于子系统之间界面的关键决策，往往建立在旧数据的基础上。
结果，最终的设计通常是扭曲的，一些子系统过于死板，很难灵活调整，而另一些子系统又不足够稳定可靠。这样经常使得这些部件或制造系统在以后的开发中较少能够被再次利用，如图29所示。
图29V型开发流程
很多公司通过投标程序选择供应商。这意味着招标方需要首先发布产品性能参数，如果不使用图样的话，很难发现哪些供应商真正有能力做到，也不知道什么样的系统设计和部件性能参数是真正可行的，只能根据承诺——也就是报价——做出选择。根据我的经验，过于依靠承诺是一种美好的想当然的情况，也就是这里说的“主观臆测”。如果供应商实际亏钱的话，他们经常通过一些变更来要求重新谈判合同。
大多数人都不喜欢不确定性，因此经常做出一些不成熟的决策以减少不确定性。丰田公司的一位高级经理曾说过：“我的工作之一是防止员工太快地做出决策。”进一步说，人性的本能是寻找一个更廉价、更简单和更快速的方案，而不是寻找多个备用方案。这通常是错误的，因为在早期寻找多个备用方案通常比后来盯住少数几个备用方案的做法要节省经费。但是很多人不愿意相信：“永远都不会一次就完全做对，总是可能需要从头再来过。”
图210主观臆测示意图
在时间进度图（见图210）上，我们看到：
预先研制在有盈利的证据之前，就选择了一个基本的开发概念方案。
销售部门在证明顾客的性能参数是否可以实现之前，就接受了项目。
产品开发部门在有证据表明产品是可以制造出来之前，就选择了一个产品设计方案。
向主观臆测挑战
在你的流程图上标注出主观臆测，然后张贴出来。
任何时候当某人告诉你某个问题是由X导致的，你就问：“你还考虑了其他什么可能的原因？你收集了什么数据来排除其他原因？”
任何时候当某人说“我将要做A”时，你就问：“你还考虑了哪些其他方案？你收集了哪些数据去排除其他方案？”
分析过去有缺陷的项目，估计主观臆测对公司造成的成本浪费，并公布出来。
一旦可能的话，尽快实施以多套方案为基础的并行工程，用第3章里的“问题解决表”进行培训。
限于性能参数的测试
为什么在开发过程中要对产品进行测试呢？为了确保满足性能参数的要求，做好投放市场的准备。
以上是标准的传统做法，也是一种主观臆测。按性能参数进行测试，并不能证明产品已经可以投放市场了。为什么？从统计学上讲，有限的测试永远不可能确保产品的质量。万分之一的缺陷经常会毁灭一个产品，但是你不可能拿一万个样品就每一种可能的失败模式进行测试。因此通过性能参数测试的设计仍有可能会面临失败。
一个精益的开发系统主要是为了发现失败点而测试——而设计是为了远离失败。将失败点在权衡曲线上记录下来，这将指导整个设计。
这个思想大大地降低了成本。丰田公司建造的原型产品数量要比美国的竞争对手少70％～80％，尽管丰田总体上在计算机仿真方面的能力落后于美国公司。举个例子，丰田对原型车不做寿命测试，而使用权衡曲线进行完善，这时车辆本身已经有足够的证据进行设计了。这是作者在写作时的理解。
限于性能参数进行测试，降低了测试组织的有效性。福特的一支团队开发了一套用于福特和马自达车门的硬件控制系统（门锁、窗调整器、镜调整器）。这个系统通过3个星期的标准测试，发现了15处毛病。马自达派来了一个测试工程师，撇开标准的测试流程，进行了严格的测试，3天内就发现了30个以上的毛病。
测试部门的工作是去破坏产品，记录下它是如何被破坏的，同时，建议设计工程师如何使它更坚固和难以破坏。测试工程师需要保持独立性、创造性和严格性。如果让产品工程师去确定测试的要求，这种感觉就像“既是裁判员，又是运动员”。
严 格 测 试
告诉测试部门去发现和记录产品性能的极限，提出改进建议。如果客户要求按性能参数测试，没关系，根据性能参数的上限进行测试，然后继续进行测试，直到这个产品被破坏了。
废弃的知识
最后，在产品制造发布之后，你将如何处理开发过程中获取的知识？
大多数公司将它存档，然后遗忘在某个角落，这也等于将最为宝贵的财富扔掉。这有以下几种原因：
传统团队（及其主管人员）关注的是产品问世，而获取知识并不在优先任务清单上。
按性能参数测试的做法，不能告诉工程师下次是否还有效。
很少有工程师知道如何将数据转变成有用的知识。
估算目前废弃的知识
试着估算流失知识的成本。工程师们将多少时间花在寻找那些至少被开发出来一次的知识上？将结果公布出来。
教大家使用第3章里讨论的权衡曲线表。频繁地检查权衡曲线表，将它列为部门负责人的优先任务。
txt电子书分享平台
到目前为止学到的经验教训
你学到了哪些可以付诸实践的内容呢？在第1章里，你学到了如何评估你的开发系统绩效的方法，如考察项目的ROI、缺陷项目的比率、开发人员花在增值活动上的时间比例、从商机出现到成功产品发布的过程时间等。
在第2章里，你学习到如何以浪费的形式，寻找绩效不良的根源：
1） 散乱失序：诸如组织重组和工作负荷波动等的管理行为，会阻止知识流向正确的地方；沟通的障碍，如在沟通渠道中使用许多不同格式的报告；不良的工具，大多数情况下它产生的信息可能有助于预防过去已发生的问题，但不一定能有效地预防未来发生的问题。
2） 交接脱节：最关键的浪费，当公司将责任、知识、行动和反馈分割开来，就会发生；无用的信息，通常是为了向管理层表明进程在控制之中而产生；等待，将开发的学习变成批量性的，以至于知识只能按一个方向流动。
3） 主观臆测：没有数据就做出决策；按照性能参数测试，可能会使产品存在风险，可能会忽视概率很小的问题；废弃的知识，未能将项目中学到的知识转换成可用的知识。
你已经学习到如何观察传统管理实践中这些浪费产生的原因，尤其是科学管理以及使用方框箭头式的流程图去计划并管理项目。你已经学习到如何将流程绘制出来，更容易发现浪费。
另外，你需要一个很长的清单，列出接下来要完成的事情。首先要提供一个公司现状的清晰图景：公司现在何处。我认为这一步具有至高的重要性。你可以通过一面镜子让公司更清楚地看清自己，然后推动变革。要保持政治上的理性，要讲究策略。但是要保持清晰、有力和积极进取，抓住每个机会去总结、优化和沟通关于正在发生的状况。
当人们看到那么多浪费，看到公司与其潜力相比表现得有多差时，你可能对公司的现状产生不满。这种不满如果能结合对未来的愿景，将促使你的公司向前进。
所以，去实践“动手做”清单上的事情，去激励公司的变革吧。继续阅读接下来的章节，将帮助你描绘出要往何处去的愿�