友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！

让企业养成节约的习惯:精益产品和流程开发-第6部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页按键盘上的 Enter 键可回到本书目录页按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能和 "加入书签" 功能！

陷等问题。
　　图28是我尊敬的一位MIT的教授画的传统流程。在该流程中，首先选定概念设计方案，将其详细化，并努力去证明方案的可行性。当无法满足要求的时候就进行修改。这意味着项目最关键的决策——基本概念设计方案的确定，不得不在没有很多数据时就拍板定案。
　　这个团队也许永远不能发现他们所选的概念设计方案是否恰当，只能在项目结束时看到结果，但往往事与愿违，选择的概念设计方案并不够适用，因此不得不匆忙地尝试其他备用方案。最可能的情况是成本增加了，质量必须妥协，时间也超过了计划。
　　图28传统的开发流程
　　“顺序而下”（waterfall）和“V”型开发流程首先设计整个系统，然后再设计其子系统。这种方法允许进行相对独立的子系统设计，但意味着阻碍了子系统之间的衔接。在系统设计中，关于子系统之间界面的关键决策，往往建立在旧数据的基础上。
　　结果，最终的设计通常是扭曲的，一些子系统过于死板，很难灵活调整，而另一些子系统又不足够稳定可靠。这样经常使得这些部件或制造系统在以后的开发中较少能够被再次利用，如图29所示。
　　图29V型开发流程
　　很多公司通过投标程序选择供应商。这意味着招标方需要首先发布产品性能参数，如果不使用图样的话，很难发现哪些供应商真正有能力做到，也不知道什么样的系统设计和部件性能参数是真正可行的，只能根据承诺——也就是报价——做出选择。根据我的经验，过于依靠承诺是一种美好的想当然的情况，也就是这里说的“主观臆测”。如果供应商实际亏钱的话，他们经常通过一些变更来要求重新谈判合同。
　　大多数人都不喜欢不确定性，因此经常做出一些不成熟的决策以减少不确定性。丰田公司的一位高级经理曾说过：“我的工作之一是防止员工太快地做出决策。”进一步说，人性的本能是寻找一个更廉价、更简单和更快速的方案，而不是寻找多个备用方案。这通常是错误的，因为在早期寻找多个备用方案通常比后来盯住少数几个备用方案的做法要节省经费。但是很多人不愿意相信：“永远都不会一次就完全做对，总是可能需要从头再来过。”
　　图210主观臆测示意图
　　在时间进度图（见图210）上，我们看到：
　　　预先研制在有盈利的证据之前，就选择了一个基本的开发概念方案。
　　　销售部门在证明顾客的性能参数是否可以实现之前，就接受了项目。
　　　产品开发部门在有证据表明产品是可以制造出来之前，就选择了一个产品设计方案。
　　

