five-whys

name	five-whys
description	用五个为什么追溯问题的根本原因，避免用短期补丁掩盖深层问题。当团队反复遇到同一个问题、产品出现异常指标、流程效率下降时，使用此Skill找到真正的原因。

Skill: 五个为什么分析

Metadata

• ID: leanstartup-005
• 类型: framework
• 来源: 《精益创业》第十一章
• 验证状态: ✅ 三重验证通过（V1: 11章完整说明+案例, V2: 团队日常高频, V3: 反常识）

R — Reading（原文引用）

"五个为什么是一种根源分析方法，通过不断追问'为什么'来找到问题的根本原因，而非仅仅解决表面症状。"

"如果我们不持续追问根本原因，同样的问题会反复出现，消耗团队精力。"

I — Interpretation（方法论骨架）

五个为什么的核心洞察：问题的表象往往不是真正的问题。

当你遇到问题时，99%的人在想"怎么解决这个"，而只有1%的人在问"为什么会出现这个问题"。

不追问根本原因的后果：

• 每次问题出现就用补丁解决（治标不治本）
• 同样的问题在不同时间、不同形式反复出现
• 团队精力被反复消耗在"救火"上

按比例投入：大问题大投入，小问题小投入。不需要为所有问题都追5个为什么。

A1 — Past Application（书中案例）

IMVU的产品缺陷处理：每次产品出问题，团队就快速打补丁。但通过五个为什么分析发现，根本原因是"测试流程没有覆盖实际用户场景"——不是"某个功能有bug"，而是"整个质量保障体系有问题"。修复了这个根本问题后，缺陷率大幅下降。

丰田的精益生产起源：大野耐一用五个为什么识别出工厂效率低下的根本原因不是设备问题，而是"工人缺乏改进权限"——这直接促成了丰田生产系统的建立。

A2 — Future Trigger（何时调用）

当你听到以下问题时，就应该调用这个Skill：

• "这个问题我们已经修复过3次了，怎么又出现了？"
• "团队总在加班救火，但问题似乎永远解决不完"
• "某个指标突然变差，但不知道是什么原因"
• "每次开会都在讨论同一个问题"
• "我们花了很长时间做优化，但效果不明显"

E — Execution（可执行步骤）

步骤1：识别需要分析的问题

选择标准：

• 这个问题是否重复出现？（出现1次可能是偶然，3次以上就是系统性问题）
• 这个问题的影响有多大？（大影响值得深挖，小问题不值得过度分析）
• 团队是否倾向于用临时补丁解决？（是的话需要追问）

步骤2：开始追问（从问题陈述开始）

"为什么这个问题发生了？" 记录答案。

"为什么那个原因导致了这个问题？" 记录答案。

继续，直到问满5次，或者答案已经是"这是流程/文化/架构问题"

注意：每次追问的答案必须是可操作的具体原因，不能是模糊的"人为疏忽"或"沟通不畅"。

步骤3：按比例投入资源

问题严重程度	投入资源	预期
影响核心业务/大量用户	大投入，彻底修复	根除
影响部分用户/中等频率	中等投入，流程改进	大幅减少
偶发/影响小	小投入，简单处理	接受现状

步骤4：防止历史包袱

不要把"历史包袱"放进五个为什么流程：

• "这个问题存在太久了，所以不用分析"
• "当时的情况和现在不一样"
• "以前的人做的决策我们不要追究"

只关注现在和未来：这个流程/体系/方法在当前是否还在产生问题？

步骤5：指定负责人

每个五个为什么分析必须指定一个**"五个为什么负责人"**：

• 负责追踪问题是否被根本性解决
• 负责在问题再次出现时启动新一轮分析
• 负责向团队报告改进效果

B — Boundary（何时不适用）

不适用场景	原因
需要立即处理的紧急故障	这时候需要快速止血，之后再复盘分析
问题原因已经明确（如明显的资源缺失）	不需要追5个为什么，直接解决
跨部门的复杂系统问题	需要更结构化的分析方法

作者盲点提醒：五个为什么可能被滥用——有人会用它"追责"而非"解决问题"。这会让团队害怕暴露问题，反而掩盖了真正的问题。健康的五个为什么文化需要"对事不对人"的心理安全感。

关联Skills

• 小批量原则 — 小批量能让问题快速暴露，而不是等几个星期才发现
• 创新沙盒 — 创新沙盒用五个为什么建立自适应组织
• 转型决策树 — 五个为什么是判断"转型根本原因"的重要工具