未完成工作重评记录应包含哪些信息：空白模板与填写规范

2026年11月4日

未完成工作重评记录用于在迭代收尾时逐条处理遗留事项，核心信息包括事项标识与来源迭代、原承诺内容、未完成原因、当前完成度与剩余工作量、重评结论、重评后的目标迭代与责任人、风险与依赖，以及评审人与评审日期。未完成工作需要重新评估后再决定去向，不宜默认自动结转到下一迭代。下面给出一张可直接复制使用的空白表，并说明字段口径、必填规则、填写示例与维护方法。

Table of Contents

要点总览（TL;DR）

未完成工作重评记录按“基本信息—事项明细—未完成原因与影响—重评结论—评审确认”五段组织，逐条处理迭代遗留事项，重评后再决定去向，不默认自动结转。
必填字段包括事项编号、事项标题、来源迭代、未完成原因分类与说明、处理方式、新责任人、目标迭代、评审人与评审日期；拆分、关闭、降级时另有条件必填项。
处理方式在结转、拆分、降级、关闭中四选一，目标迭代、新责任人与计划完成时间需相互匹配。
完成度、剩余工作量等量化字段须团队统一口径，同一团队各迭代保持一致，汇总数据才可比较。
模板可按团队规模与迭代节奏增减字段，字段变更需记录版本，历史记录保持原样。

可复制空白模板：未完成工作重评记录表

模板按“基本信息—事项明细—未完成原因与影响—重评结论—评审确认”组织。复制到文档或表格工具后，每个迭代使用一份，逐条填写遗留事项。表中“填写提示”列可在正式使用时删除。

分区	字段名	填写提示
基本信息	迭代名称	填写被重评事项所属的迭代，如“2024 第 8 迭代”
	评审日期	填写重评会议或评审完成的日期
	评审人	填写主持或负责确认结论的人
	参与角色	列出参与评审的角色，如产品负责人、开发负责人、测试负责人
	记录人	填写整理本表的人
事项明细	事项编号	沿用原工作项编号，保持可追溯
	事项标题	填写原事项名称，避免只写编号
	事项类型	需求、任务、缺陷、技术改进等
	原承诺范围	简述原计划交付的内容与验收口径
	当前状态	未开始、进行中、待测试、待验收等
	完成度	按团队统一口径填写百分比或阶段
	剩余工作量	填写剩余人天或故事点，注明单位
	原估与实际	原估算值与已投入量对照，注明单位
未完成原因与影响	未完成原因分类	从固定选项中选择，如需求变更、估算偏差、依赖阻塞、资源不足、优先级调整
	原因说明	用一两句话说明具体情况，避免只选分类不写事实
	影响范围	说明对关联需求、上线计划、其他团队的影响
重评结论	处理方式	结转、拆分、降级、关闭，四选一
	结论依据	说明为何选择该处理方式
	目标迭代	填写承接该事项的迭代；选择关闭时填写“不适用”
	新责任人	填写重评后负责推进的人
	新计划完成时间	填写日期，与目标迭代节奏一致
风险与评审确认	风险与依赖	列出外部依赖、技术风险、资源缺口
	评审确认	评审人与责任人分别确认
	确认日期	填写确认完成的日期

正式使用时，可将“事项明细”到“重评结论”之间的字段做成一行一条记录，表头固定，便于后续筛选和汇总。

字段说明：每个字段记录什么、怎么填

字段口径统一，重评记录才能在迭代之间横向比较。以下按字段类别说明含义与填写方式。

标识类字段

事项编号沿用原工作项编号，不重新编号，保证从原迭代到新迭代可以追溯。来源迭代写在基本信息区，若一张表只记录一个迭代的遗留事项，可省略逐条重复。事项类型使用团队固定的几类取值，避免同一类工作出现多种叫法。

状态与量化字段

