未完成工作重评记录模板：空白表、字段与填写示例

未完成工作重评记录用一张表把上一迭代没做完的工作逐条过一遍，记录工作项、原计划、未完成原因、剩余工作量、重评结论、新排期与责任人、验收口径和评审确认。模板的核心是强制给出重评结论与依据，避免未完成工作默认自动结转到下一迭代。以下提供可直接复制的空白表、字段填写口径、必填与选填划分、一条完整示例，以及模板长期维护方法。

要点总览（TL;DR）

• 未完成工作重评记录的核心是逐条给出“继续、拆分、降级、关闭”四选一的结论，并写明结论依据，避免未完成工作默认自动结转到下一迭代。
• 空白表覆盖工作项、来源迭代、未完成原因、剩余工作量、重评结论、新排期、责任人与验收口径等字段，可直接复制到文档或表格工具中使用。
• 必填项围绕“接下来怎么办”设置，最小可用版本保留九项字段；工作项类型、原计划完成时间等分析类字段可按团队规模裁剪。
• 填写时先由原负责人说明原因与剩余工作量，评审人当场确认结论与依据，待确认项在下次评审前闭环。
• 模板每季度检查一次，按字段填写率和评审暴露的问题增删字段，调整后先试用一个迭代再固定。

可复制空白重评记录表

下表按“一条未完成工作一行”组织，可直接复制到文档或表格工具中。表头下方保留三行空白，便于一次评审多条工作项。评审结论与确认栏放在行尾，确保每条记录在离开评审会前都有明确判断和确认人。

序号	工作项名称	工作项类型	来源迭代	原计划完成时间	原负责人	未完成原因分类	原因说明	已完成部分	剩余工作量	重评结论	结论依据	新排期（迭代/时间）	新责任人	验收口径	评审人	评审日期	确认状态

表尾可增加一行汇总，记录本次评审的未完成工作总数、各重评结论的数量分布，以及评审主持人签字。汇总行帮助团队在迭代回顾时快速判断未完成工作是偶发还是集中出现在某类工作上。

每个字段记录什么、怎么填

字段填写口径统一后，不同人填出的记录才能横向比较。下表逐字段说明含义与判断标准，其中“重评结论”和“结论依据”是整张表的关键，填写时应先确定结论，再补齐支撑信息。

字段	记录内容	填写口径
工作项名称	未完成工作的简短标题	与工作项系统中的名称保持一致，便于回查；避免使用“那个需求”“上次说的任务”等指代。
工作项类型	需求、任务、缺陷、技术债等	按团队既有分类填写，用于后续统计哪类工作最容易跨迭代未完成。
来源迭代	该工作原所属的迭代	写明迭代编号或名称，跨多个迭代未完成时记录最早来源迭代，并在原因说明中补充延续情况。
原计划完成时间	原定完成的日期或迭代节点	照录原计划，不按实际情况修改，保留计划与实际的差距信息。
原负责人	原承担该工作的人	记录原责任人，便于区分“工作未完成”与“责任人已变更”两种情况。
未完成原因分类	需求变更、估算偏差、依赖阻塞、资源冲突、优先级调整、质量问题等	从团队约定的固定选项中选择一项主因；多项原因并存时选影响最大的一项，其余写入原因说明。
原因说明	对未完成原因的具体描述	写清发生了什么、何时发现、影响了多少工作量；避免只写“时间不够”“太忙”这类无法复盘的表述。
已完成部分	该工作已经交付的内容	描述可验证的产出，如“接口联调完成”“页面开发完成 3/5”，为剩余工作量估算提供基础。
剩余工作量	完成该工作还需投入的工作量	使用团队既有估算单位（人天、故事点或工时），并在填写说明中统一单位；由原负责人提出、评审人确认。
重评结论	继续、拆分、降级、关闭	四选一，必须明确。“继续”指按原范围进入新排期；“拆分”指拆成更小工作项分别安排；“降级”指移出当前迭代优先级；“关闭”指不再推进并说明原因。
结论依据	支持该结论的事实或判断	写清为什么这样处理，如“剩余工作量小于 1 人天且依赖已解除，继续”“需求方确认本期不再需要，关闭”。
新排期	结论为继续或拆分时的新迭代或时间	落到具体迭代编号或日期区间；结论为降级或关闭时填写“不排期”并说明去向。
新责任人	后续承担该工作的人	与原负责人不同时注明交接方式；结论为关闭时填写“无”。
验收口径	完成该工作的判定标准	写成可检查的条件，如“功能上线并通过回归测试”“文档评审通过”，避免“基本完成”这类模糊表述。
评审人、评审日期、确认状态	评审确认信息	评审人签字或填写姓名，确认状态填“已确认”或“待确认”；待确认的记录应在下次评审前闭环。

