# 解决问题的方法

> 管理者大部分时间在解决问题，但多数时间浪费在**解决错的问题**上。方法的价值不是让你更快地给出方案，而是让你在动手前确认：这是不是那个真正的问题。

## 一、先分清「现象」和「问题」

- 现象：接口 P99 变高、客户投诉增加、团队加班变多；
- 问题：**期望与现状之间的差距**，且这个差距值得被消除。

现象是线索，问题是判断。把现象当问题，就会头痛医头。

## 二、问题陈述五要素

| 要素 | 要写清什么 | 示例 |
| --- | --- | --- |
| 现状 | 现在发生了什么，有多严重 | 支付成功率从 99.2% 降到 97.8%，每天约 3000 笔失败 |
| 期望 | 应该是什么样 | 恢复到 99.2% 以上 |
| 差距 | 量化差距 | 每天多 2000 笔失败 |
| 影响 | 谁受影响、损失多少 | 客诉上升、日损失约 X 元 |
| 约束 | 时间、资源、合规边界 | 48 小时内必须恢复，不能改支付渠道 |

写不出来，说明问题还没定义清楚，此时讨论方案都是空谈。

## 三、拆解：把大问题变成可验证的假设

- **MECE**：拆出的子问题互不重叠、合起来覆盖全部（按渠道、按客群、按环节拆）；
- **假设驱动**：先猜「最可能是哪一环」，再去验证，而不是平铺所有可能；
- **5 Whys 的正确用法**：不是问五次为什么，而是**每次都用证据替代猜测**。「为什么失败率上升？」→「因为超时」→「为什么超时？」→「因为数据库连接池打满」→「为什么打满？」→「因为新上线的查询没有走索引」。

没有证据的 5 Whys 会滑向「因为管理不到位」这种正确但无用的结论。

## 四、决策：给方案排序，而不是选第一个

| 维度 | 问什么 |
| --- | --- |
| 有效性 | 能解决多大比例的问题，怎么验证 |
| 成本 | 人力、时间、风险、机会成本 |
| 可逆性 | 错了能不能改回来，多久能改回 |
| 最坏情况 | 如果失败，损失有多大，能不能兜住 |

可逆且低成本的方案，先做再说；不可逆的方案，必须多方评审、准备回退路径。

## 五、执行：把方案变成可验收的动作

- 每项动作有**唯一负责人**与截止时间；
- 明确**验证指标**：什么数据出现，说明问题解决了；
- 设定**检查点**：24 小时/一周看一次，而不是等交付时才知道；
- 预案：如果第一方案无效，第二步做什么。

## 六、复盘：让同类问题不再发生

复盘不是写检讨，要回答四个问题：

1. 当时基于什么信息做的判断，哪个判断错了？
2. 为什么没更早发现（监控、流程、人的盲区）？
3. 哪一步是运气好，而不是机制在起作用？
4. 下次遇到同类问题，提前做什么能把它挡住？

行动项要区分「立刻改」「排期改」「决定不改（说明理由）」，否则复盘会变成许愿池。

## 七、五个常见错误

1. **跳到方案**：听到现象就开始讨论怎么做，没定义问题；
2. **只解症状**：重启恢复服务，根因没动，下周再来一次；
3. **方案找问题**：先决定要做某个系统，再论证它有必要；
4. **选择性用数据**：只挑支持自己观点的指标；
5. **没有验证**：改完不确认指标，凭感觉判断「应该好了」。

## 八、自检清单

- [ ] 我能用五要素写清当前最重要的问题
- [ ] 我知道哪些是现象、哪些是真正的问题
- [ ] 拆解出的子问题有数据或证据支撑，而不是猜测
- [ ] 方案有对比、有代价、有可逆性评估
- [ ] 每个动作有负责人、截止时间、验证指标
- [ ] 问题解决后有复盘，行动项闭环
- [ ] 同一个问题最近三个月没有重复出现