迭代评审结束时，会议记录里往往堆着几类内容：没达成的目标、对需求理解的分歧、临时冒出的新想法、流程上的抱怨。这些内容如果只留在纪要里，下一次迭代开始时团队仍然凭印象排期，反馈就断在了评审现场。可行的做法是把每条新增反馈先记成带来源、类型和影响对象的条目，逐条判定去向；未完成的工作按剩余价值、完成条件和依赖重新评估，不默认结转；最终以重新排序、补齐验收条件的候选条目进入下一次计划会，并保留反馈到条目的追溯关系。
要点总览（TL;DR）
- 评审现场把每条新增反馈记成带来源、提出人、影响对象和类型的条目，当天完成记录，避免只留在纪要里。
- 按目标未达成、需求理解偏差、新增需求、过程问题四类归并，不同类型对应不同去向，过程问题转为改进事项单独跟踪。
- 未完成工作逐项判断剩余价值、完成条件和依赖，给出继续、调整范围、拆分或关闭的结论，不默认结转到下一次迭代。
- 进入下一次迭代的输入以候选条目形式呈现，补齐验收条件并写明排序依据，在计划会上经团队确认后转为迭代工作项。
- 候选条目保留来源反馈编号，任取一条都能回溯到评审原始反馈；用完成检查清单核对去向、结论和追溯是否齐全。
核心做法：从评审记录到下一次迭代输入的完整链路
这条链路的目标是让评审产生的每一条信息都有明确去向，并在下一次计划会之前形成可排序、可验收的候选输入。整个过程分为记录、分类、重新评估、形成候选、建立追溯五步，每一步都要有可见的产出，而不是停留在口头共识。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 现场记录 | 评审中提出的意见、演示中暴露的问题、目标达成情况 | 逐条记录反馈，每条至少写清来源（哪次评审、哪个环节）、提出人、影响对象（目标、需求、工作项或流程）、类型 | 反馈条目清单 | 评审结束当天，所有发言要点均有对应条目，无口头遗留 |
| 2. 分类 | 反馈条目清单 | 按目标未达成、需求理解偏差、新增需求、过程问题四类归并，合并重复项，拆分混杂项 | 带类型的反馈条目 | 每条只有一个主类型，影响对象明确 |
| 3. 未完成工作重新评估 | 本次迭代未完成的工作项、对应反馈条目 | 逐项判断剩余价值、完成条件是否具备、依赖是否解除，给出继续、调整范围、拆分或关闭的结论 | 重新评估结论 | 每个未完成项都有结论和理由，无默认结转 |
| 4. 形成候选输入 | 重新评估结论、新增需求与偏差类反馈 | 把需要进入下一次迭代的内容写成候选条目，补齐验收条件，给出排序依据 | 下一次迭代候选输入清单 | 每条候选都有验收条件和排序理由 |
| 5. 建立追溯 | 反馈条目与候选输入 | 在候选条目上标注来源反馈编号，关闭无后续动作的反馈并写明原因 | 可查的追溯关系 | 任取一条候选输入，能回溯到评审中的原始反馈 |
记录环节要抓住四个字段
现场记录的质量决定后续分类是否顺畅。来源字段用于区分问题出自哪次评审、哪个演示环节，便于复盘时还原上下文；提出人字段保证后续补充和确认有人可找；影响对象字段说明这条反馈指向迭代目标、某条需求、某个工作项还是协作流程；类型字段在记录时可以先用自由描述，分类阶段再归并。四个字段齐全，反馈条目才具备被判定去向的基础。
四类反馈的处理方向不同
目标未达成的反馈需要回到迭代目标本身，判断是目标设定偏高、范围蔓延还是执行受阻，结论往往指向下一轮目标口径的调整。需求理解偏差类反馈要回到验收条件，确认是需求描述不清还是实现偏离，处理方式是补充说明或修正实现。新增需求类反馈先进入候选池，按价值和紧急度排序，不因为评审现场提出就自动插队。过程问题类反馈指向协作方式或流程环节，通常不进入迭代输入，而是转为改进事项单独跟踪。
未完成工作重新评估的三个判断项
剩余价值判断这项工作如果现在完成，对用户或业务目标还有多少贡献，价值已经消失的应当关闭而不是继续占用容量。完成条件判断需求描述、验收标准、设计稿等前置条件是否齐备，条件缺失的应先补条件再排期。依赖判断外部接口、其他团队交付或环境准备是否解除，依赖未解除的工作即使排进迭代也无法推进。三项判断都通过的未完成工作，才以候选条目形式重新参与排序，排序位置按重新评估后的价值确定，不沿用上一次的优先级。
候选输入的形态与排序依据
进入下一次迭代输入的候选条目应当具备标题、背景来源、验收条件、预估工作量和排序依据。排序依据可以综合用户价值、风险、依赖关系和学习价值，但要在计划会上说明理由，避免排序变成产品负责人的个人判断。候选条目在计划会上经过团队确认后才转为迭代工作项，确认过程本身也是对验收条件的一次校验。
在工具层面，这套链路可以借助工作项和迭代管理能力承载：评审反馈以工作项形式记录并标注来源与类型，未完成工作重新评估后调整状态或拆分，候选条目进入待排列表并在计划时关联到下一迭代。ONES 的工作项自定义字段、状态流转和迭代关联可以支持反馈条目到候选输入的追溯，具体配置按团队现有流程设定。
角色分工与各环节交付物
反馈停留在会议记录里，通常是因为没有人对“下一步”负责。把记录、归类、评估、确认、追溯五个环节的责任落到具体角色，并约定交付时点，转化才有节奏。
| 角色 | 关键动作 | 交付物 | 时限 |
|---|---|---|---|
| 产品负责人 | 对反馈条目做归类和优先级判断，确定哪些进入候选、哪些关闭，给出排序依据 | 带类型的反馈条目、候选输入清单及排序说明 | 评审后两个工作日内 |
| 迭代负责人 | 组织未完成工作的重新评估，召集相关成员逐项判断剩余价值、完成条件和依赖 | 未完成工作重新评估结论表 | 评审后三个工作日内 |
| 反馈提出人 | 补充反馈条目的背景和期望结果，确认归类与去向是否符合原意 | 反馈条目的补充说明与确认意见 | 归类完成后一个工作日内 |
| 团队成员 | 在计划会上逐条确认候选输入的验收条件与工作量，提出拆分或调整建议 | 计划会确认记录、调整后的候选条目 | 下一次计划会当场 |
| 迭代负责人（收口） | 检查追溯关系是否完整，关闭无后续动作的反馈并记录原因 | 追溯完整的候选输入清单 | 计划会结束后当天 |
产品负责人对归类和排序负责，意味着要承担取舍的解释工作，而不是把所有反馈都塞进候选清单。迭代负责人组织重新评估，重点在于让未完成工作的结论经过团队讨论，避免个人拍板。提出人参与确认，可以防止反馈在转述中失真，尤其是需求理解偏差类反馈，提出人的原意确认往往能直接澄清分歧。团队在计划会上的确认是最后一道关口，验收条件在这一步被实际检验。
时限设置的作用是让转化在下一个迭代启动前完成。评审后两到三个工作日是常见节奏，团队可以根据迭代长度调整，但应当固定下来形成惯例。交付物不必是独立文档，可以是工作项上的字段、状态和评论，关键是可查、可追溯。
示例：一次评审中目标未达成且反馈有分歧的处理
以下为演示情景，用于说明分歧如何收敛并形成下一次迭代输入。
某团队的两周迭代目标是完成订单导出功能并对接两个下游系统。评审时演示只跑通了一个下游系统，导出在数据量大时超时。产品负责人认为目标未达成，开发成员认为核心逻辑已经完成，超时属于性能优化范畴，双方对“完成”的口径产生分歧。评审中还提出两条新增反馈：业务方希望导出支持自定义字段，测试同学指出导出失败的提示信息不清晰。
分歧收敛：回到验收条件与目标口径
迭代负责人把讨论拉回迭代开始时约定的验收条件：导出功能需在两个下游系统上完成端到端验证，且在约定数据量下响应时间达标。对照验收条件，第二个下游系统未对接、超时问题均属于未满足项，目标未达成的结论成立。开发成员认可这一判断，同时提出超时问题需要先定位是查询还是文件生成环节，这成为重新评估的输入。
未完成工作的重新评估结论
第二个下游系统对接：剩余价值明确，完成条件具备，依赖对方接口已就绪，结论为继续，拆分为独立候选条目。导出超时问题：剩余价值高，但完成条件需要先做性能定位，结论为先安排定位任务，优化工作视定位结果再排。自定义字段需求：属于新增需求，价值中等，依赖导出主流程稳定，结论为进入候选池但不优先。提示信息不清晰：属于需求理解偏差，验收条件中未写明错误提示要求，结论为补充验收条件后作为小项排入。
最终候选输入与追溯
| 候选条目 | 排序 | 排序依据 | 来源反馈 |
|---|---|---|---|
| 完成第二个下游系统对接 | 1 | 直接支撑原迭代目标，依赖已解除 | 反馈-01 目标未达成 |
| 导出性能定位 | 2 | 阻塞导出可用性，需先定位再决定优化范围 | 反馈-02 目标未达成 |
| 补充导出失败提示的验收条件并实现 | 3 | 工作量小，影响用户排障体验 | 反馈-04 需求理解偏差 |
| 导出支持自定义字段 | 候选池 | 依赖主流程稳定，价值待业务方进一步确认 | 反馈-03 新增需求 |
这份清单在计划会上逐条确认，性能定位条目因工作量不确定被进一步拆分为定位与优化两个步骤。追溯关系保留在条目上，后续复盘时可以回看每条工作的来源。
完成检查：下一次迭代输入是否可用的判断标准
转化是否真正完成，可以用下面这份清单逐项核对。全部通过，说明评审反馈已经具备进入下一次迭代的条件；存在未通过项，应在计划会前补齐。
| 检查项 | 判断标准 | 通过 |
|---|---|---|
| 反馈去向完整 | 每条反馈都有明确去向：本次修正、重新评估、进入候选或关闭，关闭项写明原因 | □ |
| 未完成工作已重新评估 | 每个未完成项都有剩余价值、完成条件、依赖三项判断和结论，无默认结转 | □ |
| 候选输入具备验收条件 | 每条候选条目都有可检验的验收条件，条件缺失项已标注待补 | □ |
| 排序依据可说明 | 每条候选的排序位置有书面理由，计划会上可被质询 | □ |
| 分歧留有结论 | 评审中的分歧点记录了结论、依据和责任人，未决项标注了决策时点 | □ |
| 追溯关系可查 | 任取一条候选输入，能回溯到原始反馈条目和提出人 | □ |
清单中的“分歧留有结论”容易被忽略。分歧本身不是问题，问题在于分歧没有形成书面结论就进入下一轮，导致同样的争论在下次评审重演。记录结论时写清依据的是哪条验收条件或哪个目标口径，比只写“已达成一致”更有复盘价值。
当这份清单成为每次评审后的固定动作，反馈到迭代输入的转化就从依赖个人记忆变成可重复的流程，下一次迭代的输入质量也随之稳定。
常见问题
评审中提出的新增需求，是否应该直接排进下一次迭代？
不建议直接排入。新增需求先作为候选条目进入候选池，按用户价值、紧急度和依赖关系排序，在计划会上与未完成工作的重新评估结论一起参与排序。评审现场提出这一事实本身不构成优先理由，否则容易挤占原定目标的容量。若新增需求与本次迭代目标直接相关且工作量小，可以在评审结论中说明理由后优先安排，但同样要补齐验收条件。
未完成工作的剩余价值已经消失，应该关闭还是保留在候选池里？
剩余价值判断为已消失的工作，应当关闭并在条目上写明关闭原因，例如业务场景取消、需求被替代或用户不再需要。关闭不等于删除记录，保留条目和原因便于后续复盘时说明容量去向。若只是价值暂时不明确，可以留在候选池并标注待确认，由产品负责人在约定时点给出结论，避免长期悬置占用排序讨论的时间。
评审中分歧较大、当场无法形成结论时，转化流程怎么继续？
当场无法收敛的分歧，先记录分歧点、各方观点和所依据的验收条件或目标口径，指定决策人和决策时点，再继续处理其他反馈。分歧项在决策完成前不进入候选排序，避免带着未决条件排期。决策完成后补记结论和依据，并同步给提出人确认。这样处理可以保证转化流程不被单个分歧卡住，同时让分歧有明确的收口责任。
团队规模较小、角色兼任时，这套分工如何简化？
角色可以合并，环节不能省略。产品负责人与迭代负责人由一人兼任时，归类和重新评估仍要分开做：先完成反馈归类和排序判断，再组织团队对未完成工作逐项评估，两个动作的产出分别记录。提出人确认环节可以简化为在条目上回复确认，团队确认仍在计划会上完成。关键是保留每条反馈的去向结论和追溯关系，而不是保留固定的角色名称。
怎样判断反馈转化已经完成，可以进入下一次计划会？
可以用完成检查清单判断：每条反馈都有明确去向，关闭项写明原因；每个未完成项都有剩余价值、完成条件和依赖三项判断及结论；候选条目具备可检验的验收条件；排序位置有书面理由；分歧留有结论、依据和责任人；任取一条候选能回溯到原始反馈。全部通过即可进入计划会，存在未通过项应在会前补齐，而不是带到会上边排期边补条件。
