项目复盘鱼骨图怎么做

很多人搜“项目复盘鱼骨图怎么做”，其实不是想学一个形式上的图，而是项目已经出了问题：进度延期、多人协作混乱、需求反复变更、返工太多、上线效果不理想，复盘会也开了，但最后只停留在“以后注意”四个字。

先说结论：项目复盘时，鱼骨图最有价值的地方，不是把责任分给谁，而是把“结果为什么会发生”拆成一条条可讨论、可验证、可改进的原因链。 只要你把问题定义清楚、主因分类合理、原因往下拆到可执行层，鱼骨图就会比泛泛而谈的会议纪要更有用。

项目复盘为什么适合用鱼骨图

项目复盘最常见的难点，不是没人参加，而是大家说的都对，但说完以后没有结构。

比如同样是“项目延期”，有人会说是需求改太多，有人会说是开发排期太满，有人会说测试介入太晚，还有人会说对齐机制不清楚。每个人都只看到自己那一段，最后结论就容易变成一句空话：沟通要加强。

鱼骨图适合项目复盘，原因有三个：

• 能先固定一个核心问题，避免讨论跑偏
• 能把多个原因并列展开，不至于只盯着某一个人或某一个环节
• 能继续往下追问，把“表面原因”拆成“可改进的原因”

所以如果你的复盘目标是找经验、找漏洞、找改进动作，而不是单纯记流水账，鱼骨图通常是值得用的。

项目复盘鱼骨图到底怎么画

如果你是第一次做，最实用的方式不是追求画得专业，而是按下面 5 步来。

第一步：先把复盘问题写成一个明确句子

鱼骨图的主干上，一定要写清楚“这次到底在复盘什么结果”。

不要写：

• 项目做得不好
• 协作有问题
• 执行不顺

这类表达太虚，后面拆不出有价值的内容。

更适合写成：

• 为什么这个项目比计划晚了 18 天上线
• 为什么项目上线后首周出现大量返工
• 为什么跨部门协作导致需求多次偏离目标
• 为什么这次活动项目最终效果明显低于预期

问题写得越具体，后面的原因越容易落地。

第二步：确定 4 到 6 个主分析维度

项目复盘不是制造业现场，不一定非要照搬 5M1E。对项目场景来说，建议直接用更贴近业务的分类方式。

常见可用维度有：

• 目标与范围：目标是否清晰，边界是否反复变化
• 需求与方案：需求是否稳定，方案是否过早拍板
• 人员与分工：角色是否明确，负责人是否缺位
• 流程与协同：评审、对齐、交接、反馈机制是否完整
• 时间与资源：排期是否合理，资源是否够，优先级是否冲突
• 风险与决策：风险是否提前识别，关键决策是否太晚

如果你的项目偏技术实施，也可以改成：需求、开发、测试、上线、协作、资源。

如果你的项目偏市场活动，也可以改成：目标、内容、投放、执行、协作、复盘数据。

关键不是维度名字高级，而是能不能把原因装进去，而且不互相打架。

第三步：在每个主因下面继续拆二级原因

鱼骨图最怕停在“大词”。

比如“沟通不充分”这句话，几乎所有复盘都会出现，但它本身没有什么执行价值。你要继续拆：

• 是需求评审时关键人没到场？
• 还是任务交接只口头说，没有书面确认？
• 还是改动通知发了，但没有同步到全部相关人？
• 还是会议有结论，但没人跟进落实？

再比如“排期不合理”，也要继续问：

• 预估时间是不是按理想情况算的？
• 是否忽略了联调、测试、返工时间？
• 是否同时并行了太多优先级相近的任务？
• 中间插单后有没有重排资源？

只有拆到这一步，鱼骨图才开始真正有用。

第四步：找出高频、可验证、可行动的关键原因

鱼骨图不是原因越多越好。画满整页不等于分析到位。

项目复盘里更重要的是筛选出三类原因：

• 反复出现的原因：不是这次偶发，而是过去也出现过
• 影响结果较大的原因：对延期、返工、效果差影响明显
• 可以推动改进的原因：不是“市场变了”这种难以控制的外部因素，而是团队内部能优化的部分