向主观臆测挑战
在你的流程图上标注出主观臆测，然后张贴出来。
　　任何时候当某人告诉你某个问题是由X导致的，你就问：“你还考虑了其他什么可能的原因？你收集了什么数据来排除其他原因？”
　　任何时候当某人说“我将要做A”时，你就问：“你还考虑了哪些其他方案？你收集了哪些数据去排除其他方案？”
　　分析过去有缺陷的项目，估计主观臆测对公司造成的成本浪费，并公布出来。
　　一旦可能的话，尽快实施以多套方案为基础的并行工程，用第3章里的“问题解决表”进行培训。
　　限于性能参数的测试
　　为什么在开发过程中要对产品进行测试呢？为了确保满足性能参数的要求，做好投放市场的准备。
　　以上是标准的传统做法，也是一种主观臆测。按性能参数进行测试，并不能证明产品已经可以投放市场了。为什么？从统计学上讲，有限的测试永远不可能确保产品的质量。万分之一的缺陷经常会毁灭一个产品，但是你不可能拿一万个样品就每一种可能的失败模式进行测试。因此通过性能参数测试的设计仍有可能会面临失败。
　　一个精益的开发系统主要是为了发现失败点而测试——而设计是为了远离失败。将失败点在权衡曲线上记录下来，这将指导整个设计。
　　　这个思想大大地降低了成本。丰田公司建造的原型产品数量要比美国的竞争对手少70％～80％，尽管丰田总体上在计算机仿真方面的能力落后于美国公司。举个例子，丰田对原型车不做寿命测试，而使用权衡曲线进行完善，这时车辆本身已经有足够的证据进行设计了。这是作者在写作时的理解。　
　　限于性能参数进行测试，降低了测试组织的有效性。福特的一支团队开发了一套用于福特和马自达车门的硬件控制系统（门锁、窗调整器、镜调整器）。这个系统通过3个星期的标准测试，发现了15处毛病。马自达派来了一个测试工程师，撇开标准的测试流程，进行了严格的测试，3天内就发现了30个以上的毛病。
　　测试部门的工作是去破坏产品，记录下它是如何被破坏的，同时，建议设计工程师如何使它更坚固和难以破坏。测试工程师需要保持独立性、创造性和严格性。如果让产品工程师去确定测试的要求，这种感觉就像“既是裁判员，又是运动员”。
　　严　格　测　试
　　告诉测试部门去发现和记录产品性能的极限，提出改进建议。如果客户要求按性能参数测试，没关系，根据性能参数的上限进行测试，然后继续进行测试，直到这个产品被破坏了。
　　废弃的知识
　　最后，在产品制造发布之后，你将如何处理开发过程中获取的知识？
　　大多数公司将它存档，然后遗忘在某个角落，这也等于将最为宝贵的财富扔掉。这有以下几种原因：
　　　传统团队（及其主管人员）关注的是产品问世，而获取知识并不在优先任务清单上。
　　　按性能参数测试的做法，不能告诉工程师下次是否还有效。
　　　很少有工程师知道如何将数据转变成有用的知识。
　　估算目前废弃的知识
　　试着估算流失知识的成本。工程师们将多少时间花在寻找那些至少被开发出来一次的知识上？将结果公布出来。
　　教大家使用第3章里讨论的权衡曲线表。频繁地检查权衡曲线表，将它列为部门负责人的优先任务。
　　txt电子书分享平台　

到目前为止学到的经验教训
你学到了哪些可以付诸实践的内容呢？在第1章里，你学到了如何评估你的开发系统绩效的方法，如考察项目的ROI、缺陷项目的比率、开发人员花在增值活动上的时间比例、从商机出现到成功产品发布的过程时间等。
　　在第2章里，你学习到如何以浪费的形式，寻找绩效不良的根源：
　　1）　散乱失序：诸如组织重组和工作负荷波动等的管理行为，会阻止知识流向正确的地方；沟通的障碍，如在沟通渠道中使用许多不同格式的报告；不良的工具，大多数情况下它产生的信息可能有助于预防过去已发生的问题，但不一定能有效地预防未来发生的问题。
　　2）　交接脱节：最关键的浪费，当公司将责任、知识、行动和反馈分割开来，就会发生；无用的信息，通常是为了向管理层表明进程在控制之中而产生；等待，将开发的学习变成批量性的，以至于知识只能按一个方向流动。
　　3）　主观臆测：没有数据就做出决策；按照性能参数测试，可能会使产品存在风险，可能会忽视概率很小的问题；废弃的知识，未能将项目中学到的知识转换成可用的知识。
　　你已经学习到如何观察传统管理实践中这些浪费产生的原因，尤其是科学管理以及使用方框箭头式的流程图去计划并管理项目。你已经学习到如何将流程绘制出来，更容易发现浪费。
　　另外，你需要一个很长的清单，列出接下来要完成的事情。首先要提供一个公司现状的清晰图景：公司现在何处。我认为这一步具有至高的重要性。你可以通过一面镜子让公司更清楚地看清自己，然后推动变革。要保持政治上的理性，要讲究策略。但是要保持清晰、有力和积极进取，抓住每个机会去总结、优化和沟通关于正在发生的状况。
　　当人们看到那么多浪费，看到公司与其潜力相比表现得有多差时，你可能对公司的现状产生不满。这种不满如果能结合对未来的愿景，将促使你的公司向前进。
　　所以，去实践“动手做”清单上的事情，去激励公司的变革吧。继续阅读接下来的章节，将帮助你描绘出要往何处去的愿景。
　　。　最好的txt下载网

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页按键盘上的 Enter 键可回到本书目录页按键盘上方向键 ↑ 可回到本页顶部!

温馨提示：温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评被采纳为精评可以获得大量金币、积分和经验奖励哦！