迭代收尾时，未完成事项需要逐条重新评估，而不是默认顺延到下一轮。本文提供一张可直接复制使用的未完成工作重评记录表，包含基本信息区、逐条明细区和汇总区，并配套字段说明、必填项划分、一条完整填写示例与模板维护方法。文中示例为演示情景；如果团队在ONES中管理迭代，也可以把重评记录与工作项、文档关联起来，便于后续交接和查询。
要点总览（TL;DR）
- 模板由基本信息区、逐条明细区和汇总区三部分组成，明细区逐条登记事项标识、来源、当前状态、未完成原因、剩余工作量、重评结论、去向与责任人。
- 必填字段覆盖迭代名称、重评日期、组织人、事项标识、来源、当前状态、未完成原因、剩余工作量、重评结论、去向和责任人；原计划、确认人、确认日期等可按团队需要选填。
- 重评结论在继续、拆分、降级、关闭中选择，并与剩余工作量匹配；剩余工作量较大或包含多个独立部分的事项适合拆分，优先级下降的事项可降级到需求池。
- 必填项暂时缺失时保留该行并标注待估算或待排期，指定承接人和完成时限，在同一张表上补全，不另起记录。
- 模板按迭代归档并单独维护版本号，每三到四个迭代复核一次未完成原因分布和占位内容，据此调整字段与重评时点。
可复制空白模板：未完成工作重评记录表
模板分为三个区块：表头记录本次重评的基本信息，明细区逐条登记未完成事项，表尾汇总数量与遗留风险。使用时将表格复制到文档或表格工具中，按行追加事项即可。
基本信息区
| 字段 | 填写内容 |
|---|---|
| 迭代名称 | |
| 迭代起止日期 | |
| 重评日期 | |
| 组织人 | |
| 参与人 |
逐条记录明细表
| 序号 | 事项标识 | 来源 | 原计划 | 当前状态 | 未完成原因 | 剩余工作量 | 重评结论 | 去向 | 责任人 | 确认人 | 确认日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||||
| 2 | |||||||||||
| 3 | |||||||||||
| … |
汇总区
| 汇总项 | 填写内容 |
|---|---|
| 未完成事项总数 | |
| 结论为“继续”的数量 | |
| 结论为“拆分”的数量 | |
| 结论为“降级”的数量 | |
| 结论为“关闭”的数量 | |
| 遗留风险说明 |
字段说明：每一列记录什么、怎么填
字段说明的作用是让不同的人填出同一口径的记录。下表逐列给出含义、填写口径与常见错误，填写时以本表为准。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 事项标识 | 该事项在团队工作项系统中的唯一编号或名称 | 填写系统编号，并在括号内附简短标题，便于脱离系统也能识别 | 只写标题不写编号，或多个事项共用同一编号 |
| 来源 | 事项最初进入本迭代的渠道 | 注明来自需求池、迭代计划、临时插入或缺陷修复等具体来源 | 统一写“迭代”导致无法追溯 |
| 原计划 | 本迭代对该事项的预期 | 写原定完成时间或原定交付内容，二者至少写一项 | 只写“按计划”，没有可核对的内容 |
| 当前状态 | 重评时事项的实际进展 | 用“未开始、进行中、待验证、被阻塞”等状态描述，并注明已完成比例 | 写“差不多完成”这类无法判断的表述 |
| 未完成原因 | 导致事项未按原计划完成的主要原因 | 从需求变更、估算偏差、依赖阻塞、资源变动、外部等待等类别中选择，并补一句具体说明 | 只写“时间不够”，没有类别和具体说明 |
| 剩余工作量 | 完成该事项还需要投入的工作量 | 以人天或小时为单位，给出估算值并注明估算依据 | 留空或写“待定”，导致后续无法排期 |
| 重评结论 | 对事项去向的处理决定 | 在继续、拆分、降级、关闭中选择一项，并与剩余工作量匹配 | 结论与剩余工作量矛盾，如剩余工作量大却直接关闭 |
| 去向 | 事项后续所在的位置 | 写明下一迭代、需求池、独立跟踪列表或不处理，并注明目标迭代名称 | 只写“下期”，没有具体迭代 |
| 责任人 | 承接该事项后续工作的人 | 填写具体姓名，结论为关闭时填写确认关闭的人 | 填写团队名称或留空 |
| 确认人 | 对重评结论负责确认的人 | 通常为迭代负责人或产品负责人，与责任人区分 | 责任人与确认人填同一人且无复核 |
| 确认日期 | 结论被确认的日期 | 填写实际确认当天日期 | 填写迭代结束日期而非确认日期 |
未完成原因的分类口径需要团队提前约定，避免同一情况被归入不同类别。需求变更指范围在迭代中被调整；估算偏差指原估算与实际投入差距明显；依赖阻塞指外部团队或系统未就绪；资源变动指人员调整或请假；外部等待指审批、数据或第三方响应未到位。分类之后补一句具体说明，记录才有复盘价值。
剩余工作量与重评结论需要对应起来：剩余工作量较小且方向明确的事项，通常选择继续并带入下一迭代；剩余工作量较大或包含多个独立部分的事项，适合拆分为更小的条目再安排；优先级下降但仍需保留的事项可以降级到需求池；确认不再需要或已被其他事项覆盖的事项选择关闭。结论不是对事项价值的最终判决，而是本轮收尾时的处理决定，后续仍可在需求池中重新评估。
必填与选填：哪些字段不能空
必填项保证记录可追溯、可交接；选填项用于补充背景。团队可以按需要增加选填字段，但不宜随意删减必填字段，否则记录在跨迭代查询时会失去参照。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 迭代名称 | 必填 | 确定记录所属的迭代范围 |
| 重评日期 | 必填 | 确定重评发生的时点 |
| 组织人 | 必填 | 便于后续追溯重评过程 |
| 事项标识 | 必填 | 唯一识别事项，关联原工作项 |
| 来源 | 必填 | 判断事项进入迭代的渠道 |
| 当前状态 | 必填 | 说明重评时的实际进展 |
| 未完成原因 | 必填 | 复盘与改进的直接依据 |
| 剩余工作量 | 必填 | 后续排期与容量规划的基础 |
| 重评结论 | 必填 | 记录处理决定 |
| 去向 | 必填 | 保证事项有明确落点 |
| 责任人 | 必填 | 明确后续承接人 |
| 原计划 | 选填 | 需要对比计划与实际时填写 |
| 确认人 | 选填 | 团队规模较大、需要复核时填写 |
| 确认日期 | 选填 | 需要记录确认时点时填写 |
| 参与人 | 选填 | 需要留存会议参与情况时填写 |
| 遗留风险说明 | 选填 | 存在跨迭代风险时填写 |
必填项缺失时的处理规则建议如下：重评会议当场无法确定剩余工作量的事项，先标注“待估算”并指定估算人和完成时限，在记录中保留该行，不因缺项跳过；去向无法确定的事项，默认进入需求池并注明“待排期”，由产品负责人在下一次需求梳理时处理；责任人暂时空缺的事项，由组织人指定临时承接人，避免事项无人跟进。缺项处理完成后，应在同一张表上补全，而不是另起一份记录。
填写示例：一条未完成事项的完整记录
以下为演示情景，用于说明各字段如何配合使用，不代表真实项目数据。
| 字段 | 示例填写 |
|---|---|
| 迭代名称 | 订单模块迭代 2024-08 |
| 重评日期 | 2024-08-30 |
| 组织人 | 迭代负责人 李某 |
| 事项标识 | ORD-231（订单导出增加按门店筛选） |
| 来源 | 迭代计划 |
| 原计划 | 8月28日前完成开发并提测 |
| 当前状态 | 进行中，开发完成约60%，未提测 |
| 未完成原因 | 依赖阻塞：导出服务依赖的门店数据接口由外部团队提供，接口联调延迟三天；同时存在估算偏差，原估算未计入联调时间 |
| 剩余工作量 | 约3人天（开发收尾1人天，联调与测试2人天） |
| 重评结论 | 继续 |
| 去向 | 下一迭代 2024-09，作为迭代计划内事项 |
| 责任人 | 开发 王某 |
| 确认人 | 产品负责人 张某 |
| 确认日期 | 2024-08-30 |
这条记录的推导过程是：先确认事项当前只完成部分开发，再定位未完成原因以依赖阻塞为主、估算偏差为辅；剩余工作量按开发收尾与联调测试分别估算后合计；由于方向明确、剩余工作量在下一迭代容量内，结论选择继续，去向写明具体迭代名称，责任人为原开发人员，确认人由产品负责人担任。对照字段说明可以核对：事项标识带编号和标题，来源具体，未完成原因有类别和说明，剩余工作量有单位和构成，结论与工作量匹配，去向有具体迭代，责任人与确认人分离，各字段口径一致。
如果同一事项的剩余工作量超过下一迭代可承载的范围，示例中的结论应改为拆分，把开发收尾与联调测试拆成两条记录分别安排；如果产品侧确认该筛选功能优先级下降，则结论改为降级，去向写需求池并注明重新评估的时间。结论变化时，剩余工作量、去向和责任人应同步调整，保持整行记录自洽。
调整与维护方法：让模板适配团队并长期可用
模板的价值在于持续使用。团队规模、迭代节奏和协作方式不同，字段可以裁剪，但需要遵循几条原则，避免记录变成一次性动作。
按团队情况增删字段
小团队、迭代周期较短时，可以合并“确认人”和“确认日期”，由组织人在会上统一确认；事项数量少时，“来源”可以简化为需求池与临时插入两类。团队规模较大、跨团队依赖较多时，建议保留“原计划”和“遗留风险说明”，并增加“依赖方”字段，记录外部团队或系统名称。增删字段的原则是：影响后续排期和责任归属的信息保留，仅用于描述背景的信息可以放入备注。每次调整字段后，同步更新字段说明表，保证模板与说明一致。
重评会议的时点与参与角色
重评通常在迭代结束前最后一个工作日或迭代评审会上进行，与迭代回顾分开安排：重评解决事项去向，回顾讨论过程改进。参与角色包括迭代负责人（组织并确认结论）、产品负责人（判断优先级与降级、关闭决定）、各事项责任人（说明进展与剩余工作量），涉及外部依赖时可邀请对接人参加。会议产出就是这张填写完成的记录表，散会后由组织人补齐缺项并归档。
版本与归档
建议按迭代归档，文件名包含迭代名称与重评日期，例如“订单模块迭代2024-08-重评记录”。模板本身单独维护版本号，字段调整时记录变更说明和生效迭代，历史记录保持原样，不随模板更新而改写。这样在跨迭代查询时，可以区分不同版本的字段口径。
如果团队在ONES中管理迭代，重评记录可以与工作项保持关联：迭代中的需求和相关任务可规划至迭代并分配负责人，任务工时统计可用于核对剩余工作量估算；重评完成后，把记录文档与对应工作项关联，后续交接时可以直接从工作项找到重评结论。ONES Wiki 支持文档关联任务，也支持插入工作项列表，适合承载这类按迭代归档的记录。工具承载的是登记与关联动作，重评结论本身仍需团队在会上逐条确认。
定期复核模板有效性
建议每季度或每三到四个迭代复核一次模板：统计未完成原因的分类分布，如果某一类别长期占比过高，说明该环节需要单独改进；检查必填项是否经常出现“待估算”“待排期”等占位内容，占位过多说明重评时点或参与角色需要调整；收集填写人的反馈，删去长期空白的选填字段。复核结论记录在模板版本说明中，作为下一次调整的依据。
常见问题
迭代结束时未完成的事项，可以直接顺延到下一迭代吗？
不建议默认顺延。未完成事项在进入下一迭代前需要逐条重新评估：确认当前实际进展，定位未完成原因，重新估算剩余工作量，再决定继续、拆分、降级还是关闭。直接顺延会把上一轮的估算偏差和依赖问题带入下一轮，下一迭代的容量安排也缺少可靠依据。重评记录表的作用就是把这次评估的过程和结论固定下来，让去向有据可查。
重评时剩余工作量估不出来，这一行还要保留吗？
保留。剩余工作量是必填项，但会上无法给出估算值时，可以先标注“待估算”，同时指定估算人和完成时限，记录行不跳过。缺项处理完成后在同一张表上补全，不另起一份记录。如果多个事项都出现待估算，说明重评时点偏早或参与角色不全，需要在下一轮调整会议安排。
重评会议和迭代回顾会议可以合并开吗？
两者解决的问题不同，建议分开安排。重评会议逐条处理未完成事项的去向，产出是填写完成的记录表；迭代回顾讨论过程改进和协作问题。合并开会容易让逐条确认被流程讨论挤占，导致结论草率或记录缺项。时间紧张时可以先开重评会确定去向，回顾会另择时进行。
团队规模变大后，模板需要增加哪些字段？
跨团队依赖增多时，建议保留“原计划”和“遗留风险说明”，并增加“依赖方”字段，记录外部团队或系统名称，便于后续跟进阻塞。需要复核机制时，把“确认人”和“确认日期”设为必填，与责任人区分开。增删字段后同步更新字段说明表，保证模板与说明口径一致，历史记录保持原样。
在ONES中管理迭代时，重评记录怎么和工作项衔接？
可以把重评记录文档与对应工作项关联，后续交接时从工作项直接找到重评结论。ONES Project 支持将需求和相关任务规划至迭代并分配负责人，任务工时统计可用于核对剩余工作量估算；ONES Wiki 支持文档关联任务，也支持插入工作项列表，适合承载按迭代归档的重评记录。工具承担登记与关联，结论仍需团队在会上逐条确认。
