5 Whys 模板给你一个简单、可重复的根因分析结构。与其每周治疗同样的症状、修复同样的问题，不如沿着因果链回溯，找到真正的源头。格式看起来简单到不可思议：从问题开始，问五次"为什么"，第五个为什么的答案通常就是根本原因。
这项技术由丰田工业创始人丰田佐吉提出，成为丰田生产系统的核心工具。它的巧妙之处在于不需要数据、不需要统计、不需要培训——只需要愿意持续追问"为什么"，而不是接受第一个答案。
打开免费的 5 Whys 模板，里面预填了一个从问题到根因到行动的完整业务示例。本文解释如何开展产生真正结果、而非只是填完一张模板的 5 Whys 会议。
什么时候用 5 Whys
5 Whys 最适合具体、反复出现、涉及人员或流程因素的问题。对具有多个相互影响原因的复杂问题效果较差——那些需要鱼骨图或更结构化的根因分析方法。
5 Whys 适用于：
- 重复发生的事件：部署每隔一周失败、客户报告同一个 bug、机器总在同一环节卡住
- 流程故障：审批卡住、交接失败、截止日期因同样原因延迟
- 团队摩擦：沟通不畅、期望不一致、反复出现的冲突
- 质量问题：尽管修复了仍然反复出现的缺陷
- 客户投诉：不同客户提出同样的投诉，说明是系统性问题而非偶发事件
不要用于一次性事故、已知原因的技术故障或真实目的是追责而非改进的场景。
如何开展 5 Whys 会议
第 1 步：写清楚问题陈述
要具体。把问题写下来：发生了什么、什么时候发生、可衡量的影响是什么。
第 2 步：问第一个为什么
问："为什么会发生这件事？"把答案直接写在问题下方。答案应该是一个事实性原因，而不是追责陈述。
第 3 步：继续追问
把第 2 步的答案作为下一个问题的主体。继续这条链。不要跳到结论——让每个答案自然引出下一个问题。
第 4 步：到可执行的根因时停止
当答案是你能够通过具体行动修复的原因时，就到达了根因。
第 5 步：定义对策
针对根因，写出一个能防止问题再次发生的具体行动。指定负责人和截止日期。
完整 5 Whys 示例
以下是免费 5 Whys 模板中预填的示例：
问题： 客户支持响应时间从 4 小时增加到 Q3 的 18 小时。
为什么 1： 为什么响应时间增加了？→ 因为支持队列增长了 3 倍，而团队规模不变。
为什么 2： 为什么队列增长了？→ 因为新产品发布每天产生 200+ 工单，本应由自助知识库处理。
为什么 3： 为什么知识库没处理那些工单？→ 因为新产品的知识库文章直到发布两周后才上线。
为什么 4： 为什么知识库文章延迟了？→ 因为产品团队直到发布前一天才提供最终功能文档。
为什么 5： 为什么产品团队没有更早提供文档？→ 因为发布检查清单中没有包含"向支持团队交付可用于知识库的文档"这一步骤。
根因： 产品发布检查清单缺少支持就绪步骤。
行动： 将"发布前 1 周向支持团队交付知识库文档"添加到产品发布检查清单。负责人：产品运营。截止日期：下次发布周期前。
常见 5 Whys 错误
停得太早。 团队常在为什么 2 或为什么 3 就停下了，因为答案感觉可以执行。但如果答案仍然是更深层原因的症状，就没有到达根因。
对人不对话地追问。 "为什么小王犯了错误？"导向追责。"为什么一个人的错误就能导致生产中断？"导向流程改进。
没有后续行动。 没有对策的 5 Whys 只是脑力练习。模板中的行动栏不是可选项。
5 Whys 和鱼骨图怎么配合
鱼骨图适合先发散，把可能原因按人员、流程、设备、材料、环境、测量等类别列出来。5 Whys 适合后收敛，选中最可能的一条原因链继续往下追。
如果一开始完全不知道原因，先画鱼骨图；如果已经锁定一个高概率原因，用 5 Whys 深挖。好的对策应该具体、有人负责、有截止日期，并且能防止问题复发。“加强沟通”太虚，“发布前 1 周把知识库文档交付给支持团队，并加入发布检查清单”才是可执行行动。
打开免费的 5 Whys 模板，将预填示例替换为你自己的问题，追踪因果链到真正的根因。
