迭代评审会只剩演示，通常说明评审已经失去判断功能：团队展示做完了什么，业务方没有带着判断入场，评审结束也说不清迭代目标是否达成。原因往往同时落在目标、角色和证据口径上。下面按“症状界定—原因假设与排除—处置—验证预防”的顺序展开，帮助团队先确认问题范围，再用证据找到真实根因。
要点总览（TL;DR）
- 评审会流于演示的核心表现是会后说不清迭代目标是否达成，纪要只剩功能状态描述，缺少决策与反馈。
- 常见根因集中在四类：迭代目标模糊或未同步、业务方未被赋予反馈责任、评审材料只有演示、评审被当成例行汇报；用目标文档、参会名单、材料构成和历次纪要逐项验证。
- 处置按确认的根因匹配改动：议程先对照目标再演示，明确业务方反馈责任，准备验收标准与测试数据等可核对材料，未完成项逐项重新评估。
- 验证看连续两到三个迭代能否稳定产出目标达成结论、业务反馈记录和带负责人的后续动作，并用固定输入模板与结论抽查防止复发。
流于演示的典型症状与影响范围
判断一场评审会是否退化为演示，看会后能否回答一个具体问题：本迭代的目标达成了吗，依据是什么。如果答案只能落到“做了哪些页面、哪些接口、哪些功能点”，而说不清目标完成度、业务价值判断和遗留风险，评审就已经偏向演示。演示本身是必要环节，问题在于它成了唯一的信息载体和讨论内容。
典型表现可以从会中与会后两个时段观察。会中，团队按功能清单逐项讲解，业务方全程沉默，或只在结尾提出“界面颜色能不能改”这类礼貌性问题；没有人追问验收标准是否满足，也没有人对增量是否符合预期给出明确判断。会后，纪要里只有“已完成”“待联调”等状态描述，缺少决策、反馈和后续动作。
问题波及的环节通常不止会议本身。目标设定环节，迭代目标写得笼统或根本没有同步；参会角色环节，业务方缺席或到场但不承担反馈责任；信息准备环节，评审材料只有演示环境和功能列表；结论输出环节，没有记录谁在什么条件下做出什么判断。四个环节中任一环缺失，都会把评审推向单向汇报。
可以用下面这份自查清单快速界定范围，勾选“是”的条目越多，说明退化程度越深：
- 评审议程以功能演示顺序为主，没有“对照迭代目标”的独立环节。
- 参会名单以研发、测试为主，业务方或需求提出方缺席，或到场但不发言。
- 评审材料只有演示环境和功能清单，没有验收标准、测试结果或用户反馈。
- 评审结束后，无法用一句话回答迭代目标是否达成。
- 评审纪要只记录演示内容，没有反馈条目、决策结论和负责人。
- 历次评审的结论高度相似，后续动作在下个迭代中难以追溯。
范围界定清楚后，再进入归因。症状清单的作用是防止把个别会议的表现直接当成全局问题，也防止在原因未确认时就大改流程。
根因假设与逐项排除证据
评审流于演示的原因不能凭印象下结论。更稳妥的做法是先列出几类常见假设，再为每类假设找到可查证的证据来源，用证据确认或排除。下面四类假设覆盖了目标、角色、证据和流程惯性，实践中往往同时存在两到三类。
| 原因假设 | 验证证据 | 确认信号 | 排除依据 |
|---|---|---|---|
| 目标缺失：迭代目标模糊或评审前未同步 | 迭代目标文档、评审议程、会前通知 | 目标只有“完成某某模块”这类范围描述，议程中没有目标对照环节 | 目标文档有可判断的完成标准，且议程首项即为目标回顾 |
| 角色缺位：业务方未被邀请或未被赋予反馈责任 | 参会名单、会议邀请、反馈记录 | 业务方长期缺席，或到场但未被要求给出判断 | 业务方稳定参会，且会中有明确的反馈环节和记录 |
| 证据口径缺失：评审只依赖演示 | 评审材料构成、验收标准、测试结果、用户反馈 | 材料只有演示脚本和功能列表，无法核对完成质量 | 材料包含验收标准对照、测试结论或真实使用数据 |
| 流程惯性：评审被当成例行汇报 | 历次评审纪要、结论与后续动作记录 | 纪要只有状态描述，连续多个迭代没有决策类结论 | 历次评审均有明确结论、负责人和跟踪结果 |
验证时建议按“先查文档、再查记录、最后访谈”的顺序推进。先看迭代目标文档和评审议程，能快速判断目标缺失假设；再查参会名单和历次纪要，判断角色缺位与流程惯性；最后核对评审材料，判断证据口径问题。访谈只用于解释记录中看不出的原因，不作为主要证据来源。
需要注意区分相关与因果。例如业务方缺席与评审流于演示经常同时出现，但真正的原因可能是业务方从未被赋予反馈责任，缺席只是结果。排除某一假设时，要找到反向证据，而不是因为“感觉不像”。如果四类假设都只有部分证据，优先处理证据最充分、影响面最大的那一类，避免同时改动所有环节导致无法判断效果。
按根因采取的处置步骤
根因确认后，处置动作应围绕评审议程、角色责任和证据材料三条线展开，改动幅度与确认的根因匹配。只确认了目标缺失，就先补目标对照环节；角色缺位明显，就先解决参会与反馈责任。全面重写流程容易在短期内制造新的形式主义。
重设评审议程
把议程调整为三段：先对照迭代目标，逐项确认达成情况与偏差原因；再演示增量，演示只用于说明目标如何被满足；最后收集反馈并形成结论。目标对照放在最前，是为了让后续演示有判断基准，避免演示内容主导讨论。议程调整需要提前至少一个迭代与参会方沟通，说明每段的时间分配和产出要求，防止参会者仍按旧习惯准备。
明确参会角色与反馈责任
参会名单应覆盖需求提出方、产品、研发、测试，并为业务方设置明确的反馈责任：会前阅读评审材料，会中就增量是否符合预期给出判断，会后确认反馈是否被记录。反馈责任写进会议邀请和议程，比口头提醒更有效。业务方无法到场时，应指定代行判断的角色，避免评审在缺少业务视角的情况下走完流程。
准备可核对的证据材料
评审材料至少包含三类内容：迭代目标与完成标准、验收标准对照结果、测试或真实使用数据。演示作为辅助，用于展示关键路径和交互，不承担证明完成度的职责。材料在会前发出，给参会者留出阅读和准备判断的时间。证据材料的具体形式可以随团队习惯调整，关键是每项结论都能被核对。
重新评估未完成工作
评审中发现的未完成项，应逐项重新评估：是范围估计偏差、依赖阻塞还是优先级变化，再决定是否带入下个迭代。默认自动结转会把未完成项隐藏进新迭代，也会让评审失去对承诺的检验作用。重新评估的结论要记录原因和处置方式，作为下个迭代计划的输入。
处置过程中有两类风险需要提前交代。议程改动如果缺少沟通，参会者可能仍按演示准备，会议变成新旧流程的混合体；反馈责任如果只落在业务方一侧，研发团队不回应反馈，评审会从“没人提问”变成“提问后没有下文”。两类风险都指向同一个要求：每次调整都要有对应的记录和跟踪动作。
在记录与跟踪环节，团队可以把迭代目标、需求与验收标准放在同一套工作项中管理，让评审时的目标对照有据可查。ONES 敏捷研发管理解决方案支持产品负责人将需求规划至对应迭代，并在迭代计划会议上与团队就需求与验收标准达成一致，设计、研发、测试人员再用子任务拆分需求；测试工程师依据验收标准编写并执行测试用例，未通过用例可转为缺陷提交并指派修复。评审中形成的反馈和后续动作，可以借助 ONES Wiki 的文档关联任务能力与工作项对应起来，减少结论停留在会议纪要里的情况。这些能力承载的是目标、验收和反馈的留痕，评审本身的议程设计和角色责任仍需团队自己落实。
恢复效果的验证与复发预防
评审是否恢复判断功能，不看会议形式是否改变，而看会后能否产出可核对的三类信息：迭代目标达成情况、业务反馈记录、后续动作与负责人。连续两到三个迭代都能稳定产出，才说明调整生效。只开了一次有业务方发言的会，不足以证明问题解决。
验证信号可以逐项核对：
- 评审纪要能用明确语句回答每个迭代目标的达成、部分达成或未达成，并附依据。
- 业务方反馈有记录，包含判断意见和对应的工作项或文档。
- 每项后续动作有负责人和预期完成时间，并在下个迭代可追溯。
- 未完成项有重新评估结论，而非直接出现在下个迭代的计划中。
- 演示环节占用的时间明显少于目标对照和反馈讨论。
复发预防依靠机制而非提醒。固定评审输入模板，把迭代目标、验收标准对照、测试或使用数据列为必填项，缺少材料的评审顺延；定期抽查评审结论质量，重点看是否有决策类结论和可跟踪的后续动作；把上轮反馈的闭环情况纳入下个迭代的评审首项，让反馈处理本身接受检验。团队还可以在迭代回顾中复盘评审会的组织质量，把有效做法沉淀为团队约定。
需要说明适用条件：上述做法适合迭代周期稳定、有明确需求提出方的团队；如果业务方本身尚未确定，或迭代目标由外部统一制定，调整重点应放在证据材料和结论输出上，角色责任的改动需要与相关方协商后再推进。
常见问题
迭代目标由上级统一制定，团队还能调整评审议程吗？
可以调整议程结构，不必改动目标本身。把评审首项设为对照既定目标逐项确认达成情况与偏差原因，再进入演示和反馈环节。目标由外部制定时，团队的重点放在证据材料上：用验收标准对照、测试结论或真实使用数据说明完成度，让评审有可核对的判断依据。角色责任的改动涉及外部相关方，需要先协商再推进。
业务方确实抽不出时间参加评审，怎么避免评审又变成团队内部演示？
先明确反馈责任由谁承担，再解决到场形式。可以指定代行判断的角色，例如熟悉业务背景的产品人员，在评审中代表需求提出方给出判断；也可以要求业务方在会前阅读评审材料并提交书面意见，会上由主持人逐条读出并记录处理结论。关键是把反馈落到具体条目和负责人，而不是用“已同步业务方”概括。反馈记录要能在下个迭代追溯闭环情况。
评审材料准备到什么程度算够用？
判断标准是每项结论都能被核对。材料至少覆盖三类内容：迭代目标与完成标准、验收标准对照结果、测试或真实使用数据。演示作为辅助，用于展示关键路径和交互。材料在会前发出，给参会者留出阅读和准备判断的时间。形式可以随团队习惯调整，清单、表格或文档均可，重点是参会者能据此判断增量是否符合预期，而不是只看功能是否做出来。
未完成的工作能不能直接带到下个迭代？
建议逐项重新评估后再决定。先判断未完成的原因是范围估计偏差、依赖阻塞还是优先级变化，再决定是否带入下个迭代以及如何调整范围。默认自动结转会把未完成项隐藏进新迭代，评审也就失去了对承诺的检验作用。重新评估的结论要记录原因和处置方式，作为下个迭代计划的输入。
调整评审流程后，怎么判断改动是否真的生效？
看会后产出的信息质量，不看会议形式。连续两到三个迭代都能稳定产出三类信息，才说明调整生效：每个迭代目标的达成、部分达成或未达成结论及依据；业务方反馈记录及对应工作项；每项后续动作的负责人和预期完成时间。只开了一次有业务方发言的会，不足以证明问题解决。若结论仍以状态描述为主，需要回到根因排查，确认是议程执行不到位还是角色责任没有落实。
