鱼骨图（Fishbone Diagram）又称因果图（Cause-and-Effect Diagram）或石川图（Ishikawa Diagram），由日本质量管理大师石川馨博士于 1960 年代发明。它用一张"鱼的骨架"结构，帮助团队系统地梳理"从问题（鱼头）出发，层层展开到六大类可能原因（大鱼骨），再细分到具体的影响因素（小鱼骨）。
鱼骨图最强大的地方在于：它是一个"发散 → 收敛的可视化的团队讨论工具——你可以在白板上和团队一起头脑风暴，每个人都能看到"原因如何汇聚到一个问题"，避免讨论从"混乱的想法"变成"结构化的分析"。
鱼骨图的基本结构如下：
六大类原因（经典 5M1E）：
注意：以上是制造业/质量管理场景下的经典分类。在非制造业场景（如软件、服务、管理）可以灵活调整分类。常见的替代方案包括但不限于：人、流程、技术、数据、客户、合规等。
以下是一个简化的鱼骨图分析，展示"产品 A 次品率从 1.2% 上升到 3.8% 的完整分析表格形式的鱼骨图（因为 HTML 中表格形式鱼骨图）：
| 大类原因 | 中原因 | 具体小骨（具体原因） | 是否根本原因？ |
|---|---|---|---|
| 人（人员） | 经验不足 | 3 名资深工程师离职 + 2 名新工程师入职不满 3 个月 | ✓ 是（主要原因） |
| 培训不足 | 缺乏产品知识培训 | ✓ 是 | |
| 沟通不畅 | 新老工程师交接不完整 | ✓ 是 | |
| 角色不清 | 代码审查由谁负责不明确 | — | |
| 机（系统/工具） | 工具缺失 | 缺乏自动化测试工具覆盖新模块 | ✓ 是 |
| 系统问题 | CI/CD 流水线不稳定 | — | |
| 监控不足 | 生产环境监控缺失 | — | |
| 料（输入/需求） | 需求不清 | 需求文档不完整，边界条件描述模糊 | ✓ 是 |
| 变更频繁 | 7 月需求变更 5 次 | — | |
| 法（流程/方法） | 流程设计问题 | 代码覆盖率从 85% 下降到 52% | ✓ 是（核心原因） |
| SOP 缺失 | 没有统一的代码审查 checklist | ✓ 是 | |
| 测试方法 | 缺乏压力测试不充分 | — | |
| 测（数据/测量） | 数据缺失 | 缺陷率的自动化监控缺失 | — |
| 指标定义 | 不同团队对"缺陷"定义不同 | — | |
| 环（环境） | 时间压力 | v2.3 版本发布压力大，压缩测试时间 | ✓ 是 |
| 组织氛围 | 离职潮导致团队士气下降 | — |
根本原因总结：人员流失 + 流程松弛 + 时间压力是三个核心根本原因——这三个原因相互作用，导致了次品率的显著上升。
鱼骨图和 5Why 是完美搭档：鱼骨图帮助你"发现可能原因"（发散），5Why 帮助你"验证根本原因"（收敛）。流程是：
鱼头问题太宽泛的话，大骨下的原因也会跟着变宽泛。正确做法：问题陈述必须具体、可衡量、有时限。"产品 A 的支付转化率问题"比"产品有问题"好 10 倍。
"人有问题"是一个结论不是一个原因。应该写成"3 名工程师离职 + 新人入职不满 3 个月"这种具体事实，这样才会让分析有意义。
鱼骨图画完了就结束了——这是最常见的错误。画完图只是分析的"开始"。必须通过数据验证、根本原因是否真的存在吗？有数据支持吗？有数据验证才是"完成"。
鱼骨图是一个团队讨论工具，不是一个人的文档。最佳实践是在会议室的白板上和团队一起画——每个人的想法汇聚在一张图上，这样才能产生"集体智慧。
鱼骨图适合"原因分析"，不适合"方案制定"。鱼骨图完成后还需要结合其他工具（如 PDCA、8D）来制定和执行方案。不要用鱼骨图来做所有事。
选择你团队最近一个"讨论了多次但没说不清楚"的问题，用 30 分钟做一次完整的鱼骨图分析：
关键收获：你会得到一张"原因可视化的团队协作图——每个人都能看到"问题如何从各个方向汇聚到这个问题"。