有些工程师喜欢做一些没完没了的优化，对于这种情况甚至有一种说法：“干掉工程师后，才能发布产品。”
创新的产品并不比旧产品更加盈利。（在一个实际案例中，经理问道：“旧的控制电路已经满足客户的要求了，为什么你还要设计一个新的？”工程师回答：“我已经设计过那个旧的了。”）
减少无用信息的浪费
开始的一些步骤是比较容易的。只需要：
问问开发人员，他们被要求提供哪些无用的信息？
应用在讨论散乱失序浪费的流程图中，取消并替代那些无用的信息。
引入新的管理概念和系统，发挥效应，这是最难的一部分。
等待
许多公司曾经发生过这样的情况：产品线出现了太多的问题，以至于不得不加快运转。于是他们组建一支精干的团队，让他们放下各自手头的工作，将他们搬到同一个地点，无须遵照标准流程行事。毫无疑问，这个团队的速度会是平日的两倍。但这些公司发现，他们很难重复这些流程。一旦重新强调遵循标准流程时，进展就会变慢。然而我们知道，丰田确实遵循一套标准流程，并没有将所有人搬到一起，或者是让开发人员仅专注于某个项目，但每个项目上丰田都能以两倍的速度进行。为什么？
向交接脱节的浪费开战（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％，尽管丰田总体上在计算机仿真方面的能力落后于美国公司。举个例子，丰田对原型车不