【产品与流程开发】（十三）知识浪费之三“主观臆测”

《精益产品与流程开发》（第二版）连载十三

第三章：观察开发活动中的浪费（4/4）
主观臆测（Wishful Thinking）

到这里，我们已经考察了导致创造价值时间流失的大部分浪费——散乱失序和交接脱节。这些浪费还造成了许多有缺陷的项目。散乱失序会引起缺陷，是因为正确的知识没有被放在正确的地方。交接脱节也会引起缺陷，因为做决策的人和做工作的人并没有所需要的知识。但是，还有另外一个主要的导致缺陷项目的来源。为什么大多数项目都超出了资金和时间预算呢？为什么大多数公司在从产品制造开始到全速量产的过程中会遇到如此多的麻烦呢？

答案是主观臆测！

主观臆测指的是由没有充分的数据就做决策，或者是盲目地工作。按照传统开发模式来运转，实际上需要主观臆测。让我们来看看为什么是这样。

传统开发往往从确定规格或者设定开发需求开始。然而，所有的规格都是客户实际需要和自然规律允许情况之间的一种妥协。项目开始之初，客户不知道他们想要什么，开发人员也不知道自然规律允许什么，除非基于旧的数据。所以，项目开始时就设定规格的做法是种主观臆测，这样常常会导致丧失市场机会，成本过高，或产生严重的质量问题。

下图是由我喜欢的一位MIT（麻省理工学院）教授画的传统开发流程。该流程中，开发团队很快就选择了一个单一的设计概念方案，将其详细化，努力证明该方案的可行性，当该方案无法满足要求的时候，就进行修改。这意味着，项目最关键的决策——基本概念设计方案的确定，不得不在没有很多数据的时候就仓促作出。

图：传统的开发过程（第61页）自左至右：确定规格，概念设计，选择一个方案，详细设计（对子系统重复这个过程，然后装配），改进，分析和测试，对制造系统重复这个过程

开发团队也许永远不能弄明白自己所选的概念设计方案是否是最好的；只能在项目结束时才看到这个概念设计方案是否足够好。而往往，事与愿违，选择的这个概念设计方案并不够好，团队不得不匆忙地尝试其他备选方案，在可能的最糟糕情况下，会导致成本增加，质量遭受了妥协，时间也超过了计划。之所以这样，是因为它是一个机遇主观臆测的开发流程。

“瀑布”和“V”型开发流程首先设计整个系统，冻结子系统之间的界面，然后再设计它的子系统。在设计过程中，它们采取的是自上而下的做法；在测试过程中，它们采取的是自下而上的做法。这虽使得独立的子系统设计成为可能，但是也意味着，与子系统间界面有关的关键系统决策，是在关于何为可能的旧数据基础之上做出的。结果，设计方案通常是扭曲的，一些子系统设计太过保守，而另一些子系统却不够可靠。它们经常使得部件或制造系统再利用的机会不大。

许多人看起来不喜欢不确定性，经常作出一些不成熟的决策以减少不确定性。丰田公司的一位高级经理说过，“我的工作是防止人们太快作出决策。”进一步说，人性的本能是寻找一个更廉价、更简单和更快速的方案，而不是寻找多个备选方案。这通常是错误的，因为早期寻找多个备选方案，通常比后期再寻找少数几个备选方案，要来得便宜。而如果在只有很少的知识时就仓促地决定选择一个备选方案，那只是一厢情愿（主观臆测）的行为。

很多传统公司通过投标程序选择供应商，这种做法要求先公布规格，如果不是图纸的话。因此，这就很难发现供应商的实际能力，也就不知晓到底什么样的系统设计和部件规格是真正可行的。它还在报价承诺的基础上作出选择决策。根据我的经验，依赖承诺是种主观臆测的事。如果供应商在亏钱，他们会找到一种摆脱困境的办法，通常是通过工程变更来要求就合同再次谈判。

但是许多人太难被说服了：“永远都没有时间一次做对，总是有时间从头再来”。

