鲁达 有时，在项目管理中会发生意外事件。 线索混乱，系统崩溃，产品无法按照预期的水平运行，或者遗留的流程无法达到当前的预期。 在精益项目管理中，当事情没有按照计划进行时，有一个简单而强大的分析技术可以快速深入到问题的根源，我们称之为精益的 5 Why。
5 Why即五个为什么，是指用连续追问的方法直至找到问题的症结并解决问题的一种分析法。当然，这里的“5”是虚指，有时候需要10个或者更多“why”才能找到答案，有时可能只要两三个“why”就能找到想要答案。
使用5 Why，精益团队可以:
- 摆脱责备
- 超越问题的具体背景来思考
- 找出问题的根本原因
- 确定一个可持续的、渐进的解决方案来解决问题
5 Why的起源
5 Why的概念最初是由丰田工业公司的创始人丰田佐吉 （ Sakichi Toyoda ）在20世纪30年代提出的。 但是这个概念在20世纪50年代后期达到了主流受众，当时丰田生产系统的设计师大野耐一（Taiichi Ohno）推广了“5 Why”的概念。
除了在丰田的制造业演进中扮演关键角色外，大野耐一通常被认为是精益思想的早期先驱之一。 他在他的书《丰田生产系统: 超越大规模生产》（ Toyota Production System: Beyond Large-Scale Production. ）中讨论了精益的5 Why。 在这篇文章中，他将这一想法称为“丰田科学方法的基础”。
作为一家公司，丰田的大部分故障排除工作都基于“Go See”的理念。换句话说，它的领导层致力于根据对生产现场实际情况的详细了解做出决策，而不是依赖于董事会成员的高管认为可能发生的事情。这就是为什么“5 Why”概念需要团队成员积极投入的主要原因之一------它不是作为一个单独的或孤立的任务来工作的。
“5 Why”的概念是基于一个简单的前提:当一个问题出现时，问问题为什么？最多五次，直到出现可行的解决方案。“5 Why”是一种解决问题的技巧，旨在帮助公司发现问题的根本原因。每一个额外的“Why”的答案都有助于团队深入研究，直到问题的本质和解决方案都变得清晰为止。
“5 Why”通常有助于解决产品问题、解决一般问题、质量控制或过程改进等问题。这个过程对于简单到中等的问题很有效，但是对于复杂或关键的问题就不那么有效了。
“5 Why”的简单性使得它非常适合于需要进行根本原因分析的情况，这是一个系统化的过程，重点在于确定要解决的核心问题。
第一步是明确要解决的问题。如果从一开始就认为这是一个可以从根本原因分析中获益的问题，那么应用“5 Why”技术很可能是有意义的。相反，需要潜在多种解决方案的复杂情况最有可能通过更广泛的方法来解决。
假设您有精益团队，致力于设计和生产新的15英寸笔记本电脑。在设计阶段，测试工程师开始看到性能测试和基准测试的性能下降。这种行为是可重复的和一致的:性能开始很强，但很快就减弱了。
使用5 Why，很明显性能下降是由于热问题。当处理器长时间被征用时，它最终会开始过热。然后，系统工程师可以研究潜在的热解决方案。他们可能会考虑机械解决方案，比如缩小电池尺寸，为更大的风扇腾出空间，或者甚至增加第二个风扇。
如果这个问题直到笔记本电脑投入生产并已经在客户手中时才被发现，那会怎么样？这使得硬件变更更难实现，成本也更高。在这种情况下，工程师可能会决定追求非硬件的替代品；例如，在基本输入输出系统级别重新检查风扇速度和定时设置，以使处理器保持更长时间的冷却。
另一个“5 Why”可能适用的制造场景是：想象你是一个生产团队的一员，负责在一个特定的工厂生产轿车。与前几个月相比，你们团队生产的汽车数量下降了20%以上。
使用“5 Why”，你的团队能够缩小生产过程中持续降低团队速度的部分。由于零件更换，现在安装发动机需要三个额外的手动步骤。在这种情况下，团队可以与领导层合作，自动执行部分新步骤，以缩短整体生产时间。
软件开发是另一个“5 Why”可能有用的地方。你可能是一个开发团队的成员，负责在接下来的四周内向客户交付一个发布候选版本。团队成员很关注如何满足交付期限。
使用5 Why，很明显，如果一个关键特性的开发比预期的要花更长的时间来完成。由于预算原因，雇佣更多的开发商不是一个选项。经过团队讨论后，项目负责人向客户通报情况，提出一种把核心特性功能中次要元素优先级降低的方法。
这种折衷使得团队能够满足核心产品的原始交付计划。然后，团队延长时间表，在产品交付三周后，将次要元素作为功能更新进行交付。
5 Why可以有效帮助团队
在许多情况下，“5 Why”对团队很有帮助。通过提供一个简单的根本原因分析途径，5 Why允许精益团队专注于确定持久的解决方案，而不是满足于临时的快速解决方案------这可能导致流程分散，显著增加复杂性，并最终导致堆积如山的技术债务。
使用5 Why，精益团队可以把注意力从责怪问题的“责任人”转移到改善过程本身
如果你的团队已经在实践和思考精益，5 Why提供了一个自然诊断和消除浪费来源的机会。 团队可以超越问题的具体环境，看到更大的改进机会。
5 Why如何开始
开始学习精益的5 Why很简单:找出你的团队面临的问题，然后问，“为什么会出现这个问题？”记录答案，然后重复这个过程四次，或者直到你的答案没有效果。
当答案不再揭示与问题直接相关的因素时，是时候专注于开发解决方案了。这些解决方案可以是小的改进——记住引导精益思想的渐进改进本质。
关键是找到可持续的、持续的、直接解决问题的解决方案。团队应该关注两件事:渐进的过程改进和防止问题再次出现。
一些专家和精益实践者建议指定一个“5 Why”的Master，这个人将:
- 拥有问题的定义
- 问五次为什么(或者需要问多少次)
- 指导或记录讨论结果
- 明确解决方案并将其实现分配给团队成员
- 拥有任何事后讨论
其他团队可能会发现轮流促进“5 Why”的讨论很有帮助。举例来说，你的团队可能决定不实施正式的精益讨论的5个为什么，而是选择将5个为什么构建到日常工作对话中。
把这个简单、容易记住的思考工具当作一种资源，当你遇到一个明显的问题，却没有一个明确的解决方案时，你可以利用它。定期使用“5 Why”最有可能帮助团队节省时间、精力和挫折，同时有助于确定持续问题的可持续解决方案。
5 Why如何应用
现在，让我们来看看如何应用5 Why。下面是一个真实的例子，说明一个组织如何使用精益的5个为什么来解决一个问题。
在这种情况下，移动开发团队的问题集中在交付上。该团队努力及时将错误修复交给质量保证团队。团队知道他们当前交付过程的许多方面本质上是手工的，并且提高效率的机会将对他们有极大的帮助。以下是他们如何使用5个为什么:
问题：为QA提供错误修复是一个耗时的过程。
为什么？—生成新的应用程序发布候选版本非常耗时。为什么？—构建步骤需要仔细注意，因为一旦犯错需要重新开始。为什么？—有一个特定的构建顺序来交付成功的候选版本。为什么？—交付候选版本需要额外的步骤。为什么？—我们花费过多时间记录当前功能以及变更请求历史。
如果没有精益的5 Why，团队可能过早地将其定义为速度问题——团队中交付错误修复的人员动作不够快。但是应用5 Why突出了通过自动化简化交付过程某些方面的机会。
目前的手工提交过程是可重复的，但文档化过程被证明是冗长乏味的，并且容易出现人为错误。 团队决定花费周期来简化文档和自动化向 Quality Assurance 交付错误修复。
一旦实现，这些步骤的自动化将大大减少交付时间。 团队士气和团队工作的质量也极大地提高了过程。
精益工作的5 Why最好是由一个跨职能团队完成，而不是由一个人完成。 这个团队应该包括那些非常了解当前流程的成员，以及那些愿意关注事实和数据而不是诉诸情绪反应的成员。
最终目标是找出问题的根本原因，并采取行动进行纠正，而不仅仅是治疗症状。这不仅在团队成员层面创造了持续改进的机会，也给了团队信心，他们可以用改进的流程和增量解决方案来解决问题。
5 Why应用案例
案例一：大野耐一的运用
丰田汽车公司前副社长大野耐一曾举了一个例子来找出停机的真正原因
问题一:为什么机器停了？
答案一:因为机器超载，保险丝烧断了。
问题二:为什么机器会超载？
答案二:因为轴承的润滑不足。
问题三:为什么轴承会润滑不足？
答案三:因为润滑帮浦失灵了。
问题四:为什么润滑帮浦会失灵？
答案四:因为它的轮轴耗损了.
问题五:为什么润滑帮浦的轮轴会耗损？
答案五:因为杂质跑到里面去了。
经过连续五次不停地问“为什么”,才找到问题的真正原因和解决的方法，在润滑帮浦上加装滤网。
如果员工没有以这种追根究底的精神来发掘问题，他们很可能只是换根保险丝草草了事，真正的问题还是没有解决。
案例二：阿波罗13氧气舱爆炸
1970年4月13日 氧气舱内的风扇开启后氧气舱爆炸 。
为什么爆炸会发生？
电线使风扇变成拱形并引燃舱内的氧 气
为什么会被电线弄成拱形?
导线中心被引爆
为什么中心被引爆?
绝缘被烧坏
为什么绝缘被烧坏?
在前导系统测试过程中氧气舱过热
为什么氧气舱过热?
氧气舱中的加热器通常会维持舱内的 压力，但在舱内被清空后（也就是测 试结束后）没有被关掉
为什么加热器没有被关掉?
切断电源的开关可以在舱过热时自动 关掉加热器，可是它失效了。
为什么开关会失效?
在测试中它超过了额定电压。工程师 们确信舱内的液氧可以使开关保持冷 却,然而,当舱内被清空时，开关就迅速 地变热从而失效。
为什么加热器首先被启动？
当测试结束时舱内的氧气并没有彻底 清除干净(为了安全起见，测试结束后 舱内不应留有氧气。
为什么舱内没有完全被清空?
在前导系统测试中插口管被震松了。