完成度与剩余工作量需要团队事先约定口径。常见做法是完成度按阶段取值（如 0%、30%、70%、90%），剩余工作量统一用人天或故事点，并在表头注明单位。原估与实际并列填写，用于识别估算偏差。口径一旦确定，同一团队的各迭代保持一致，否则汇总后的数据无法比较。

未完成原因分类

建议使用固定选项，便于按迭代汇总阻塞来源：

需求变更：范围在迭代中发生调整
估算偏差：原估算明显偏离实际投入
依赖阻塞：等待外部团队、接口或环境
资源不足：人员变动、并行任务挤占
优先级调整：资源被调往更高优先级事项
其他：写明具体情况

选择分类后仍需填写原因说明，分类用于统计，说明用于还原事实。

重评结论字段

处理方式的选项集合为结转、拆分、降级、关闭，判定依据如下：

处理方式	适用情形	需同步填写的字段
结转	事项仍然有效，剩余工作量可在下一迭代完成	目标迭代、新责任人、新计划完成时间
拆分	范围较大或部分内容可先行交付	子项清单、各子项目标迭代与责任人
降级	优先级下降，暂不进入近期迭代	降级理由、重新评估时点
关闭	需求取消、已被其他事项覆盖或不再需要	关闭理由、确认人

目标迭代、新责任人与计划完成时间三者需要相互匹配：目标迭代决定时间窗口，计划完成时间应落在该迭代周期内，责任人应是实际推进该事项的人。

必填与选填：哪些字段不能空

重评记录的最低完整性要求是：每条遗留事项都能被识别、解释和追责。据此划分三档字段。

必填字段

事项编号、事项标题：保证事项可识别、可追溯
来源迭代：说明事项从哪个迭代遗留
未完成原因分类与原因说明：解释为什么没有完成
重评结论（处理方式）：承载重新评估的判断结果
新责任人：明确后续由谁推进
目标迭代：明确事项去向，关闭时填“不适用”
评审人与评审日期：确认结论经过评审

选填字段

完成度、剩余工作量：事项尚未开始时可不填，但进入执行后应补
原估与实际：用于分析估算偏差，小团队可简化
影响范围：跨团队依赖较多时填写价值更高
参与角色、记录人：团队人数少时可合并填写

条件必填字段

处理方式为“拆分”时，必填子项清单及每个子项的目标迭代
处理方式为“关闭”时，必填关闭理由与确认人
处理方式为“降级”时，必填降级理由与重新评估时点
存在外部依赖时，必填风险与依赖说明

缺失字段的处理规则建议写进团队约定：评审会上当场补齐必填项；条件必填项在结论确定时同步填写；事后补录需注明补录日期与补录人，避免记录被静默修改。

填写示例：一条遗留事项的完整记录

以下为演示情景，用于展示字段之间的对应关系。

背景：某团队在“2024 第 8 迭代”中承诺完成“订单导出支持按时间范围筛选”，迭代结束时接口联调尚未完成，事项遗留。

字段	填写内容
迭代名称	2024 第 8 迭代
评审日期	2024-05-17
评审人	产品负责人
参与角色	产品负责人、开发负责人、测试负责人
事项编号	ORD-231
事项标题	订单导出支持按时间范围筛选
事项类型	需求
原承诺范围	导出页增加起止时间筛选，导出结果与筛选条件一致
当前状态	进行中
完成度	70%
剩余工作量	3 人天
原估与实际	原估 5 人天，已投入 4 人天
未完成原因分类	依赖阻塞
原因说明	依赖的数据服务接口延期两天交付，联调时间被压缩
影响范围	影响运营侧月度对账的导出效率，不阻塞本期上线
处理方式	结转
结论依据	需求仍然有效，剩余 3 人天可在下一迭代完成，无需拆分
目标迭代	2024 第 9 迭代
新责任人	后端开发 A
新计划完成时间	2024-05-30
风险与依赖	数据服务接口需在 5 月 24 日前完成联调
评审确认	产品负责人、后端开发 A 已确认
确认日期	2024-05-17

