进度纠偏计划模板的核心是一张纠偏行动记录表，用来把偏差事实、原因、措施、责任人、完成时间和验证结论放在同一条记录里。字段覆盖偏差描述与量化、原因分析、纠偏措施、责任人、计划完成时间、验证方式与验证结果、状态与关闭结论。适用范围是项目执行阶段已发现进度偏差、需要启动纠偏的场景；填写顺序建议先写偏差事实与影响，再写原因和措施，最后用验证结果证明偏差已消除或受控。
要点总览（TL;DR）
- 模板核心是一张纠偏行动记录表，字段覆盖偏差描述与量化、影响范围、原因分析、纠偏措施、责任人、计划完成时间、验证方式、验证时间、验证结果、状态与关闭结论。
- 启动纠偏时必填记录编号、偏差描述与量化、纠偏措施、责任人和计划完成时间；验证类字段在记录关闭前必须补齐。
- 填写顺序建议先写偏差事实与影响，再写原因和措施，最后用验证结果证明偏差已消除或受控。
- 一条记录对应一个可独立验证的偏差，原因写到可归因的层面，措施用动词开头写清做到什么程度，责任人填唯一人员。
- 模板可按项目规模裁剪字段，但建议保留偏差描述、措施、责任人与验证结论四项，并按状态流转更新与归档复盘。
可复制空白纠偏计划模板
下面这张表可以直接复制到文档或表格工具中使用。表头分为两段：左侧记录“计划”，说明偏差是什么、准备怎么纠；右侧记录“验证”，说明纠偏是否真的生效。一条纠偏行动占一行，同一项目有多条纠偏时向下复制行即可。
| 纠偏计划（计划段） | 验证与关闭（验证段） | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 记录编号 | 偏差描述与量化 | 影响范围 | 原因分析 | 纠偏措施 | 责任人 | 计划完成时间 | 验证方式 | 验证时间 | 验证结果 | 状态与关闭结论 |
使用时有三个结构要点。第一，计划段与验证段在同一行内左右对应，避免措施写在一边、验证结论记在另一处导致对不上。第二，一条记录只对应一个可独立验证的偏差，偏差包含多个成因时拆成多条记录，分别指定责任人。第三，记录编号用于在会议纪要、周报和项目计划中互相引用，编号规则可按“项目简称-序号”自行约定。
字段说明：每个字段记录什么
字段的含义和填写口径决定了模板能否被不同人填出一致的结果。下表按偏差、原因与措施、责任人与时间、验证与关闭四组说明。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 记录编号 | 该条纠偏记录的唯一标识 | 按项目约定的编号规则填写，便于跨文档引用 |
| 偏差描述与量化 | 实际进度与计划进度的差距 | 写清对象、计划值、实际值和差距，例如“模块A联调计划第8周完成，实际第10周仍未开始，滞后约2周” |
| 影响范围 | 偏差波及的后续任务、里程碑或交付物 | 列出受影响的节点和依赖方，说明是否影响最终交付日期 |
| 原因分析 | 导致偏差的具体成因 | 写到可归因的层面，区分内部原因与外部条件，避免只写“资源不足”这类笼统表述 |
| 纠偏措施 | 为消除或控制偏差采取的具体动作 | 用动词开头写清做什么、做到什么程度，例如“增派2名开发人员，将模块A联调压缩至5个工作日完成” |
| 责任人 | 对该条措施结果负责的唯一人员 | 填具体姓名或岗位，一条记录对应一名责任人，协作人员可写在措施中 |
| 计划完成时间 | 措施应完成的日期 | 填具体日期，与项目计划中的任务时间保持一致 |
| 验证方式 | 用什么方法确认偏差已消除或受控 | 写可核验的方式，例如“核对模块A联调完成记录与测试报告”“对比更新后的计划与实际进度” |
| 验证时间 | 执行验证的日期 | 填实际验证日期，通常不早于计划完成时间 |
| 验证结果 | 验证后的事实结论 | 写清验证看到的结果，例如“联调已于第11周周三完成，进度差距缩小至3天”，避免只写“已完成” |
| 状态与关闭结论 | 记录当前所处阶段及是否关闭 | 按“待启动、进行中、待验证、已关闭、转升级”填写，关闭时写明结论依据 |
原因分析字段需要特别注意。偏差原因通常分为计划估算偏差、执行延误、资源变动、外部依赖延迟几类，填写时先判断属于哪一类，再写具体事实。原因写得越具体，纠偏措施越容易对应上；原因写成“配合不到位”，措施往往也只能写成“加强沟通”，验证时无从核对。
必填与选填的划分
纠偏记录启动时，部分字段必须当场填清，否则记录无法跟踪；另一些字段可以随进展补充。划分依据是：缺少该字段会导致记录无法被验证或无法被追责。
| 类别 | 字段 | 理由或适用情形 |
|---|---|---|
| 必填 | 记录编号 | 用于引用和归档，缺失会导致记录无法定位 |
| 必填 | 偏差描述与量化 | 没有量化偏差，后续措施和验证都失去基准 |
| 必填 | 纠偏措施 | 模板的核心内容，缺失则记录不构成纠偏计划 |
| 必填 | 责任人 | 无唯一责任人时措施难以推进和追责 |
| 必填 | 计划完成时间 | 没有时间点无法判断是否按期纠偏 |
| 必填（关闭时） | 验证方式、验证结果、关闭结论 | 记录关闭前必须补齐，作为偏差已消除或受控的证据 |
| 选填 | 影响范围 | 偏差仅影响单个任务、不波及里程碑时可简写或暂缺 |
| 选填 | 原因分析 | 原因尚在排查时可先记录初步判断，待查清后补充；但关闭前建议补齐，便于复盘 |
| 选填 | 验证时间 | 验证执行后填写，启动阶段留空 |
| 选填 | 状态与关闭结论 | 启动时填“待启动”或“进行中”，随进展更新 |
如果启动时必填字段缺失，不建议直接建立记录后长期空置。处理方式有两种：偏差描述与量化不清时，先补做进度核对再建记录；责任人暂未确定时，由项目负责人指定临时责任人并在记录中注明，待正式责任人确定后更新。验证类字段在记录关闭前必须补齐，未补齐的记录保持“待验证”状态，不进入关闭。
填写示例：一条完整的纠偏记录
下面用一条已填写的记录示范字段如何联动。示例为演示情景，数据仅用于说明填写方式。
| 字段 | 填写内容 |
|---|---|
| 记录编号 | CRM-003 |
| 偏差描述与量化 | 客户管理模块接口开发计划第6周完成，实际第8周周末完成约70%，滞后约1.5周 |
| 影响范围 | 影响后续联调任务启动，若第9周内未追平，将影响第12周的系统测试里程碑 |
| 原因分析 | 接口依赖的第三方鉴权服务文档延迟提供，且原估算未计入联调环境准备时间，属于外部依赖延迟叠加估算偏差 |
| 纠偏措施 | 由后端负责人协调第三方在2个工作日内提供完整文档；增派1名开发人员并行处理剩余接口；将联调环境准备提前至第9周周一完成 |
| 责任人 | 后端负责人（姓名略） |
| 计划完成时间 | 第9周周五 |
| 验证方式 | 核对接口开发完成清单与联调环境就绪记录，对比更新后的计划与实际进度 |
| 验证时间 | 第9周周五 |
| 验证结果 | 接口开发于第9周周四全部完成，联调环境周一就绪，进度差距缩小至2天，系统测试里程碑不受影响 |
| 状态与关闭结论 | 已关闭。偏差已消除，后续按更新后的计划跟踪 |
这条记录体现了字段之间的对应关系：偏差量化到“滞后约1.5周”，措施就围绕追回这1.5周展开；原因写到“外部依赖延迟叠加估算偏差”，措施就分别处理依赖和人力；验证结果用完成清单和环境就绪记录支撑，结论才能落到“已关闭”。如果验证时发现差距仍有1周，记录应回到“进行中”，追加新一轮措施，而不是直接关闭。
当纠偏记录需要多人协同更新时，可以把模板沉淀在项目文档中，并与计划中的任务关联。ONES Wiki 支持使用模板库一键创建制式化文档，文档可关联项目任务并嵌入任务进度与报表；ONES 也支持设置项目计划和里程碑基线，对比计划与执行的偏差，并通过版本对比追溯变更细节。把纠偏记录放在这样的文档与计划环境中，责任人和验证结论能对应到具体任务，状态更新也有据可查。
模板的调整与维护方法
模板需要在项目推进中持续使用，字段可以按项目规模裁剪，但裁剪要有原则，更新和归档要有固定动作。
字段裁剪与扩展原则
- 保留四项核心字段：偏差描述与量化、纠偏措施、责任人、验证结果。这四项缺失时，记录无法形成“发现—行动—验证”的闭环。
- 小型项目可合并“影响范围”与“偏差描述”，把影响写在偏差描述末尾；跨团队项目建议单独保留，便于识别依赖方。
- 偏差频繁、记录量大的项目可增加“偏差类别”字段，按计划估算、执行延误、资源变动、外部依赖分类，便于统计高频原因。
- 需要向上汇报的项目可增加“升级标记”字段，标明该条记录是否已提交项目管理层。
记录更新与状态流转
建议按“待启动—进行中—待验证—已关闭”四个状态推进，状态变化时同步更新对应字段。措施执行期间，责任人按计划完成时间检查进展；到期未完成时，更新计划完成时间并说明原因，同时判断是否需要追加措施。进入“待验证”后，由责任人以外的人员按验证方式核对结果，填写验证时间与验证结果，再给出关闭结论。偏差未消除但已受控的记录，可在关闭结论中写明控制方式和后续跟踪安排。
归档与复盘使用
项目阶段结束时，将已关闭的纠偏记录按编号归档，与项目计划、变更记录放在同一文档结构中。复盘时按原因类别统计记录数量和平均纠偏周期，识别反复出现的偏差来源，把有效做法补充进后续项目的计划估算和检查清单。归档后的记录保持只读，后续如需调整，新建记录并引用原编号，避免历史结论被覆盖。
常见问题
偏差原因一时查不清，记录还能先建立吗？
可以。原因分析属于选填字段，原因尚在排查时可先记录初步判断，待查清后补充。但偏差描述与量化、纠偏措施、责任人、计划完成时间这四项必填字段需要当场填清，否则记录无法跟踪。记录关闭前建议补齐原因分析，便于后续复盘时统计高频偏差来源。
一条记录里包含多个偏差成因，应该拆开还是合并？
建议拆成多条记录。一条记录只对应一个可独立验证的偏差，每个偏差分别指定责任人。如果多个成因指向同一个偏差且由同一人负责，可以合并为一条记录，在原因分析中分条列出，措施也按成因分别对应。拆分的判断标准是：验证时能否用同一组证据同时证明这些偏差已消除或受控。
验证时发现偏差没有完全消除，记录该怎么处理？
记录应回到“进行中”状态，追加新一轮措施，更新计划完成时间，而不是直接关闭。如果偏差已受控但尚未完全消除，可以在关闭结论中写明控制方式和后续跟踪安排，同时保留验证结果中的事实数据。验证结果要写清验证看到的具体结果，例如进度差距缩小到多少天，避免只写“已完成”。
纠偏记录放在文档里还是放在任务工具里更好？
取决于记录需要和什么联动。如果纠偏记录主要供团队阅读和复盘，放在项目文档中即可，便于按编号归档和检索。如果需要和计划中的任务、里程碑基线对应，让责任人和验证结论落到具体任务上，可以放在支持文档与任务关联的工具中。ONES Wiki 支持使用模板库一键创建制式化文档，文档可关联项目任务并嵌入任务进度与报表；ONES 也支持设置项目计划和里程碑基线，对比计划与执行的偏差。两种方式也可以结合使用，文档承载记录内容，任务工具承载跟踪状态。
小型项目使用这个模板需要保留全部字段吗？
不需要。小型项目可以合并“影响范围”与“偏差描述”，把影响写在偏差描述末尾；偏差仅影响单个任务时，影响范围可简写或暂缺。但偏差描述与量化、纠偏措施、责任人、验证结果四项建议保留，这四项缺失时记录无法形成“发现—行动—验证”的闭环。字段裁剪的原则是：缺少该字段会导致记录无法被验证或无法被追责时，就应当保留。