最后真正要落到行动上的，通常也就 3 到 5 项。太多，团队执行不过来；太少，又容易流于表面。

第五步：把鱼骨图转成复盘行动项

很多团队鱼骨图画完就结束了，这是最可惜的地方。

一张好的项目复盘鱼骨图，最后应该能转成具体动作，比如：

• 所有需求变更必须经过版本记录和负责人确认
• 跨部门项目在立项阶段就明确唯一项目 owner
• 排期模板加入测试、联调、验收缓冲时间
• 每周例会固定同步风险项，不只同步进度
• 上线前增加一次关键页面或关键流程走查

如果画完鱼骨图，行动项还写不出来，通常说明原因拆得还不够细。

一个简单的项目复盘鱼骨图模板

如果你不知道从哪下手，可以直接套这个基础结构：

主问题

为什么本次项目未按预期完成目标？

主因分类

1. 目标与范围
2. 需求与方案
3. 人员与分工
4. 流程与协同
5. 时间与资源
6. 风险与决策

每个分类下可以追问的方向

1. 目标与范围

• 立项时目标是否量化
• 成功标准是否统一
• 项目边界是否频繁变化
• 是否存在边做边改、越做越大

2. 需求与方案

• 需求来源是否统一
• 需求优先级是否明确
• 方案评审是否充分
• 关键假设是否验证过

3. 人员与分工

• 谁负责拍板，是否清楚
• 谁负责推进，是否明确
• 关键岗位是否缺人或临时兼任
• 出问题时是否出现职责真空

4. 流程与协同

• 评审、同步、验收流程是否完整
• 跨部门信息是否及时传递
• 交付标准是否一致
• 临时变更有没有同步到位

5. 时间与资源

• 工期预估是否偏乐观
• 是否存在资源抢占
• 是否给风险和返工预留时间
• 多项目并行是否影响专注度

6. 风险与决策

• 风险是不是太晚才暴露
• 关键决策是否拖延
• 遇到争议时是否缺少决策机制
• 是否有人持续维护风险清单

这类模板的意义不是替你直接得出结论，而是帮你更快进入分析状态。

项目复盘时，鱼骨图会议应该怎么开

很多人会画图，但不会组织讨论。结果要么一群人沉默，要么会议变成甩锅现场。

更稳的开法是这样的：

1. 先统一“复盘的问题是什么”

开会前先确认这次复盘聚焦哪一个结果。一次会议最好只抓一个核心问题。

比如：

• 这次先只复盘“上线延期”
• 下一场再复盘“上线后效果不及预期”

如果把所有问题混在一张鱼骨图里，最后通常会乱。

2. 先收集事实，再讨论判断

先列事实，再说观点。

比如：

• 需求在第 2 周和第 4 周分别发生过两次重大调整
• 联调开始时间比计划晚了 5 天
• 测试阶段发现高优先级问题 12 个
• 核心负责人在项目中后期被抽调去支持别的项目

事实能让讨论落地，避免大家只凭印象发言。

3. 由主持人不断追问“再往下一层是什么”

项目复盘里最重要的动作，就是避免大家停在表层原因。

例如：

• “为什么需求总变？”
• “是谁有权改？改完怎么通知？”
• “为什么测试介入晚？是流程规定没有，还是执行没做到？”
• “为什么 owner 没有顶住变更？是权限不足还是目标不清？”

这个过程很像把抽象词翻译成具体动作。

4. 最后明确责任人与改进截止时间

不然鱼骨图只会变成一张复盘纪念品。

建议每一个关键改进项都对应：

• 谁负责
• 何时完成
• 如何验证是否生效

这样鱼骨图才不只是“看起来认真”。

项目复盘里最常见的 5 个误区

误区一：把鱼骨图当成找人背锅的工具

如果会议氛围变成“是谁的问题”，大家就会自我保护，不会讲真实情况。

鱼骨图更适合分析机制、流程、协作、判断和资源问题，而不是简单把结果归到某个人身上。人可能是节点，但背后往往还有流程和组织原因。