结论推导过程：该事项范围明确、剩余工作量可控，选择“结转”即可；若剩余内容包含“导出格式改造”等独立部分，则可选择“拆分”，并为子项分别指定目标迭代。示例中的完成度、剩余工作量与原因说明相互印证，评审人可据此判断结转是否合理。

调整与维护：让模板适配团队并持续可用

模板需要随团队规模和迭代节奏调整，同时保持关键字段稳定，才能长期用于追溯。

按团队情况增减字段

小团队（十人以内）：可合并参与角色与记录人，简化原估与实际，保留必填字段即可
多团队协作：增加“关联团队”“依赖事项编号”字段，便于跨团队追踪
两周迭代：计划完成时间精确到日期；月度迭代可精确到周
缺陷占比较高的团队：在事项类型中单列缺陷，并增加“严重程度”字段

评审时点与参与角色

重评会议通常安排在迭代评审或迭代回顾之前，由产品负责人主持，开发、测试负责人参与，对每条遗留事项给出处理方式。会议时长按遗留事项数量控制，逐条过表，当场补齐必填字段。

归档、检索与追溯

每个迭代的重评记录单独存档，文件名包含迭代名称与日期。检索时以事项编号为线索，可串起原迭代记录、重评记录与新迭代执行情况。跨迭代追溯的重点是同一事项编号在多次重评中的处理方式变化。

模板版本与字段变更

字段增删、选项调整需记录版本号、变更日期、变更人和变更原因。已归档的历史记录保持原样，新版本从下一个迭代开始使用，避免同一迭代内口径不一致。

在协作工具中承载重评记录

当遗留事项较多、跨迭代追溯频繁时，可将重评记录放到协作工具中承载。以 ONES 为例，ONES Project 支持将需求和相关任务规划至迭代并分配负责人，团队可用工作项状态与属性记录处理方式、目标迭代等结论；任务工时统计与看板、燃尽图可用于核对完成度和剩余工作量。评审结论与原因说明可通过 ONES Wiki 文档关联任务留痕，并在迭代回顾时结合报表复盘遗留来源。具体字段配置与状态流转方式，需结合团队实际流程在工具中确认。

常见问题

未完成事项在重评时选择“结转”，还需要重新估算剩余工作量吗？

需要。结转的前提是剩余工作量能在目标迭代内完成，因此重评时应核对原估算与实际投入，重新确认剩余人天或故事点，并据此判断目标迭代是否合适。若重新估算后发现剩余量超出单个迭代容量，应改为“拆分”，把可先行交付的部分单独列出。

重评记录和迭代回顾会的记录是什么关系，能否合并成一份？

两者关注点不同。重评记录逐条处理遗留事项，输出的是每条事项的处理方式、目标迭代与责任人；迭代回顾记录关注流程改进与经验总结。可以安排在同一次会议中完成，但建议分开留档：重评记录按事项编号可追溯，回顾记录按改进项跟踪。合并成一份时，容易让事项去向被改进讨论淹没，后续检索不便。

遗留事项较多时，逐条填写重评记录会不会负担过重？

可以按影响程度分层处理。对影响上线计划或跨团队依赖的事项，完整填写全部必填与条件必填字段；对影响有限的小任务，可只填事项编号、未完成原因分类、处理方式与新责任人。分层规则应写进团队约定并保持稳定，避免同一类事项在不同迭代中记录详略不一，影响汇总比较。

重评结论确定后，事项在协作工具中如何与记录对应？

常见做法是保留原工作项编号，在工具中更新状态、目标迭代与负责人，并把重评记录文档与对应工作项关联，形成从原迭代到新迭代的追溯链。以 ONES 为例，ONES Project 支持将需求和相关任务规划至迭代并分配负责人，团队可用工作项状态与属性记录处理方式、目标迭代等结论；评审结论与原因说明可通过 ONES Wiki 文档关联任务留痕。具体字段配置与状态流转方式，需结合团队实际流程在工具中确认。