第14章 失败分类与复盘方法

前面的体系多次提到：要惩罚低质量行为，而不是惩罚经过验证后的失败。但如何区分"高质量失败"和"低质量失败"？如何从失败中学习？

这一章我们讨论：失败的分类、如何复盘失败、如何从失败中沉淀经验。

失败不是洪水猛兽

首先要明确一个观点：

在研发工作中，失败是正常的，甚至是必要的。

尤其是在 0->1 探索阶段，失败本身就是学习的一部分。如果一个团队从来没有失败过，可能意味着：

• 他们从来没有尝试过有挑战的事情
• 他们把失败隐藏起来了
• 他们不敢试错，只做安全的事情

真正应该避免的，不是失败本身，而是"低质量失败"——没有验证、没有学习、没有结论、重复犯同样的错误。

失败分类矩阵

我们可以用两个维度来区分不同类型的失败：

什么是高质量失败？

特征：

• 有明确的假设
• 有合理的验证设计
• 有真实的数据和证据
• 有清晰的结论（知道为什么失败，以后如何避免）
• 有经验沉淀

例子：

• 我们假设"用户需要这个功能"，做了原型验证，发现用户其实不需要——结论清晰，学习到了，这是高质量失败
• 我们假设"这个技术方案可行"，做了 PoC，发现性能不达标——但我们知道了为什么不行，这是高质量失败
• 我们按计划推进，但外部依赖延期，我们提前暴露了风险，有预案——虽然延期了，但过程质量高

对高质量失败的态度：

• 不要惩罚
• 要鼓励和认可
• 要复盘和沉淀经验
• 要问：我们学到了什么？

什么是低质量失败？

特征：

• 没有假设，拍脑袋就上
• 没有验证，直接大投入
• 没有风险控制，问题最后爆发
• 没有复盘，下次还犯同样的错
• 隐瞒问题，等出事才暴露

例子：

• 不做用户调研，直接做了一堆功能，最后没人用——低质量失败
• 不做技术验证，直接重构，导致线上事故——低质量失败
• 发现问题不说，等别人发现才被动处理——低质量失败
• 同样的质量问题，重复出现——低质量失败

对低质量失败的态度：

• 要严肃对待
• 要问责
• 要改进流程和机制
• 要问：为什么会发生？如何防止再犯？

失败复盘方法论

失败复盘不是为了"找责任人"，而是为了"防止再犯同样的错"和"沉淀经验"。

复盘的适用时机

• 项目失败了
• 线上出现严重事故
• 关键假设被证伪
• 同样的问题重复出现
• 里程碑没有按时达成，且原因不清晰

复盘的原则

1. 对事不对人：关注问题本身，不攻击人格
2. 用数据说话：有事实，有证据，不是凭感觉
3. 往前看：重点是"以后如何避免"，而不是"谁错了"
4. 公开透明：复盘结果可以分享给其他团队，避免别人也踩坑

复盘的步骤（5步法）

第一步：还原事实

目标：搞清楚"到底发生了什么"，不要急着下结论。

要回答的问题：

• 我们的目标是什么？
• 实际发生了什么？
• 时间线是怎样的？
• 关键节点有哪些决策和行动？
• 有哪些数据和证据？

怎么做：

• 收集所有相关信息（文档、邮件、聊天记录、数据）
• 画出时间线
• 让所有相关人一起还原，确保没有遗漏
• 只记录事实，不做评价

注意：

• 不要说"张三做错了"，要说"在某某时间，张三做了某某决定，导致了某某结果"
• 不要说"这是个愚蠢的决定"，要说"这个决定基于什么假设，后来发现这个假设不成立"

第二步：分析原因

目标：找到"为什么会发生"，区分"直接原因"和"根本原因"。

要回答的问题：

• 直接原因是什么？（最表面的原因）
• 根本原因是什么？（深层的、系统性的原因）
• 有哪些假设不成立？
• 有哪些风险没被识别？
• 流程和机制有什么问题？

怎么做：

• 用 5 Whys 法：不断问"为什么"，直到找到根本原因
• 区分"人"的问题和"系统"的问题（通常都是系统问题）
• 画出因果关系图

5 Whys 例子：

• 问题：线上出现事故
• Why 1？因为代码有 bug
• Why 2？因为测试没覆盖到
• Why 3？因为测试用例没考虑这个场景
• Why 4？因为需求文档没写这个边界条件
• Why 5？因为我们没有"需求边界条件检查清单"

关键：不要停留在"人犯了错"，要找到"为什么系统会让人犯这个错"。

第三步：总结经验

目标：从这次失败中，我们学到了什么？

要回答的问题：

• 哪些假设被证伪了？
• 哪些做法是错的，以后不能再做？
• 哪些做法是对的，以后要继续？
• 如果重来一次，我们会怎么做？
• 其他团队可以从中学到什么？

怎么做：

• 把经验整理成"原则"或"检查清单"
• 区分"这次的经验"和"可复用的经验"
• 用简洁的语言总结，方便记忆

