不只处理导火索 · 找到那个装满火药的桶 · 让问题不再复发
1.
线上出了个故障。老板问：「怎么回事？」你说：「小王昨晚提交了一段有问题的代码。」小王被批评了。代码修好了。两周后，同样类型的故障又发生了——这次是小李的代码。
你上次只处理了触发原因（小王的错误代码），没有处理根因（为什么一段未经审核的代码可以直接上线？）。 触发原因是导火索，根因是火药桶。你灭掉了一根导火索——但火药桶还是满的。
2. 核心概念
> 触发原因（Trigger）：直接导致事件发生的表面行为。根因（Root Cause）：使得触发原因能产生破坏力的底层系统缺陷。处理触发原因 = 治标。处理根因 = 治本。
根因分析的铁律：永远不要停在第一个「谁做了什么」。一直追问到「为什么这个系统允许这件事发生？」
3. 三个场景
场景一：客户流失
- 触发原因：「客户说我们的产品太贵了。」
- 根因：客户没有看到产品的独特价值——因为我们的交付过程中没有持续的「价值回顾」环节。客户用了6个月只体验到了「贵」，没体验到「值」。
- 修复：在交付流程中每两周做一次价值回顾——主动告诉客户「因为我们的产品，你省了多少/赚了多少」。
场景二：员工离职
触发原因：「ta说薪水太低。」根因可能是：ta觉得成长空间有限，薪水只是最容易说出口的理由。处理触发原因（加薪）可能再留ta一年。处理根因（提供明确成长路径+定期职业对话）才能留更多人。
场景三：项目延期
触发原因：「设计师改了三版稿，浪费了开发时间。」根因：需求阶段没有明确「设计冻结」的标准和时间点，缺乏变更控制流程。
4. 如果你只记住一句话
> 「不要惩罚触发原因——修复根因。犯错的人不是问题，允许错误发生的系统才是。」
3件事
1. 下次出了问题，问自己：「这是触发原因还是根因？」 如果不是根因，再问5个Why。
2. 根因必须是「系统性的」而非「个人的」。 「小王粗心」不是根因——「为什么没有机制防止粗心导致的错误？」才是。
3. 修复方案必须能回答：同样类型的触发原因再来一次，系统能挡住吗？ 不能的话——你修的还是触发原因。