问题树：如何发现、拆解、分析并解决复杂问题
原始 Flomo：https://v.flomoapp.com/mine/?memo_id=MTA3NDU2NjQ4
一、先把模糊现象改写成可解决的问题
问题不是“系统不好用”或“客户不满意”这种判断，而是现状与目标之间可观察、可度量的差距。建议用一句话写清：
在什么场景、哪个对象、什么时间范围内，实际表现与目标差多少？影响谁？希望达到什么结果？
例如：“最近两周，某 ECU 在高温环境下偶发 CAN 通信中断，目标是定位可复现根因并把复发率降到项目阈值以下。”
二、问题解决七步法
- 界定问题：明确范围、影响、时间线、症状、目标和不在范围内的内容。
- 收集事实：区分观察事实、推测、观点；记录日志、版本、环境、样本和证据。
- 拆解问题树：把主问题拆成互斥且尽可能穷尽的子问题（MECE），逐层分解。
- 提出假设：每个分支提出可证伪假设，并标注证据、风险和优先级。
- 验证根因：用数据、实验、对照组、复现和排除法验证；不要把相关性当因果。
- 制定行动：根因、纠正措施、负责人、截止日期、验收指标和回滚方案一一对应。
- 复盘固化：验证效果是否持续，更新标准、检查表、监控和知识卡，避免复发。
flowchart TD A[观察到异常/机会] --> B[定义问题与目标] B --> C[收集事实和基线] C --> D[构建问题树] D --> E[提出可证伪假设] E --> F[设计验证实验] F --> G{证据支持根因？} G -->|否| D G -->|是| H[制定纠正措施] H --> I[实施与回归验证] I --> J{指标达标且稳定？} J -->|否| E J -->|是| K[标准化/复盘/知识沉淀]
三、问题树怎么拆？
问题树常见三种结构：
- 议题树（Issue Tree）：把“为什么/如何”拆成可以分别回答的子问题。
- 原因树（Cause Tree）：从结果向上追溯潜在原因，适合故障分析。
- 方案树（Solution Tree）：从目标向下拆解可执行措施，适合制定行动计划。
例：ECU 偶发通信中断：
flowchart TD A[ECU通信中断] --> B[软件] A --> C[硬件/物理层] A --> D[系统集成/外部环境] B --> B1[应用未更新数据] B --> B2[COM/PduR/CanIf配置] B --> B3[任务调度/中断延迟] C --> C1[收发器供电/模式] C --> C2[终端/线束/EMC] D --> D1[网络负载/BusOff恢复] D --> D2[版本/标定/温度条件]
每个分支继续拆到可以通过日志、测量或实验验证的粒度。若两个分支大量重叠，说明分类维度不清；若有无法归类的现象，说明树不够穷尽。
四、如何排优先级？
可用“影响 × 发生可能性 × 验证成本”做初筛，再考虑安全风险和可逆性。安全相关问题优先处理，不能因概率低就忽略。高风险假设先验证；低成本且能快速排除的假设可先做。
五、常见误区
- 一开始就跳到解决方案，没有定义问题和基线。
- 把“可能原因”写成“根因”，缺少可复现证据。
- 问题树分类维度混杂，分支重复或遗漏。
- 只追究个人责任，不检查流程、接口、资源和系统性诱因。
- 措施完成就宣布关闭，没有验证效果和防复发机制。
六、可复制的问题记录模板
| 项目 | 记录内容 |
|---|---|
| 问题陈述 | 场景、对象、现状、目标差距 |
| 影响范围 | 用户、产品、版本、时间、风险 |
| 事实证据 | 日志、数据、截图、复现步骤 |
| 问题树 | 主问题与分层子问题 |
| 根因假设 | 假设、支持证据、反证、置信度 |
| 验证计划 | 实验、样本、通过/失败标准 |
| 纠正措施 | 负责人、期限、回滚与风险 |
| 效果确认 | 指标变化、观察周期、防复发措施 |