PMP迭代评审和回顾会议区别主要是检查对象不同：评审围绕产品结果和接下来的方向，回顾围绕团队的工作方式、质量和协作改进。评审不能缩减为单向演示，回顾也不是追责会；两者都应产生可落实的后续决定。
信息核对：2026年9月21日。概念参考PMI：敏捷如何运作；下文数字及项目情境为本站原创教学示例，不是官方试题或真实项目统计。
两种会议分别回答什么
评审讨论本阶段产出是否帮助实现产品目标、环境出现什么变化以及后续工作如何调整。回顾讨论工作过程中哪些安排有效、哪里出现障碍，以及下一阶段尝试什么改善。两种会议可能引用同一件事，却从不同层面分析。
| 对照项 | 迭代评审 | 迭代回顾 |
|---|---|---|
| 关注对象 | 产品结果与价值方向 | 工作过程与团队协作 |
| 主要输入 | 完成的成果、反馈、环境变化 | 工作事实、障碍、质量与协作记录 |
| 典型问题 | 接下来做什么更有价值 | 接下来怎样工作更有效 |
| 典型输出 | 对后续产品工作的调整 | 可执行且可检验的改进行动 |
| 常见偏差 | 只放幻灯片，不讨论反馈 | 只列抱怨，不落实行动 |
在Scrum中，两类事件有明确的定义和参与安排；在其他敏捷或混合项目中，名称和形式可能不同。应先识别采用的工作框架，再应用对应规定，不能把某种框架的事件要求扩写为所有项目都必须照搬的流程。
谁应该参加评审与回顾
评审需要能检视结果、提供业务反馈和讨论后续方向的人参与，包括团队和适当的关键相关方。回顾以负责共同工作的团队为中心，营造能够讨论真实问题的环境。外部专家是否受邀，应根据框架、目的和团队需要判断，而不是一律把所有领导都请来。
相关方参加评审并不意味着可以绕过产品管理或治理机制，现场直接向每位成员派新任务。应把反馈记录为待澄清事项，再由适当角色权衡优先级。想了解职责可结合PMP Scrum角色，避免把主持会议与独占决定权混为一谈。
回顾中的安全感也不等于没有责任。成员应能够说明事实和承担改进行动，同时不因提出流程问题受到羞辱。涉及纪律、安全或合规事件时，还需要相应正式渠道处理，不能把它们全部压缩为普通回顾讨论。
用同一个交付问题区分两种讨论
以下为原创案例。团队完成了订单查询功能，用户在评审时发现，真正高频的需求是查询异常订单而不是全部订单。评审应讨论使用场景、价值假设和后续产品工作，可能调整下一阶段的查询筛选能力。
同一阶段团队发现异常规则到开发末期才澄清，导致多次返工。回顾应分析为什么澄清太晚：业务代表不可用，还是没有在开始前讨论关键条件？后续行动可以是为高风险需求安排提前示例讨论，并观察返工是否减少。
两种讨论不能互相替代。只改善会议流程，却不调整偏离需求的产品方向，价值问题仍然存在；只把新功能加入列表，却不解决反复晚澄清，下一阶段仍可能返工。
评审怎样避免变成单向汇报
先说明本阶段想验证的目标和实际结果，再让相关方基于真实成果讨论，而不是把所有时间用在介绍团队做了多少工作。可以提前提供背景材料，把现场时间留给使用反馈、环境变化与下一步选择。
反馈越具体越有用。“不好用”需要继续追问任务、角色和受阻位置；“增加一个按钮”则需要澄清背后的业务目的。不要现场接受每个实现建议，也不要因为成果已经做完就拒绝讨论价值偏差。
未完成的工作应透明说明，不能用看起来完整的演示掩盖质量缺口。对完成状态有争议时，先核对验收标准和完成的定义。演示顺利不是自动获得验收或发布许可的证明。
回顾怎样从抱怨转向可验证的行动
先收集具体事件和影响，再寻找团队能够改变的因素。例如“沟通差”太宽泛，可以改为“接口变更在合并之后才通知，造成两次联调返工”。这样才有条件比较提前通知、契约校验或联合检查等改善方案。
不要一次列十几项没有负责人、没有容量的行动。可以选择少量影响大、能在下一阶段尝试的措施，写清负责人、完成时间和观察指标。这里的负责人用于推动落实，不代表所有问题都由一个人造成。
假设团队决定把接口示例提前一天确认，复查时应看缺少输入的次数、返工和等待是否改善，而非只确认“开过会”。若措施无效，要重新检查原因假设，不能仅要求成员更认真。
产品反馈和改进行动分别放在哪里
产品反馈可进入适当的产品工作管理流程，形成澄清、排序或拒绝的可追踪决定。过程改进则需要进入团队可见且有容量支持的行动列表，必要时反映在后续工作计划中。存放工具可以相同，但两类事项的目标和负责人应清楚。
对产品排序可以结合产品待办列表优先级。对协作改进可以结合PMP团队绩效提升。不能把回顾结论只存在会议纪要里，然后在下一次回顾重新抱怨同样的问题。
两种会议可以合并吗
需要先遵守采用框架的要求。Scrum把评审和回顾定义为不同事件，不能为了省时间取消其独立目的；其他工作方式即使安排在相邻时段，也应明确议题、参与者和结果，避免产品讨论挤掉过程改进。
若长期觉得会议没有价值，先检查准备、参与人员和决定落实，而不是立即删掉反馈机制。一次没有客户信息的演示和一次没有行动的回顾，确实容易浪费时间；问题在于检查与调整没有发生，不是“反馈”本身没有用。
怎样判断会议产生了实际效果
看后续产品选择是否吸收了重要反馈，看改进行动是否被实施并检验，也看团队能否更早暴露问题。参会人数、纪要长度和会议时长都不能单独证明有效。保留少量清楚的决定与结果，比堆积没有负责人认领的建议更有价值。
常见问题
迭代评审就是验收会吗？
不能简单等同。评审关注产品结果、反馈和后续方向，正式合同验收可能另有规定，应分别确认目的和权限。
回顾会议只讨论做得不好的地方吗？
不是。也应识别有效做法并决定如何保留，同时把需要改善的事项转成可执行行动，而非只列缺点。
用户提出新功能应该在回顾会上排序吗？
通常应进入产品反馈和待办事项管理流程。回顾重点是团队怎样更有效地工作，不替代产品优先级决定。
回顾行动没有完成应该怎么办？
先了解缺少容量、权限还是行动定义不清，再调整安排或升级障碍，不应只在下一次会议重复同一承诺。
来源与适用边界
- PMI：敏捷如何运作
- PMI：迭代回顾实践
- Scrum指南：评审与回顾
PMI官网知识库中的署名论文属于实践参考，不等同于当前考试通知。本站为第三方知识整理站，本文不替代PMP考试内容大纲，不承诺某一工具的固定考试题量；考务及认证要求以官方最新通知为准。