这样，我们可以看到，传统开发方法对于开发团队部分，实际上要求主观臆测式的思维，而主观臆测导致了许多以糟糕决策形式表现出来的主观臆测浪费。主观臆测的两种特别的形式是：限于规格参数的测试；废弃掉的知识。

动手做：向主观臆测出击

●  在你的流程图上标注出“主观臆测”的地方，然后在大厅里贴出来。

●  任何时候当有人告诉你说某个问题是由X原因导致的，你就问他，“你还考虑了其他什么可能的原因，你收集了什么数据来排除掉它们？”

●  任何时候当有人说，“我将要执行A方案”时，你就问他，“你还考虑了哪些其他的方案，你收集了哪些数据去排除掉它们？”

●   分析过去发生的缺陷项目，尝试估计对公司来说的主观臆测的成本，公布出来。

●   一旦可能的话，尽快实施以多套方案为基础的并行工程，使用第六章里讨论的“问题解决表”来培训。

1限于规格参数的测试为什么在开发过程中，你要对产品进行测试呢？为了确保它们已经满足了规格参数的要求，准备好可以投放市场了？这是标准的传统做法，也是主观臆测。

按规格参数进行测试，并不能表明产品已经做好准备、可以投放市场了。为什么？从统计学上讲，有限的测试永远不可能确保产品能满足现代的质量需求。万分之一的缺陷经常会毁灭掉一个产品，但是你不可能拿一万个样品就每一种可能的失败模式进行测试。经过限于规格参数的测试，那些获得通过的设计方案仍有可能正面临失败的深渊。

精益公司的测试主要是为了发现失败点——而设计是为了远离失败。失败点在权衡曲线上记录下来（在第六章里会有更多讨论），这将指导整个设计。

这样做极大地降低了成本。据说，在20世纪晚期，丰田公司建造的全尺寸产品原型数量要比美国竞争对手少70%到90%，尽管丰田总体上在计算机仿真方面的能力落后于美国公司。丰田对原型车不做寿命测试；可以使用实际生产车辆的数据来完善权衡曲线，来满足寿命测试的需要，而车辆本身已经按照足够的寿命进行设计了。

按规格参数进行测试的做法，降低了测试小组的有效性。一支福特的团队开发了一套汽车门的硬件控制系统（门锁，窗调整器，镜调整器），将用于福特和马自达的车上。这个系统经过为期三周的福特标准测试，发现了15处毛病。马自达将该产品送到一名测试工程师那里，该工程师撇开测试流程，进行了严格的试验，花了三天时间就发现了30个以上的毛病。

测试工作的目的是去使产品发生故障，记录它是如何发生故障的，以及建议设计工程师如何使它更坚固难以发生故障。测试工程师需要保持独立性、创造性和严格性。让产品工程师来定义测试的标准，就像将一只狐狸放进鸡窝里一样。

动手做：严格测试，直到产品失效

告诉你的测试部门去发现和记录产品运行绩效的极限，为设计改进提供建议。如果客户要求按规格参数测试，没关系，根据规格参数的上限进行测试，然后继续测试，直到这个产品发生故障，让你知道产品的极限。此外，你的客户实际上未来很可能会更改对规格参数的要求。

2废弃的知识

最后，在产品制造发布之后，对于你在开发过程中获取的知识，你将如何处理？

看起来，大多数公司在项目接近结束的时候，会常规性地执行某种项目评审，来反省一下哪些事情进展顺利，哪些不顺利，以及下一次该做哪些调整。当被问到对于这些反省结果他们会做些什么时，他们回答道，讨论中的重点内容（要点）会被用某种通用的办公软件产品加以记录，放到项目文档里一并保管，通常是放在某个文件共享点上。开发团队“希望”有人可以在未来的项目中使用到它们的学习成果，但实际情况下，一个又一个项目的事后审核都大抵相同。换句话说，很少的知识真正被在不同的项目之间转移。

