鱼骨图怎么做：从问题拆解到在线绘制的入门方法

很多人第一次画鱼骨图会卡在两件事：一是不知道“主骨”到底要写什么（问题怎么写才算清楚）；二是原因越写越散，最后变成一张“抱怨清单”。

更实用的结论是：鱼骨图不是为了把原因写得越多越好，而是为了把问题的可能原因按类别拆开、逐层追问到可验证的层级，最后能落到“先查什么、先改什么”的行动上。你只要按固定步骤做，第一次也能画出能用的版本。

鱼骨图是什么？它解决的到底是哪类问题

鱼骨图（也叫因果图、石川图）是一种“从结果倒推原因”的分析方式：

• 鱼头：要解决的结果/问题（发生了什么、在哪里、影响多大）
• 主骨：从鱼头向左延伸的主干线
• 大骨（一级原因）：把原因按大类分组（常见 4M1E/5M1E 等）
• 小骨（二级/三级原因）：在大类下继续拆分，直到能验证、能改进

它最擅长处理的是“问题比较复杂、可能原因不止一个”的场景，让团队讨论更聚焦、更可追踪。

适用场景：什么时候用鱼骨图最划算

鱼骨图适合你遇到这些情况：

• 质量/缺陷类问题：返工率上升、客诉增加、某类缺陷频发
• 生产/交付异常：停机、交期延误、异常波动（良率、产能、时长）
• 流程/协作问题：需求反复、沟通断层、交接丢信息
• 项目复盘：同样的坑反复踩，想找“系统性原因”
• 数据指标异常：转化率掉了、留存下降、错误率上升

一个判断标准：当你怀疑“不是单点原因”，而是多个因素叠加，鱼骨图通常比拍脑袋更有效。

不适用场景：这些情况别硬画

鱼骨图也有边界，不适合：

• 问题定义不清：连“到底哪里不好、比什么变差、差多少”都说不清
• 已经有明确根因：比如已经定位到某个配置错误、某台设备故障
• 纯决策偏好问题：例如“我们要不要做 A 功能”这类战略选择
• 需要统计验证的复杂因果：比如涉及多变量、需要 A/B 实验或回归分析的场景（鱼骨图只能做假设归类，不能替代验证）

如果你发现团队一直在争论“到底算不算问题”，先把问题写清楚再开始画。

鱼骨图怎么做：从 0 到 1 的标准步骤（带清单）

下面这套步骤是最稳的“新手流程”，你可以照抄。

第 1 步：把“问题”写成可对齐的一句话

鱼头上的问题建议包含三类信息：

• 现象：发生了什么（缺陷/异常/指标变化）
• 范围：哪个产品/流程/时间段/地点/人群
• 影响：损失/风险/客户体验/成本/交期

示例写法：

• “3 月份 A 产线良率从 98% 降到 93%，主要集中在工位 X 的焊点缺陷”
• “App v2.3 发布后，登录失败率从 0.3% 上升到 2.1%，影响新用户”

避免写成：

• “良率不好”“最近不太顺”“用户体验差”（太抽象，没法拆原因）

第 2 步：选一个合适的一级原因分类（别纠结，但要一致）

常见分类有两种：

• 4M1E：人（Man）/机（Machine）/料（Material）/法（Method）/环（Environment）
• 5M1E：在 4M1E 基础上加 测（Measurement）（检验、量测、指标口径）

你也可以用更贴合业务的分类：

• 产品：需求/设计/研发/测试/发布/运营
• 服务：人员/流程/工具/信息/环境

原则是：一级分类要能覆盖原因来源，且互不太重叠。对新手来说，5M1E 足够通用。

第 3 步：先铺开一级原因，再往下拆二级/三级

建议按下面的顺序讨论：

1. 先把每个一级分类下，大家想到的原因“先放上去”（不急着争对错）
2. 对每条原因继续追问：
   • 这是事实还是猜测？证据是什么？
   • 如果它成立，会导致什么机制？
   • 能不能再拆成更具体、可检查的点？

拆到什么程度算够？用这个标准：

• 你能说出下一步去哪里查（数据、日志、现场、抽检、访谈）
• 你能写出可执行的改进动作（改流程、改参数、加校验、补培训）

如果还停留在“态度不认真”“管理不到位”这类泛化词，通常说明没拆够。

第 4 步：给每条原因加“验证方式”和“优先级”

鱼骨图画完只是“假设地图”，真正能落地需要两列信息：

