项目进度表用于逐条记录任务的计划与实际进度，让团队在同一套口径下判断哪些任务按期、哪些已经偏离。本文提供一张可直接复制到表格工具中的空白进度表，并逐字段说明填写方法、区分必填与选填、给出一份完整填写示例，最后说明模板随项目规模调整和日常维护的做法。内容聚焦进度控制本身，状态汇报与里程碑管理另作处理。
要点总览（TL;DR）
- 空白进度表包含任务编号、任务名称、负责人、协作方、计划与实际起止日期、当前进度、前置依赖、状态和偏差说明十二个字段，复制后先设置日期格式、百分比格式和状态下拉选项。
- 最低可用字段为任务编号、任务名称、负责人、计划开始、计划完成、当前进度和状态；协作方、实际日期、前置依赖和偏差说明按项目复杂度补充。
- 进度百分比按可核验的产出计量，例如接口数、用例数或章节数，计量单位在项目周期内保持一致，避免前后数据无法比较。
- 延期任务的状态选“已延期”，偏差说明写清事实、原因和下一步动作；未发生的实际日期留空，不填预计值。
- 小项目可精简字段，跨部门或长周期项目增加基线列；每周固定时间由任务负责人更新，汇总后另存带日期的历史版本。
可复制空白项目进度表
下面这张表可以直接选中复制到 Excel、在线表格或文档表格中。表头保持一行，每行记录一个可交付、可跟踪的任务，不要把一个阶段的多项工作挤在同一行。任务较多时按任务编号排序，编号规则建议为“阶段缩写-序号”，例如“需求-01”“开发-03”。
| 任务编号 | 任务名称 | 负责人 | 协作方 | 计划开始 | 计划完成 | 实际开始 | 实际完成 | 当前进度 | 前置依赖 | 状态 | 偏差说明 |
|---|---|---|---|---|---|---|---|---|---|---|---|
复制后先做三件事：把日期列设置为日期格式，避免出现文本型日期无法排序；把“当前进度”列设置为百分比格式；为“状态”列建立下拉选项，取值统一为“未开始、进行中、已完成、已延期、已暂停”。这三步能让后续筛选和汇总直接可用。
每个字段记录什么
字段口径统一，不同人填出的数据才具备可比性。下表逐项说明每个字段记录的内容和填写要求，其中日期一律使用“年-月-日”格式，进度一律使用整数百分比。
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 任务编号 | 任务的唯一标识 | 按“阶段缩写-序号”编制，全表不重复；任务拆分或合并后编号不复用 |
| 任务名称 | 任务要交付的结果 | 用动宾结构写清产出，例如“完成登录接口联调”，避免只写“开发”“跟进”这类无法判断完成与否的词 |
| 负责人 | 对任务结果负责的一个人 | 只填一个姓名，多人负责会导致延期时无人拍板；其余参与者写入协作方 |
| 协作方 | 需要配合的团队或人员 | 写部门或角色即可，例如“测试组”“设计”；人数较多时写主要配合方 |
| 计划开始 / 计划完成 | 任务原定的起止日期 | 在任务启动前填写；计划变更时保留原值并另设基线，或在偏差说明中记录变更原因 |
| 实际开始 / 实际完成 | 任务真实发生的起止日期 | 实际开始当天填写；实际完成以交付物通过验收为准，未验收不填完成日期 |
| 当前进度 | 任务已完成的比例 | 按可核验的产出计量，例如 5 个接口完成 3 个记 60%；不以“感觉快好了”估算，已完成任务记 100% |
| 前置依赖 | 本任务开始前必须完成的事项 | 填写前置任务的编号，多个用逗号分隔；无依赖填“无”，不留空，以便区分“没有依赖”和“漏填” |
| 状态 | 任务当前所处阶段 | 从固定选项中选择；实际完成日期晚于计划完成日期时选“已延期”，不选“进行中” |
| 偏差说明 | 计划与实际不一致的原因和应对 | 写清偏差事实、原因和下一步动作，例如“接口文档延迟 2 天，已协调后端周五前提供” |
进度百分比是最容易失真的字段。建议在项目启动时约定计量单位：开发任务按功能点或接口数，测试任务按用例执行数，文档任务按章节完成数。计量单位一旦确定，整个项目周期内保持一致，中途更换会让前后数据无法比较。
必填字段与选填字段
字段并非越多越好。项目规模小、周期短时，字段过多会增加填写负担，反而降低更新频率。下表给出最低可用字段和按需补充字段的划分。
| 类别 | 字段 | 原因或适用情形 |
|---|---|---|
| 必填 | 任务编号、任务名称、负责人、计划完成、当前进度、状态 | 这六项构成判断“谁在什么时候该完成什么、现在到哪一步”的最小集合，缺任何一项都无法独立跟踪任务 |
| 必填 | 计划开始 | 用于判断任务是否已到启动时间，缺少时无法识别“该开始却未开始”的情况 |
| 选填 | 协作方 | 任务涉及跨部门配合时填写；单人独立完成的任务可留空 |
| 选填 | 实际开始、实际完成 | 任务尚未启动时自然为空；任务进入执行后应尽快补齐，用于计算偏差 |
| 选填 | 前置依赖 | 存在明确先后顺序时填写；独立任务填“无”或留空均可，但同一项目内应统一 |
| 选填 | 偏差说明 | 任务按计划推进时可留空；出现延期、范围变化或资源调整时必须填写 |
字段缺失时按以下方式处理：负责人缺失的任务不得进入执行，先明确责任人再排期；计划完成日期缺失的任务视为未排期，不纳入进度统计；进度缺失按 0% 处理并在下次更新时补齐；偏差说明缺失但状态为“已延期”的，由项目负责人追问原因后补填。对于两周以内、三人以下的小项目，可以只保留必填字段加偏差说明；跨团队、周期超过一个季度的项目，建议启用全部字段，并增加基线列记录计划变更前的日期。
填写示例：一个迭代周期的进度表
以下为演示情景：某团队开展一个为期四周的版本迭代，包含需求确认、接口开发、联调测试和上线准备四类任务。示例数据仅用于说明字段之间的对应关系，不代表真实项目数据。
| 任务编号 | 任务名称 | 负责人 | 协作方 | 计划开始 | 计划完成 | 实际开始 | 实际完成 | 当前进度 | 前置依赖 | 状态 | 偏差说明 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 需求-01 | 完成本期需求清单评审 | 张敏 | 产品组、业务方 | 2025-03-03 | 2025-03-05 | 2025-03-03 | 2025-03-05 | 100% | 无 | 已完成 | |
| 开发-01 | 完成订单查询接口开发 | 李伟 | 后端组 | 2025-03-06 | 2025-03-14 | 2025-03-06 | 60% | 需求-01 | 进行中 | 5 个接口完成 3 个，剩余 2 个按计划 3 月 14 日前完成 | |
| 开发-02 | 完成订单列表页前端改版 | 王芳 | 前端组、设计 | 2025-03-10 | 2025-03-18 | 2025-03-12 | 30% | 需求-01 | 已延期 | 设计稿 3 月 11 日才定稿，实际开始晚 2 天；已与设计确认后续不再变更，预计完成日顺延至 3 月 20 日 | |
| 测试-01 | 完成订单模块联调与回归测试 | 赵强 | 测试组 | 2025-03-17 | 2025-03-24 | 0% | 开发-01,开发-02 | 未开始 | 等待开发-02 完成后启动，当前无其他阻塞 | ||
| 上线-01 | 完成上线检查单与发布 | 陈静 | 运维组 | 2025-03-25 | 2025-03-26 | 0% | 测试-01 | 未开始 |
从示例可以看出几个填写要点。开发-01 的进度按接口数量计量，60% 对应 5 个接口完成 3 个，读者可以自行核验。开发-02 的实际开始日期晚于计划开始日期，状态因此标为“已延期”，偏差说明同时写明了原因、影响和新的预计完成日，而不是只写“设计延迟”。测试-01 的前置依赖填了两个任务编号，说明它必须等两项开发工作都完成才能启动。上线-01 尚未开始，实际日期和偏差说明留空，符合“未发生不填”的口径。
对照字段说明检查这份示例：所有任务都有唯一编号和单一负责人；已完成任务的实际完成日期与计划完成日期一致，进度为 100%；未开始任务的实际日期为空，进度为 0%；延期任务的偏差说明包含事实、原因和应对动作。若团队填写时出现“进度 90% 持续两周不变”“延期但状态仍为进行中”等情况，说明口径未被遵守，需要在下次更新时纠正。
模板的调整与日常维护
模板投入使用后，需要根据项目规模调整字段，并固定更新节奏和版本管理方式，否则表格会逐渐失真，变成只在汇报前临时补填的材料。
按项目规模增减字段。三人以下、两周以内的小项目，保留必填字段加偏差说明即可，减少填写负担；跨部门、周期超过一个季度的项目，建议启用协作方、前置依赖和基线列，基线列记录计划变更前的日期，便于对比计划与执行的偏差。任务层级较深时，可增加“所属阶段”列用于分组筛选，但不宜再增加与进度判断无关的字段。
固定更新频率与责任人。建议每位任务负责人在每周固定时间更新自己名下的行，项目负责人汇总核对。更新内容包括实际开始与完成日期、当前进度、状态和偏差说明四项；计划日期原则上不随意改动，确需调整时在偏差说明中记录原因和原计划。更新完成后由项目负责人检查一遍：是否有状态为“进行中”但计划完成日期已过的行，是否有进度长期不变的行，是否有前置依赖已完成但本任务仍未启动的行。
保留历史版本。每次汇总更新后另存一份带日期的副本，例如“进度表-20250314”，或使用在线表格的版本记录功能。历史版本的作用是回溯某次延期从何时开始、当时的判断依据是什么，也便于在复盘时对比计划与实际的差异。版本命名保持统一，避免出现“最终版”“最终版2”这类无法判断先后的文件名。
明确与其他管理材料的边界。进度表回答“每个任务计划何时完成、实际到哪一步”，综合状态汇报回答“项目整体健康度如何、风险等级怎样”，里程碑管理回答“关键节点是否达成”。三者可以引用同一批任务数据，但不必合并成一张表：进度表按任务逐行记录，状态汇报按周期汇总，里程碑单独标记关键时间点。把这三类内容混在一张表里，会让进度表不断膨胀，最终无人愿意维护。
当进度表需要多人同时更新、并且要与任务状态流转和依赖关系联动时，可以借助项目协作工具承载。以 ONES 为例，其项目计划支持按目标、交付物或项目阶段分解工作，为任务设置前后置依赖，并通过项目列表查看项目状态与当前进展；设置计划和里程碑基线后，可以对比计划与执行的偏差，追溯变更细节。这类能力适合任务量大、更新频繁、需要保留变更记录的团队；任务少、周期短的项目继续使用表格模板即可，不必为此增加工具成本。
常见问题
任务拆分到什么粒度，进度表才不会变成流水账？
以“能独立判断完成与否”为拆分标准：一行对应一个可交付结果，例如“完成订单查询接口开发”，而不是“开发阶段”。如果一项任务需要两周以上才能看到可核验的产出，通常可以再拆一层；如果拆到半天以内、需要逐条汇报动作，说明粒度太细，会增加更新负担。拆分后为每行分配唯一编号，任务合并或取消时编号不复用，便于在偏差说明和前置依赖中稳定引用。
计划日期中途调整了，进度表里应该改原计划还是另记基线？
建议保留原计划日期，另设“基线”列记录调整前的日期，并在偏差说明中写明变更原因和批准人。直接覆盖原计划会让历史偏差消失，复盘时无法判断延期从何时开始。项目周期短、变更少时，也可以只在偏差说明中记录原计划和新计划；跨部门或周期超过一个季度的项目，单独设基线列更清晰。无论采用哪种方式，同一项目内应统一做法。
多人同时更新进度表，怎样避免覆盖和口径不一致？
先约定更新责任：每位负责人只改自己名下的行，项目负责人负责核对和汇总。使用在线表格时开启编辑记录，或每次汇总后另存带日期的副本。口径方面，把状态选项、日期格式和进度计量单位写在表格首行备注或单独的填写说明页中，新成员加入时先读说明再填写。若团队任务量大、更新频繁，并且需要保留变更记录和依赖联动，可以借助项目协作工具承载，例如 ONES 的项目计划支持设置前后置依赖和计划基线，便于对比计划与执行的偏差；任务少、周期短的项目继续用表格即可。
进度表里的“当前进度”和项目整体完成度是一回事吗？
两者口径不同。进度表中的当前进度是单个任务的完成比例，按该任务的计量单位计算；项目整体完成度通常需要结合任务权重、工作量或阶段汇总得出，不能简单对各任务百分比取平均，否则一个耗时很短的任务和一个主要交付物会被赋予相同分量。本文的进度表只记录任务级进度，整体完成度和健康度评估属于项目状态汇报的范围，需要另行汇总。
任务已经延期，但负责人认为很快能补上，状态可以先填“进行中”吗？
不建议。状态字段反映的是与计划对比的事实：实际完成日期晚于计划完成日期，或当前日期已过计划完成日期而任务未完成，就应选“已延期”，并在偏差说明中写清预计补回的时间和措施。把延期任务标为“进行中”会让筛选和汇总失真，也会掩盖需要协调的问题。若延期已获批准并调整了计划日期，则按新计划判断状态，同时在偏差说明中保留原计划和变更依据。