努力形成文档并予以保存，这是另一种主观臆测的形式，如果该信息被保存在那里却永远没有被再次使用，那么创造这份文档的过程就是浪费。对于其他类型的项目文档，诸如分析、仿真和测试报告，也存在相似的现象。它们通常被是被做成报告，然后保存在某个角落里——很多情况下，从来没有被另一个人读过。那种关于未来的开发人员会使用这份报告的希望，就任何实际的目的而言，都是主观臆测。

使用测试数据来创建可以再使用的知识

许多年里，高尔夫俱乐部用品制造商PING的分析和测试小组都在产生测试报告。公司累积了数以千计的“测试报告”，放在文件柜里，通常只被大概地阅读过一遍，很少会被再次阅读。既然这些报告基本上反应的是单“点”结果，也就是说根据被要求的测试项目而做的测试，报告中的信息对未来也只有非常小的用处，因为知识与之前的结果之间没有特别的联系。

最近，PING取得了显著的进展，他们从过去的诸多测试报告中归纳有用的知识，并在当前的测试中包括进比较的数据。工程师们发现，这种类型的数据“有了上下文”，变得有用得多。事实上，对这些标杆比较数据的不断维护一直被继续着，无需高管人员的督促，因为大家发现，这些信息是如此地有价值。

也就是说将它们最为宝贵的财富丢弃掉了？这里是几种可能的原因：

●  传统团队（及其主管人员）关注的是将产品推上市场，而获取知识并不在他们的优先任务清单上。

●  个人通常会被立刻派到下一个项目中去，没有足够的时间来反省和归纳他们产生出的技术或客户方面的知识。

●  按规格进行测试的做法，不能提供多少下次还有用的信息。

●  特别是，很少有工程师知道如何将数据转变成有用的知识，以一种对未来开发项目可以据以行动和有用的形式。

图（原书第66页）：废弃掉的知识 （知识）

动手做：估算目前被废弃掉的知识

试着估算流失知识的成本。工程师们将多少时间花在重新创造那些已被开发出来至少一次的知识？将结果公布出来。

教大家使用权衡曲线表方法（在第六章会进一步讨论）。

使频繁地检查权衡曲线表成为所有部门领导者的一项高优先级工作。

时间进度图有助于观察浪费

你如何才能够“观察”开发流程？“看见”（Seeing）是非常重要的，因为大脑约有一半都用来处理目视化的信息。人对于目视化的信息理解得更好。对流程观察得越好，你就能越好地发现浪费。

我推荐使用资源消耗的时间进度图，就像下面这个例子里的样子。你可以对一个典型的完整开发流程来运用这一工具，也可以对流程的一部分运用，例如建造原型。

横轴代表项目朝着正式发布（或者某种其他方便的目标）进展的时间，还有一些超出目标时间点。运用任何方便的刻度单位，从小时到年。

纵轴代表花费的努力。典型情况下，这里的单位是以相当于全职员工的工作量（full-time equivalent, FTE）表达。两个人每人分别花1/2时间在一个项目上，就是一个FTE。

如果你已经有了某种用框框和箭头绘制的流程图（例如，关键路径图、工序流程图或者价值流图），那么运用它们去分析你现有系统中的各种浪费。然而，你需要确保自己理解与那些图表分析方法相联系的问题：

●  它们没有显示资源负荷信息，因此无法帮你实现均衡负荷或规划资源的功能。

●  它们强迫你使用顺序式思维方式，即一个在前一个在后的次序，不能反映开发活动实际进行的方式。实际上，顺序式思维正是我们想要努力消除的。

●  它们强迫你采用通道化的思考方式，这个人得与那个人沟通，这一点也是我们想要消除的（在我们提倡的拉动系统中，知识是随处可得的）。

一旦你有了一张图表，你就可以用它来识别浪费的来源。例如，对于交接脱节浪费：

●  预先研制后的交接脱节，因为预先研制选择了概念设计方案，然后概念设计方案必须由产品开发团队来执行；