例子：

• 经验 1：硬件相关的变更，必须做满 72 小时的老化测试
• 经验 2：涉及第三方依赖的功能，必须验证降级方案
• 经验 3：上线前，必须有明确的回滚预案

第四步：制定改进计划

目标：把经验落实到行动，防止再犯。

要回答的问题：

• 我们需要做哪些改进？
• 谁负责？
• 什么时候完成？
• 如何验证改进有效？
• 哪些改进需要纳入流程和规范？

怎么做：

• 把改进措施变成具体的任务
• 每个任务有明确的责任人、时间节点、验收标准
• 优先级排序：先做高影响、低成本的
• 改进计划要公开透明，让大家都知道

例子：

• 改进项 1：建立"需求边界条件检查清单"（张三，2 周内完成）
• 改进项 2：在代码评审流程中加入"第三方依赖降级方案检查"（李四，3 周内完成）
• 改进项 3：所有硬件项目必须做 72 小时老化测试，加入项目 Checklist（王五，1 周内完成）

第五步：跟踪和回顾

目标：确保改进措施真正落地，而不是"说说而已"。

要回答的问题：

• 改进措施是否按时完成了？
• 效果如何？有没有防止再犯？
• 还需要什么调整？
• 哪些改进可以推广到其他团队？

怎么做：

• 定期（如 1 个月后、3 个月后）回顾
• 检查改进措施的完成情况
• 评估效果
• 如果问题还是出现，继续复盘

复盘模板

失败复盘文档模板

# [项目/事故名称] 复盘报告

## 一、背景和目标

- 我们原本要做什么？
- 目标是什么？
- 时间线是怎样的？

## 二、发生了什么

- 实际结果是什么？
- 和目标的差距在哪里？
- 关键事件时间线
- 相关数据和证据

## 三、原因分析

- 直接原因
- 根本原因（5 Whys）
- 因果关系图（可选）
- 哪些假设不成立？
- 哪些风险没被识别？

## 四、这是高质量失败还是低质量失败？

- 理由是什么？
- 哪些做得好？
- 哪些做得不好？

## 五、经验总结

- 我们学到了什么？
- 哪些原则可以提炼出来？
- 哪些检查清单可以建立？
- 其他团队可以学到什么？

## 六、改进计划

| 改进项 | 具体内容 | 责任人 | 完成时间 | 验收标准 |
|-------|---------|--------|---------|---------|
| 1 | | | | |
| 2 | | | | |

## 七、下一步

- 什么时候回顾？
- 哪些改进需要推广？
- 还有什么要跟进？

不同类型失败的复盘重点

探索期失败（0->1）

重点：

• 我们的假设是什么？
• 验证设计是否合理？
• 数据是否真实有效？
• 结论是否清晰？
• 学到了什么，以后可以避免？

不要：

• 因为失败就否定团队
• 说"早知道就不做了"

交付期失败（1->10/1->100）

重点：

• 风险是否被识别？
• 计划是否合理？
• 质量控制是否到位？
• 流程和机制有什么问题？
• 如何防止再犯？

不要：

• 只骂"谁犯了错"
• 不改进系统，只要求"下次注意"

重复失败

重点：

• 上次复盘的改进措施为什么没落地？
• 是改进措施本身不对，还是执行不到位？
• 机制上有什么问题，让同样的错误重复犯？
• 如何从根源上解决？

不要：

• 只说"你们又犯了同样的错"
• 不反思为什么上次的改进没起作用

失败与绩效评价

失败应该如何影响绩效评价？

高质量失败

绩效影响：

• 不应该影响绩效，甚至可以加分
• 关键看过程质量：有假设、有验证、有学习、有结论

评价时要问：

• 他们是不是真的在探索有价值的方向？
• 验证设计是否合理？
• 有没有学到东西？
• 有没有沉淀经验？

低质量失败

绩效影响：

• 应该影响绩效，甚至是低绩效的理由
• 关键看行为：无验证、无闭环、隐瞒问题、重复犯错

评价时要问：

• 是不是拍脑袋？
• 有没有隐瞒问题？
• 有没有复盘和改进？
• 是不是重复犯同样的错？

混合情况

很多时候失败不是非黑即白的，可能既有做得好的地方，也有做得不好的地方。

评价时要区分：

• 哪些是高质量的部分？
• 哪些是低质量的部分？
• 整体来看，过程质量如何？
• 团队有没有从失败中成长？

总结

失败分类与复盘的核心原则是：

1. 区分高质量失败和低质量失败：前者应该被鼓励，后者应该被惩罚
2. 复盘是为了学习，不是为了问责：重点是"以后如何避免"，不是"谁错了"
3. 用系统思维看问题：不要停留在"人犯了错"，要找根本原因
4. 把经验落实到行动：改进计划要有责任人、时间节点、验收标准
5. 失败要和绩效正确关联：高质量失败不影响绩效，低质量失败才影响

当团队真正敢于面对失败、从失败中学习时，失败就会变成团队成长的养分，而不是包袱。