• 验证方式（怎么证伪/证实）：
  • 查数据：某指标在某时间段是否同步变化
  • 查日志：错误码、异常栈是否集中
  • 查现场：设备参数、工位操作是否一致
  • 查样本：抽检对比、复测复现
• 优先级（先查谁）：
  • 发生频率高？
  • 影响大？
  • 验证成本低？
  • 可控性强？

你可以简单用“三档”就够：高/中/低。

第 5 步：把“根因候选”变成行动清单

最后输出三类结果：

• 要立即验证的 3–5 条原因（带负责人、截止时间）
• 已经确认的根因（证据链接/记录）
• 改进措施（预防复发：流程、标准、监控、培训、自动化）

到这一步，鱼骨图才算真正“做完”。

例子：用 5M1E 画一次“交付延误”的鱼骨图

假设问题是：

“最近两周项目交付平均延期 5 天，主要卡在上线前 48 小时。”

你可以这样拆：

• 人（Man）
  • 关键评审人临时请假/排期冲突（验证：评审日程、会议记录）
  • 交接不完整导致返工（验证：需求变更记录、返工工时）
• 机（Machine）
  • CI 构建时间过长（验证：构建耗时趋势、瓶颈步骤）
  • 测试环境不稳定导致反复重跑（验证：环境告警、失败原因分布）
• 料（Material）
  • 外部依赖接口文档不一致（验证：联调问题列表、接口差异）
  • 素材/配置迟到（验证：资源交付时间、阻塞记录）
• 法（Method）
  • 发布流程过多手工步骤（验证：发布 checklist、耗时拆解）
  • 需求冻结点不清晰（验证：冻结后变更次数）
• 测（Measurement）
  • “延期”的口径不一致（从什么时候算开始？）（验证：度量定义）
  • 缺少提前预警指标（验证：是否有里程碑燃尽/风险清单）
• 环（Environment）
  • 跨团队时区/节假日影响协作（验证：沟通响应时间）
  • 高峰期多人共享同一测试资源（验证：资源占用/排队）

然后你会发现：优先验证的可能不是“大家都很忙”，而是“发布流程手工步骤导致上线前 48 小时集中爆雷”这类更可操作的点。

常见误区：新手最容易踩的坑

• 把鱼骨图当成结论：画完就算结束，没有验证和行动清单
• 问题写得太宽：比如“质量不好”，导致任何原因都能往里塞
• 一级分类混用：一会儿按 5M1E，一会儿按部门，导致重复/遗漏
• 原因停留在情绪词：如“态度不好”“沟通差”，但说不出证据和改法
• 只找个人原因：忽略流程、工具、度量口径，复发概率很高

FAQ：关于“鱼骨图怎么做”的常见问题

1）鱼骨图一定要用 5M1E 吗？

不一定。5M1E 适合制造/质量/流程类问题；如果你在做互联网产品，也可以用“需求/设计/研发/测试/发布/运营”等更贴合业务的分类。关键是：分类要清晰、讨论时保持一致。

2）鱼骨图要拆到几级才算够？

拆到你能做两件事就够：能验证（知道去哪查、怎么复现）+ 能行动（能写出具体改进措施）。如果最后还停留在“管理不到位”，一般是不够的。

3）一个原因下面可以挂很多子原因吗？

可以，但建议控制可读性。经验上：二级原因先铺开，再挑 3–5 条最可能/最容易验证的继续深挖到三级。太多会把讨论拖垮。

4）鱼骨图和 5Why 有什么关系？

鱼骨图更像“把可能原因铺开并归类”；5Why 更像“沿着某条原因一路往下追问”。常见做法是：先用鱼骨图把范围铺开，再对优先级最高的几条原因用 5Why 深挖。

5）团队开会画鱼骨图，怎么避免跑题？

三个小技巧：

• 先把问题写清楚并固定在鱼头，开会过程中不随意改
• 每条原因都补一句“验证方式”，没有验证方式就先标注为猜测
• 设一个“停车场”区域：与本次问题无关的吐槽/想法先放停车场，避免打断主线

6）线上工具画鱼骨图要注意什么？

优先选能快速增删节点、拖拽调整结构、支持导出图片/链接的工具；同时最好能方便协作（评论/共享），避免一张图只存在某个人电脑里。

结尾：把图画出来只是开始

鱼骨图的价值不在“画得好看”，而在于让团队对问题形成同一张“可验证的原因地图”。画完之后，把优先验证的几条原因落到负责人和时间点上，你会明显感觉排查效率提升。

如果你想更省事地在线画一张结构清晰的鱼骨图，可以顺手用一下：https://yugu.cengxuyuan.cn/ 。