项目进度跟踪要拿得出可相互校验的记录，而不是只看一句“完成了多少”。常用依据包括经批准的范围与进度基准、WBS与任务分解、实际完成量与剩余工作量、里程碑和交付物验收状态、工时与资源投入、依赖关系和变更记录、风险与问题台账。本文围绕进度控制，给出依据清单、单次跟踪步骤、角色分工、演示示例和完成检查表。
要点总览（TL;DR）
- 进度跟踪的依据分三组：基准类（范围与进度基准、WBS、依赖关系、里程碑与验收标准）、执行记录类（实际完成与剩余工作量、工时与资源投入、交付物验收状态）、变更类（变更记录、风险与问题台账）。
- 单次跟踪按五步执行：确定周期与采集口径、采集实际值与剩余工作量、与基准比对计算偏差、形成偏差说明与纠偏动作、记录归档；每步都有输入、输出和完成标志。
- 任务负责人提供任务实际与剩余工作量，项目经理维护基准与变更并牵头判断偏差，职能负责人确认资源投入，质量或验收角色提供评审与验收结论；升级条件写入项目跟踪约定。
- 用检查表核验跟踪质量：依据完整性与时效性、偏差可追溯、纠偏闭环、变更受控、记录可复核；依据清单随阶段变化定期维护。
进度跟踪前先备齐哪些依据
开始跟踪之前，先把依据分成三组备齐：基准类回答“原计划是什么”，执行记录类回答“实际做到哪里”，变更类回答“计划为什么变了”。三组记录能相互对照，偏差判断才有落点。只有执行记录而没有基准，无法计算偏差；只有基准而没有变更记录，会把已批准的调整误判为延期。
依据清单与维护要求
| 依据名称 | 分组 | 来源 | 维护人 | 更新频率 | 缺失时的处理 |
|---|---|---|---|---|---|
| 经批准的范围说明与进度基准 | 基准类 | 项目立项与计划评审材料 | 项目经理 | 基准批准时建立，变更批准后更新 | 无正式基准时，先以评审通过的计划版本作为临时基准，标注“临时”并注明批准人 |
| WBS与任务分解 | 基准类 | 项目计划中的工作分解结构 | 项目经理与任务负责人 | 计划调整时更新 | 分解过粗时，至少补到可分配负责人、可估算工作量的层级 |
| 任务计划起止时间与依赖关系 | 基准类 | 进度计划 | 项目经理 | 计划变更时更新 | 依赖未登记时，由任务负责人在跟踪会上口头补充并当场记录 |
| 里程碑清单与交付物验收标准 | 基准类 | 项目计划、合同或需求文档 | 项目经理、质量或验收角色 | 里程碑设定或验收标准调整时更新 | 验收标准不明确时，先由验收角色书面确认“什么算完成” |
| 任务实际完成情况与剩余工作量 | 执行记录类 | 任务状态更新、每日或每周填报 | 任务负责人 | 按跟踪周期更新 | 无法获得剩余工作量时，用完成百分比加负责人说明替代，并注明估算依据 |
| 工时与资源投入记录 | 执行记录类 | 工时填报、资源分配表 | 任务负责人填报，职能负责人确认 | 按周或按跟踪周期汇总 | 无工时系统时，用简易工时表按人按任务登记 |
| 交付物提交与验收状态 | 执行记录类 | 评审记录、验收单、缺陷或问题单 | 质量或验收角色 | 每次评审或验收后更新 | 无正式验收记录时，保留评审纪要并写明结论与遗留项 |
| 变更申请与批准记录 | 变更类 | 变更单、会议纪要、邮件确认 | 项目经理 | 变更发生时即时登记 | 口头变更须在下次跟踪前补成书面记录，写明影响的范围与时间 |
| 风险与问题台账 | 变更类 | 风险登记册、问题清单 | 项目经理指定责任人 | 每周或每个跟踪周期更新 | 台账未建立时，先在跟踪记录中单列“风险与阻塞”栏 |
每项依据都有最低要求：基准要有批准人和版本，执行记录要有填报人和时间，变更记录要有影响说明。满足这三条，后续比对时才能说清“和哪个版本比、由谁确认、影响了什么”。依据的准备不必追求一次到位，可以在第一次跟踪时暴露缺口，再按上表的缺失处理逐项补齐。
按什么步骤完成一次进度跟踪
一次完整的进度跟踪由五个动作组成，每个动作都有明确输入、输出和完成标志。跟踪周期按项目节奏确定：交付周期短的项目可以按周跟踪，周期长或风险高的项目可以加密到每周两次；周期一旦确定，采集口径应保持一致，避免这次按任务数、下次按工时比较。
第一步：确定跟踪周期与采集口径
输入是项目基准和团队工作节奏，动作是明确本次跟踪覆盖的时间段、比对基准版本、统计口径（按任务完成数、按剩余工作量或按交付物验收数）。输出是一份简短的跟踪约定，写明周期、口径和参与人。完成标志是所有参与人对“这次和什么比、比什么”没有歧义。
第二步：采集实际进度与剩余工作量
输入是任务清单和填报模板，动作是由任务负责人逐项更新状态、已完成内容、剩余工作量和预计完成时间，项目经理汇总工时与资源投入。输出是本次跟踪的实际值记录。完成标志是每项进行中的任务都有负责人确认的更新，未更新的任务被单独标出，而不是默认视为正常。
第三步：与基准比对并计算偏差
输入是基准版本和实际值，动作是逐项比较计划完成时间与实际完成时间、计划工作量与剩余工作量，识别延期任务、提前任务和依赖受阻任务。输出是偏差清单，至少包含任务名称、基准值、实际值、偏差量和影响范围。完成标志是偏差能对应到具体任务和具体基准版本，而不是停留在整体“略有延迟”的描述。
第四步：形成偏差说明与纠偏动作
输入是偏差清单和风险问题台账，动作是逐条分析偏差原因，区分估算偏差、执行延误、依赖阻塞和范围变更，并为每条重要偏差指定纠偏动作、责任人和完成时间。输出是偏差说明与纠偏计划。完成标志是每条超出容忍范围的偏差都有责任人和下一次检查时间。
第五步：记录并归档跟踪结果
输入是本次跟踪的全部记录，动作是整理成一份跟踪记录，包含基准版本、实际值、偏差、纠偏动作和待决事项，存入项目共享位置。输出是可复核的跟踪档案。完成标志是下次跟踪时能直接调出上次记录，对照纠偏动作的落实情况。
这五步在协作工具中可以用同一套工作项承载：任务负责人更新状态和剩余工作量，项目经理对照已设置的计划和里程碑基线查看偏差，变更与风险记录留在同一项目中，跟踪记录作为文档归档。ONES 的项目计划支持建立WBS、设置任务前后置依赖和里程碑，并可设置计划与里程碑基线用于对比执行偏差；工时日历和成员工时报表可用于查看资源投入情况。跟踪周期、口径和纠偏规则仍由团队自行约定。
谁提供依据、谁判断偏差：角色与交付物
依据无人维护，跟踪就会退化成项目经理的单方面汇总；偏差无人判断，问题就会拖到无法挽回。角色分工的关键是让每项依据有明确提供人，让偏差判断有明确责任人。
| 角色 | 负责提供的依据 | 提交时间点 | 交付物 |
|---|---|---|---|
| 任务负责人 | 任务实际完成情况、剩余工作量、阻塞说明 | 每个跟踪周期截止前 | 更新后的任务状态与剩余工作量记录 |
| 项目经理 | 基准版本、变更记录、风险与问题台账、跟踪汇总 | 跟踪会前完成汇总，变更发生时即时登记 | 偏差清单、跟踪记录、纠偏计划 |
| 职能负责人 | 人员投入安排、工时确认、资源冲突说明 | 按周或按跟踪周期确认 | 资源投入记录与调整说明 |
| 质量或验收角色 | 交付物评审结论、验收状态、遗留缺陷 | 每次评审或验收后 | 评审纪要、验收记录、遗留项清单 |
偏差判断通常由项目经理牵头，任务负责人和职能负责人共同确认原因。升级条件按项目实际设定，常见的触发情形包括：关键路径任务延期超过约定容忍天数、里程碑交付物验收未通过、同一偏差连续两个周期未收敛、资源冲突影响多个任务。触发后由项目经理提交给项目决策人或项目指导层判断是否调整基准。容忍天数和升级层级应写入项目跟踪约定，不同规模的项目可以不同。
一个迭代周期的跟踪示例
以下为演示情景，用于说明依据如何串成闭环，不代表真实项目数据。
示例背景与基准设定
某内部系统改造项目按两周一个迭代推进。迭代开始时，项目经理在项目计划中建立WBS，将迭代范围拆为需求确认、接口开发、联调测试、上线准备四组任务，设置任务依赖和迭代结束里程碑，并将该版本设为进度基准。验收角色同步确认上线准备的验收标准：联调测试通过且无高优先级遗留缺陷。
采集到的实际数据与偏差
第一次跟踪时，需求确认任务按计划完成；接口开发任务负责人填报完成百分之七十，剩余工作量约三天，比基准多出一天；联调测试因接口未完成而尚未开始，依赖关系显示其开始时间将被推迟。工时记录显示一名开发人员本周有两天投入其他项目。变更记录中有一条已批准的小范围需求补充，影响接口开发约半天工作量。
比对基准后，偏差集中在接口开发任务：偏差量为一天，原因是需求补充和人员投入分散。联调测试的推迟属于依赖传导，尚未独立构成偏差。
纠偏动作与后续跟踪结果
项目经理与职能负责人确认，下周将该开发人员的主要工时集中到本项目；接口开发任务负责人将需求补充拆为独立子任务并重新估算剩余工作量；联调测试的开始时间顺延一天，里程碑日期暂不调整，列入下次跟踪重点观察。第二次跟踪时，接口开发按调整后的估算完成，联调测试启动，偏差收敛，里程碑按期达成。两次跟踪记录、变更单和工时调整说明一并归档，成为后续迭代估算的参考。
跟踪结果如何核验与持续改进
判断一次跟踪是否到位，可以对照下面的检查表逐项核验。检查的目的在于确认记录能否支撑复核，而不在于追求文档数量。
| 检查项 | 核验内容 | 通过标准 |
|---|---|---|
| 依据完整性 | 基准、执行记录、变更记录三组是否齐全 | 本次跟踪涉及的每项任务都能找到对应基准和实际值 |
| 依据时效性 | 实际值和工时是否在跟踪周期内更新 | 无超过一个周期未更新的进行中任务，或有明确说明 |
| 偏差可追溯 | 每条偏差是否对应具体任务和基准版本 | 偏差清单可回溯到任务和版本，不停留在整体描述 |
| 纠偏闭环 | 上期纠偏动作是否落实并复查 | 每条纠偏动作有落实结论，未落实的有原因和新时间 |
| 变更受控 | 影响进度的变更是否登记并反映到基准 | 变更单与基准版本一致，口头变更已补书面记录 |
| 记录可复核 | 跟踪记录是否归档且可被他人调阅 | 下次跟踪能直接调出上期记录并对照 |
依据清单本身也需要维护。项目阶段变化、范围调整或团队分工变动后，应检查依据清单是否仍覆盖当前跟踪对象：新增的交付物是否补充了验收标准，新加入的成员是否明确填报责任，已关闭的风险是否从台账中清理。建议在每个阶段结束或每个季度复核一次清单，把反复缺失的依据补进模板，把不再使用的记录项删去。跟踪记录中暴露的估算偏差，也可以反过来修正后续任务的估算口径，让基准更贴近实际。
常见问题
项目刚启动、还没有正式批准的进度基准，能开始跟踪吗？
可以开始，但要把临时基准标注清楚。常见做法是以最近一次评审通过的计划版本作为临时基准，记录批准人和版本号，并在跟踪记录中注明“临时”。后续正式基准批准后，用新版本替换，同时保留旧版本，便于解释此前偏差是按哪个版本判断的。临时基准期间，变更同样要登记，避免正式基准建立后无法追溯。
任务负责人填报的剩余工作量明显不可靠，跟踪时怎么处理？
先把口径统一，再谈准确性。可以在跟踪约定中明确剩余工作量的填报单位（人天或小时）和估算依据，要求负责人说明剩余工作包含哪些具体内容。对反复偏差较大的任务，项目经理可与负责人一起复核，或改用交付物完成情况加评审结论作为辅助判断。跟踪记录中保留估算与实际差异，作为后续修正估算习惯的依据。
偏差在什么情况下需要调整基准，而不是继续纠偏？
通常先纠偏，再考虑调整基准。当偏差来自已批准的范围变更、外部条件发生实质变化，或纠偏后仍无法在容忍范围内收敛时，才提交基准调整。调整应由项目经理提出，写明影响的任务、时间和资源，交由项目决策人或项目指导层批准，并在变更记录中登记。未经批准的顺延仍按偏差处理，不自动改写基准。
跟踪周期定多长比较合适，周期内出现突发阻塞怎么办？
周期按项目节奏和风险确定：交付周期短、依赖密集的项目可按周跟踪，周期长或风险高的项目可加密。周期确定后保持采集口径一致，便于逐期比较。周期内出现突发阻塞时，不必等到下个跟踪日，可由任务负责人即时在任务上标注阻塞并通知项目经理，项目经理判断是否触发升级；该阻塞仍纳入下期跟踪记录，形成完整链条。
用协作工具承载跟踪记录时，需要关注哪些配置要点？
重点在三处：一是计划结构，任务分解到可分配负责人、可估算工作量的层级，并登记任务前后置依赖和里程碑；二是基线，在计划稳定时设置项目计划与里程碑基线，后续对比执行偏差；三是记录留存，变更、风险与跟踪记录放在同一项目中，便于下次跟踪直接调取。ONES 的项目计划支持建立WBS、设置任务依赖和里程碑，并可设置计划与里程碑基线用于对比偏差，工时日历和成员工时报表可用于查看资源投入。跟踪周期、口径和纠偏规则仍需团队自行约定。