填写时先由原负责人逐条说明原因与剩余工作量，再由评审人给出结论并写明依据。剩余工作量建议在评审会上当场确认，避免会后各自估算导致排期失真。

必填项与选填项怎么区分

必填项保证每条记录可追溯、可决策；选填项服务于分析和复盘，团队规模小或迭代周期短时可以裁剪。下表给出划分建议。

类别	字段	理由
必填	工作项名称、来源迭代、未完成原因分类、原因说明、剩余工作量、重评结论、结论依据、新排期、新责任人、验收口径、评审人、评审日期	这些字段共同支撑“这条工作接下来怎么办”的判断，缺任何一项都会让结论失去依据或无法执行。
选填	工作项类型、原计划完成时间、原负责人、已完成部分、确认状态	用于统计分析和交接说明；团队已能在工作项系统中查到原计划与原负责人时，可只保留引用。

裁剪原则是：结论与执行相关字段必填，分析类字段按需保留。最小可用版本保留工作项名称、未完成原因分类、原因说明、剩余工作量、重评结论、结论依据、新排期、新责任人和验收口径九项，适合刚建立重评习惯的团队。随着记录积累，再补回工作项类型和原计划完成时间，用于分析估算偏差和未完成工作的分布。裁剪时保持字段含义不变，避免同一字段在不同迭代中口径漂移。

一条未完成工作的完整填写示例

以下示例为演示情景，用于说明字段之间的对应关系，不代表真实项目数据。

示例背景：某团队迭代 S12 中有一项“订单导出功能开发”未完成。该工作原计划在 S12 第 8 个工作日完成，实际开发到接口联调阶段时，因下游数据服务接口延期而阻塞，迭代结束时页面开发完成约六成。

字段	填写内容
工作项名称	订单导出功能开发
工作项类型	需求
来源迭代	S12
原计划完成时间	S12 第 8 个工作日
原负责人	开发 A
未完成原因分类	依赖阻塞
原因说明	下游数据服务接口原定 S12 第 5 个工作日提供，实际延期至迭代结束后，联调无法按计划开展；页面开发不受影响，已完成大部分。
已完成部分	导出页面开发完成，导出逻辑单元测试通过；接口联调未开始。
剩余工作量	3 人天（接口联调 2 人天，回归测试 1 人天）
重评结论	继续
结论依据	功能范围未变，下游接口已确认在 S13 第 2 个工作日提供，剩余工作量可在 S13 内完成，无需拆分或降级。
新排期	S13，接口提供后 3 个工作日内完成
新责任人	开发 A（继续负责，接口对接人不变）
验收口径	导出功能在测试环境通过回归测试，导出结果与源数据核对一致，产品负责人验收通过。
评审人	迭代负责人 B
评审日期	S12 迭代评审会当日
确认状态	已确认

