进度纠偏行动记录模板以“一条偏差一行记录”为基本单位，用固定字段把偏差事实、原因判断、纠偏措施、责任人和验证结果串成可追溯的闭环。下文先给出一张可直接复制到文档或表格工具中的空白表，再逐字段说明偏差原因、措施、责任人和验证结果的写法，并补充必填范围、完整填写示例与模板维护方法，适合项目管理者、PMO在周度或阶段性的进度纠偏中使用。
要点总览（TL;DR）
- 模板以“一条偏差一行记录”为单位，按“事实—原因—措施—责任—验证—关闭”排列字段，把偏差原因、纠偏措施、责任人和验证结果串成可追溯的闭环。
- 偏差原因先写分类（需求变更、资源不足、估算偏差、依赖延迟、质量问题、外部因素），再用一两句话区分直接原因与根因。
- 纠偏措施要写清动作、产出物和完成标准，责任人采用单一责任人加配合人，验证方式在制定措施时一并约定。
- 偏差编号、关联任务、偏差描述、原因分类、纠偏措施、责任人、截止日期、验证方式和关闭状态为必填，其余字段按偏差等级调整。
- 未完成验证的记录保持“待验证”状态，验证结果记录验证人、日期和结论后才关闭；模板需版本管理并定期归档复盘。
可复制空白模板：进度纠偏行动记录表
使用前先填表头，确定这份记录属于哪个项目、由谁维护、当前是第几版。表头信息建议固定在表格上方，避免每次新增记录都重复说明背景。
| 表头字段 | 填写内容 |
|---|---|
| 项目名称 | 填写项目全称或内部统一简称 |
| 记录人 | 负责维护本表的人员姓名或角色 |
| 更新日期 | 本次新增或修改记录的日期 |
| 版本 | 如V1.0、V1.1，字段调整时递增 |
表体按“事实—原因—措施—责任—验证—关闭”的顺序排列字段，一条偏差占一行。空白表如下，可直接复制后逐行填写：
| 偏差编号 | 关联任务/里程碑 | 计划值 | 实际值 | 偏差描述 | 偏差原因分类 | 原因说明 | 影响评估 | 纠偏措施 | 责任人 | 配合人 | 开始日期 | 截止日期 | 验证方式 | 验证结果 | 关闭状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DEV-001 | （示例）接口联调完成 | （示例）6月10日 | （示例）6月14日 | （示例）联调完成时间晚于计划4天 | （示例）依赖延迟 | （示例）上游系统接口文档6月8日才确认 | （示例）影响后续测试启动 | （示例）6月15日前完成剩余3个接口联调并提交联调报告 | （示例）张工 | （示例）李工 | （示例）6月11日 | （示例）6月15日 | （示例）联调报告通过评审 | （示例）6月15日评审通过，偏差消除 | （示例）已关闭 | （示例）无 |
填写提示：偏差编号按“模块缩写-序号”编排，便于检索；计划值和实际值使用同一口径，例如都填日期或都填完成百分比；偏差描述只写可核对的事实，原因判断放到原因字段；关闭状态建议限定为“待处理、处理中、待验证、已关闭”四种，避免出现含义模糊的自定义状态。
字段说明：偏差原因、措施、责任人、验证结果怎么写
模板能否发挥作用，取决于四个核心字段是否写到可执行、可核验的程度。以下逐项说明填写口径。
偏差原因：区分直接原因与根因
直接原因描述触发偏差的具体事件，根因说明为什么会发生。例如“上游接口文档延迟确认”是直接原因，根因可能归入“依赖延迟”。常见分类包括需求变更、资源不足、估算偏差、依赖延迟、质量问题和外部因素。填写时先写分类，再用一两句话说明判断依据，例如“分类：估算偏差；说明：原估算未计入数据迁移工作量，实际增加约5人天”。分类的作用是便于后续统计高频原因，说明则保证单条记录可回溯。
纠偏措施：写清动作、产出物和完成标准
措施要落到具体动作和可交付的产出物上。对比“加强跟进”和“6月15日前完成剩余3个接口联调，提交联调报告并通过评审”，后者明确了做什么、交付什么、什么算完成。一条偏差可能对应多项措施，建议按序号分行填写，每项措施都对应明确的截止日期。措施还应说明是否需要调整后续计划，例如压缩测试周期或增加人力，避免纠偏动作与整体计划脱节。
责任人：单一责任人加配合人
每条记录指定一名责任人，对措施完成和结果验证负责；配合人列出需要协同的角色或人员。责任人字段同时承担决策与执行两种角色时，可在备注中注明决策人，避免出现“多人负责、无人推进”的情况。责任人应是能够调动相应资源、对结果作出判断的人，而不是仅负责传递信息的人。
验证结果：事先约定口径，验证后再关闭
验证方式和判定标准应在制定措施时一并写明，例如“联调报告通过评审”“进度回到基线±1天以内”。验证结果记录验证人、验证日期和结论三项内容。未完成验证的记录保持“待验证”状态，不进入关闭。验证不通过时，在原记录下补充新一轮措施和截止日期，保留前一次验证结论，形成完整的纠偏过程。
必填与选填：哪些字段不能空
字段全部必填会推高填写成本，导致记录流于形式；关键字段留空则无法闭环。建议按下表划分必填与选填，并根据偏差等级适当调整。
| 字段 | 要求 | 理由 |
|---|---|---|
| 偏差编号 | 必填 | 唯一标识，便于检索和引用 |
| 关联任务/里程碑 | 必填 | 建立偏差与计划对象的对应关系 |
| 偏差描述 | 必填 | 记录可核对的事实，作为后续判断的基础 |
| 偏差原因分类 | 必填 | 支持按原因统计，识别高频问题 |
| 纠偏措施 | 必填 | 没有措施的记录无法推动偏差消除 |
| 责任人 | 必填 | 明确推进和验证的负责人 |
| 截止日期 | 必填 | 为措施设定可检查的时间边界 |
| 验证方式 | 必填 | 提前约定判定口径，避免事后争议 |
| 关闭状态 | 必填 | 反映记录当前所处环节 |
| 配合人 | 选填 | 协同关系简单的偏差可不填 |
| 影响评估细节 | 选填 | 影响范围明确时可简要填写或省略 |
| 备注 | 选填 | 用于补充背景、附件链接等辅助信息 |
按偏差等级调整必填范围是一种常见做法：影响关键路径或里程碑的偏差，影响评估、验证方式和配合人建议全部填写；影响较小、可在当周内消除的偏差，可只保留必填字段，影响评估写一句结论即可。等级划分标准由团队在模板说明中约定，并在表头或备注中标注等级，便于后续复盘时区分处理力度。
填写示例：一条完整偏差记录
以下示例为虚构情景，仅用于说明字段之间的对应关系。某系统集成项目的“接口联调完成”任务原计划6月10日完成，实际6月14日完成，项目经理据此登记一条纠偏记录。
| 字段 | 填写内容 |
|---|---|
| 偏差编号 | DEV-001 |
| 关联任务/里程碑 | 接口联调完成（属于“系统集成”阶段） |
| 计划值 | 6月10日完成 |
| 实际值 | 6月14日完成，滞后4天 |
| 偏差描述 | 联调完成时间晚于计划4天，剩余3个接口尚未联调 |
| 偏差原因分类 | 依赖延迟 |
| 原因说明 | 上游系统接口文档6月8日才确认，联调启动时间相应推迟；直接原因为文档确认延迟，根因是跨团队接口约定缺少提前冻结机制 |
| 影响评估 | 后续系统测试启动推迟4天，当前不影响整体上线日期 |
| 纠偏措施 | 1. 6月15日前完成剩余3个接口联调，提交联调报告；2. 6月16日起测试组按压缩后的测试计划启动，测试周期由10天调整为8天 |
| 责任人 | 张工（联调推进与结果验证） |
| 配合人 | 李工（上游接口支持）、测试组负责人 |
| 开始日期 | 6月11日 |
| 截止日期 | 6月15日 |
| 验证方式 | 联调报告通过评审，且测试按调整后计划启动 |
| 验证结果 | 6月15日联调报告评审通过，测试于6月16日启动，偏差消除 |
| 关闭状态 | 已关闭 |
| 备注 | 建议在下一阶段计划中增加接口文档冻结节点 |
核对这条记录与字段说明的一致性：偏差描述只陈述事实，原因字段区分了直接原因与根因，措施包含动作、产出物和完成标准，责任人单一且明确，验证方式在措施阶段即已约定，验证结果记录了日期和结论后才关闭。备注中的建议指向后续计划改进，可作为复盘输入，但不替代本条记录的关闭条件。
调整与维护：模板如何随项目演进
模板需要在项目中持续使用才有效，字段过多会拖慢填写，字段过少则无法闭环。建议从以下四个方面维护。
- 按项目规模与偏差频率裁剪字段。偏差数量少、影响范围小的项目，可合并计划值与实际值为一列“计划/实际”，省略配合人；偏差频繁、跨团队协作多的项目，保留完整字段，并增加偏差等级列。
- 做好模板版本与变更记录。字段增删、状态选项调整都应在表头版本号中体现，并在模板说明页记录变更日期、变更内容和原因。历史记录按原版本保留，避免新旧口径混用导致统计失真。
- 明确归档、复盘与关闭规则。已关闭记录按月或按阶段归档，复盘时按原因分类统计频次和平均关闭周期；未验证的记录不归档、不关闭，由记录人在进度例会上逐条说明进展。
- 与进度例会和周报衔接。例会前更新记录状态，例会上只讨论待处理和待验证的记录；周报引用本周新增偏差数、关闭数和超期未关闭数，不重复粘贴整张表。
当纠偏记录需要与任务状态、责任人和验证过程保持同步时，可以把表格放进支持任务关联与版本管理的协作工具中。例如在ONES中，项目计划与里程碑基线可用于对比计划与执行的偏差，从项目到任务的多层级管理支持自下而上的进度反馈；记录文档可通过ONES Wiki关联对应任务，页面版本可随时查看与回滚，便于保留模板和每条记录的修改历史。工具承载的是记录流转和状态同步，偏差原因判断、措施制定和验证结论仍由项目团队按上述口径完成。
常见问题
偏差原因分类和原因说明分别写到什么程度？
分类用于统计，说明用于回溯，两者分工不同。分类从需求变更、资源不足、估算偏差、依赖延迟、质量问题和外部因素中选一个最贴近的，便于后续按原因统计高频问题。原因说明用一两句话交代判断依据，并区分直接原因与根因：直接原因写触发偏差的具体事件，根因写为什么会发生。例如“上游接口文档延迟确认”是直接原因，“跨团队接口约定缺少提前冻结机制”是根因。说明写清依据即可，不必展开成完整分析报告。
一条偏差对应多项措施时，责任人和截止日期怎么填？
建议按序号分行列出每项措施，每项措施各自对应截止日期，责任人仍保持单一，由这名责任人对全部措施的推进和结果验证负责。如果某项措施实际由其他角色执行，把执行人写入配合人字段，并在备注中注明分工。这样既保留单一责任人的问责关系，也能看清具体动作由谁完成。措施涉及调整后续计划时，例如压缩测试周期，应把计划调整一并写入措施，避免纠偏动作与整体计划脱节。
验证不通过时，是修改原记录还是新增一条？
在原记录下补充新一轮措施和截止日期，保留前一次验证结论，不另起一条新记录。这样一条偏差的完整纠偏过程集中在一行记录里，复盘时能看清尝试过哪些措施、哪次验证未通过、原因是什么。关闭状态在补充措施后回到“处理中”，新一轮验证通过后再改为“已关闭”。如果验证不通过暴露出新的独立偏差，例如引发质量问题，则另开一条记录并关联原偏差编号。
小项目偏差很少，模板字段可以精简到什么程度？
偏差数量少、影响范围小的项目，可以把计划值与实际值合并为一列“计划/实际”，省略配合人和影响评估细节，保留偏差编号、关联任务、偏差描述、原因分类、纠偏措施、责任人、截止日期、验证方式和关闭状态这些必填字段。精简的前提是闭环链条完整：原因、措施、责任人、验证方式和关闭状态不能省。字段调整后更新表头版本号，并在模板说明中记录变更内容，避免后续统计口径不一致。
纠偏记录和进度例会、周报如何配合使用？
例会前由记录人更新各条记录的状态，例会上只讨论“待处理”和“待验证”的记录，逐条确认措施进展和验证安排。周报引用本周新增偏差数、关闭数和超期未关闭数三项汇总数据，不重复粘贴整张表。已关闭记录按月或按阶段归档，复盘时按原因分类统计频次和平均关闭周期，作为下一阶段计划改进的输入。记录表承担单条偏差的过程跟踪，例会与周报承担汇总和决策，两者分工明确可以减少重复填写。