误区二：原因全是大词

像“沟通不足”“执行不到位”“重视不够”“协同不畅”这种词，写上去很容易，但几乎无法直接改进。

你要继续往下问，直到它变成可以行动的句子。

误区三：把现象当原因

“项目延期”“返工太多”“需求太乱”很多时候只是表象。

真正需要找的是：

• 为什么延期
• 为什么返工
• 为什么乱

也就是再往下一层的原因链。

误区四：一次塞太多问题

一张图既想分析延期，又想分析预算超支，还想分析效果不好，最后一定会散。

更好的做法是一个核心问题一张图，必要时拆成多张。

误区五：复盘只看问题，不总结有效做法

项目复盘不只要找失败点，也要保留有效经验。

比如这次虽然延期，但某个协同方式明显更高效，或者某个阶段的评审方法明显降低了返工，这些也应该记下来。否则下次又得从头摸索。

哪些项目场景特别适合用鱼骨图复盘

鱼骨图不是所有复盘都必须用，但下面几类场景尤其合适：

• 项目延期明显：需要系统分析时间、资源、流程和决策问题
• 返工较多：需要追查需求、评审、交付标准是否有漏洞
• 多人协作复杂：需要看跨部门之间哪里断了
• 结果不达预期：需要从目标、执行、资源、判断等多维度分析
• 同类问题反复发生：适合通过结构化方式找共性原因

如果问题非常简单，比如某次交付就单一漏了一项内容，未必需要专门画鱼骨图。但只要事情涉及多人、多环节、多因素，鱼骨图通常都值得用。

项目复盘鱼骨图和 5Why 要不要一起用

可以，而且很多时候一起用更有效。

鱼骨图适合先把“可能的原因范围”摊开，5Why 适合对其中某一个关键分支继续深挖。

比如你在鱼骨图里发现一个主因是“需求频繁变更”，接下来就可以继续问：

1. 为什么需求频繁变更？
2. 为什么需求评审阶段没有提前识别？
3. 为什么关键决策人没有在评审时到场？
4. 为什么没有明确评审通过标准？
5. 为什么项目启动时没有设定需求冻结节点？

这样比只画鱼骨图、不继续深挖，更容易找到真正该改的地方。

如果你想更快落地，可以这样做

如果你正在准备下一场项目复盘，不妨直接照这个顺序执行：

1. 先确定一个复盘问题，不要一口气复盘全部
2. 拉出 4 到 6 个主因维度
3. 先收集事实，再填原因
4. 对高频原因继续往下追问一层
5. 只保留最关键的 3 到 5 个改进项
6. 明确负责人、时间和验证方式

这样做，哪怕你的图画得不复杂，也会比一场泛泛而谈的复盘会更有结果。

如果你想先把结构快速搭起来，再边讨论边补充，也可以直接用 鱼骨图在线制作工具 先生成骨架。对于项目复盘这种多人讨论场景，先把主问题和主因分类摆出来，往往比空白文档里临时整理更省时间。

常见问题

项目复盘鱼骨图一定要很正式吗？

不一定。真正有用的是结构清楚，而不是图画得多漂亮。哪怕先用最简单的文本结构把主干和分支列出来，只要原因拆得够具体，也完全可以。

项目复盘适合几个人一起做？

通常 3 到 8 个核心相关人最合适。人太少，信息不全；人太多，讨论容易发散。关键是让真正参与项目关键节点的人到场。

项目复盘鱼骨图和普通复盘模板有什么区别？

普通复盘模板更像回顾流程，鱼骨图更强调“结果为什么发生”。如果你这次更想找原因和改进点，鱼骨图会更强。

项目复盘时，原因写多少合适？

不是越多越好。先尽可能列，再筛选真正关键、可行动的原因。最后能推动改进的，通常是少数几个重点项。

画完鱼骨图之后下一步做什么？

下一步不是存档，而是形成行动项。没有负责人、截止时间和验证标准的复盘，通常很难真正改变下一个项目。