●  销售和规格确定之后的交接脱节，因为产品开发团队被期望执行由建议团队决定的规格；
●  产品开发和制造开发之间的交接脱节，因为制造工程必须实施产品开发确定的设计方案；
●  制造工程和工厂之间的脱节，因为工厂必须使用制造工程设计的系统。

你也可以用类似的方式，将主观臆测在图上标注出来：

●  预先研制在有证据表明它盈利之前，就选择了一个基本的开发概念方案。
●  销售部门在有证据表明顾客的规格是可以实现的之前，就接受了它。
●  产品开发部门在有证明表明它是可以制造出来的之前，就选择了一个产品设计方案。

你是否能观察到由于工作负荷变化而导致的散乱失序？组织的不同部分看到他们花在这个项目上的工作负荷波峰。这意味着，他们不得不努力跟上自己在多个不同项目中的工作进度要求，如果一个项目没有跟上，干扰就可能没完没了。你可以通过在时间进度图上工作负荷发生剧烈变化的点上放上一个星星或者爆炸云的标志，来展示这一点。

动手做：画出你的流程，识别浪费

你可以画出：

●  一个实例项目。

●  一个产品系列的一个通用流程。

●  流程的一部分，例如一个工程更改流程，或者一个“模型和仿真”流程。

根据你对某些流程的了解，画出一个时间进度图。像“工程更改”这样的小规模流程，往往也包括了很多散乱失序，体现为通道化的知识流动等等。在图上把它标注出来。

在你学到更多浪费的时候，可以逐步在图上标出来，尤其是交接脱节、等待以及主观臆测等。

之后，在其他的图表也做出标注。将图表挂在各个部门里，公布出来；用它们去激发变革。

到此学到的经验教训

你都学到了哪些需要付诸实践的知识呢？在第二章，你学到了如何评估开发系统的绩效，如：考察项目的ROI；缺陷项目的比率；开发人员花在增加价值活动上的时间比例；学习的比率，包括从机会出现到形成成功产品的过程时间。

在第三章里你学习到，如何对以三种形式的浪费表现出的糟糕绩效，寻找它们背后的根本原因：

1) 散乱失序：诸如组织重组和工作负荷波动等的管理行为，会导致知识难以正常流到正确的地方去；沟通的障碍，如使用多种形式（书面的，或电子的）在不同沟通渠道中传递信息；不良的工具，大多数情况它产生的信息可能有助于预防过去发生的问题，但不能有效地预防未来会发生的问题。

2) 交接脱节：最关键的浪费，当公司将责任、知识、行动和反馈分割开来，就会发生；无用的信息，通常是为了向管理层表明“在控制之中”而产生；等待，将学习变成批量性的做法，以至于知识只能按一个方向流动。

3) 主观臆测：没有数据就作出决策；按照规格进行测试，可能会使产品存在风险，可能会忽视发生概率很小的问题；废弃掉的知识，未能将在一个项目中学到的所有知识转换成为可用形式的浪费。

你学习到了观察传统管理实践中导致这些浪费的原因，尤其是科学管理，和用方框箭头式流程图方法来计划和掌控项目。你学习了如何将流程绘制出来，以使得浪费更加显而易见。

另外，你还有一个很长的清单，列出了接下来要完成的事情。大部分任务的用意在于为公司现状提供一幅更清晰的图景：公司现在何处。需要强调这有多么重要！一个人可以通过拿着一面镜子让组织更清楚地看清它自己，而改变整个组织。要保持政治上的理性，要讲究策略。但是要保持清晰、有力和积极的进取，抓住每个机会去总结优化和沟通关于正在发生什么的图景。当人们看到有那么多浪费，看到公司与其潜力相比表现得有多差时，你可能会构建出大家对公司现状的不满感。这种不满如果能与对未来的愿景结合起来，将促使你的公司向前进。

所以，去实践“动手做”清单上的事情吧。着手激励你自己的公司变革吧。继续阅读接下来的章节，它将帮助你描绘自己未来行动的图景。

欢迎关注下期连载十四，我们将介绍第四章“展望未来精益开发系统”