这条记录的后续动作是：开发 A 在 S13 第 2 个工作日确认接口可用后启动联调，迭代负责人 B 在 S13 站会上跟踪该工作项状态；若接口再次延期，需在下一次重评中改为“拆分”或“降级”，并更新结论依据。示例体现了模板的使用要点：原因分类与原因说明对应，剩余工作量支撑结论，结论依据引用可核实的事实，验收口径写成可检查的条件。

当团队在 ONES 中管理迭代时，重评结论可以直接回写到工作项状态和迭代计划：ONES Project 支持将需求和相关任务规划至迭代、分配负责人，并提供任务工时统计与看板、燃尽图等进度工具，便于把“继续”的工作项放入新迭代后持续跟踪。评审记录本身可沉淀在 ONES Wiki 中，作为迭代回顾的材料。

模板的调整与长期维护方法

模板用久了容易出现两类问题：字段越加越多，填写负担上升；或者字段长期无人使用，记录流于形式。维护的重点是让字段与团队实际决策需求保持对应。

• 调整触发条件：连续两个迭代出现同一字段填写率低于一半，考虑删除或改为选填；某类未完成原因反复出现却无法在现有分类中归类，考虑新增选项；评审会上多次出现“结论依据写不清”的情况，考虑把结论依据拆成“事实”和“判断”两栏。
• 版本与字段变更记录：在模板文件顶部保留版本号和变更说明，记录每次增删字段的日期、原因和影响范围。字段改名时同步更新填写说明，避免新旧口径混用。
• 评审节奏：重评记录随迭代评审会同步完成，不单独增设会议；评审主持人负责检查每条记录是否都有结论和依据，待确认项在下次评审前闭环。
• 归档方式：按迭代归档，文件名包含迭代编号和评审日期；归档前汇总未完成工作数量与结论分布，作为迭代回顾的输入。跨迭代延续的工作项保留来源迭代信息，便于追溯。

建议每季度检查一次模板：统计各字段的实际填写情况，结合迭代回顾中暴露的问题决定增删。调整后的模板先在下一个迭代试用，确认填写负担和决策效果后再固定下来。

常见问题

未完成工作重评和直接结转到下一迭代有什么区别？

直接结转只改变工作项所属的迭代，不记录为什么没做完、还剩多少、接下来怎么处理。重评记录要求逐条给出结论：继续、拆分、降级或关闭，并写明依据。这样团队在迭代回顾时能区分偶发延期和系统性阻塞，也能避免范围不清的工作项反复占用新迭代容量。

团队刚开始做重评记录，字段太多填不完怎么办？

先用最小可用版本：工作项名称、未完成原因分类、原因说明、剩余工作量、重评结论、结论依据、新排期、新责任人、验收口径九项。工作项类型、原计划完成时间、原负责人、已完成部分、确认状态可以暂时省略，等记录习惯稳定后再补回，用于分析估算偏差和未完成工作的分布。

重评结论为“拆分”或“降级”时，原工作项怎么处理？

结论为拆分时，在记录中写明拆出的子工作项名称和各自排期，原工作项标记为已拆分并保留来源信息，便于追溯。结论为降级时，新排期填“不排期”并说明去向，例如回到需求池等待重新评估。两种情况下都要保留原负责人和原因说明，避免工作项在流转中丢失上下文。

重评记录应该在哪里保存和归档？

记录可以随迭代评审会同步完成，按迭代编号和评审日期命名归档，归档前汇总未完成工作数量与结论分布，作为迭代回顾的输入。如果团队使用 ONES，评审记录可沉淀在 ONES Wiki 中形成团队知识库；重评结论可回写到 ONES Project 的工作项状态和迭代计划，便于在新迭代中持续跟踪。

剩余工作量由谁估算，评审人需要逐条确认吗？

剩余工作量由原负责人提出，评审人在会上确认，避免会后各自估算导致排期失真。评审人重点确认结论与依据是否匹配：剩余工作量是否支撑“继续”的判断，依赖是否真的解除，验收口径是否可检查。对依据不清的记录标记为待确认，在下次评审前闭环。