项目进度是项目在时间维度上的计划安排与实际推进状态，回答“什么时候做什么、做到哪一步”。它由活动、工期、依赖关系、开始与完成时间、里程碑等要素构成，核心用途是支撑进度控制：比较计划与实际、识别偏差并采取纠偏措施。本文聚焦进度的定义、构成与边界，状态汇报和里程碑验收归其他主题展开。
要点总览（TL;DR）
- 项目进度是项目在时间维度上的计划安排与实际推进状态，由活动、工期、依赖关系、起止时间和里程碑构成，回答“什么时候做什么、做到哪一步”。
- 进度本身是管理对象，进度控制是作用于它的过程：建立基准、比较计划与实际、识别偏差、采取纠偏措施，基准更新需有明确触发条件。
- 进度与状态报告、健康度、里程碑管理回答的问题不同：状态报告看综合状态，健康度给整体评估，里程碑管理判定节点是否达成。
- 完成百分比只是进度的一种度量口径，需结合活动权重、依赖关系和剩余工作量判断；进度落后是偏差，是否升级为风险要看幅度、关键路径影响和纠偏空间。
项目进度的准确定义
项目进度（Project Schedule）指项目在时间维度上的计划安排与实际推进状态。它既包含“打算在什么时间完成哪些活动”的计划侧内容，也包含“目前实际推进到哪一步”的执行侧内容。判断一个项目的进度，需要同时看这两侧，并说明两者之间的差距。
理解这个定义，要抓住三个关系：
- 进度与时间：进度以时间轴为载体，每项活动都有计划开始时间、计划完成时间，执行中还会产生实际开始时间和实际完成时间。没有时间坐标，就谈不上进度。
- 进度与范围：进度安排的对象是范围中已经分解出来的活动。范围发生增减，进度就要相应调整；脱离范围谈进度，容易出现“时间没超但该做的没做”的误判。
- 进度与资源：工期估算和排期需要考虑可用人力、设备等资源约束。资源不到位会推迟活动，资源调整也可能改变活动的先后安排。
因此，项目进度是一项有结构的计划信息，并非“快”或“慢”的主观感受。说某个项目“进度正常”，应当能对应到具体的活动、时间和完成情况。
项目进度包括什么、不包括什么
把进度的范围列清楚，可以避免把不同管理主题混在一起讨论。进度本身包含以下要素：
- 活动：为完成项目交付物而分解出的具体工作单元，是进度安排的最小对象。
- 工期：每项活动预计需要的时间长度，以及由此汇总出的项目总工期。
- 依赖关系：活动之间的先后约束，例如某项设计完成后才能开始开发，某项测试通过后才能上线。
- 开始与完成时间：每项活动的计划起止时间和实际起止时间。
- 里程碑：标记重要时间点、事件或决策点的零工期节点，用于标示阶段性位置。
以下内容属于相邻管理主题，不计入进度概念本身：
- 进度控制：围绕进度偏差展开的管理动作，包括对比、分析和纠偏。进度是对象，进度控制是作用于对象的管理过程。
- 项目状态报告与健康度管理：综合反映范围、成本、质量、风险等多维信息的汇报与评估，进度只是其中一项输入。
- 关键节点达成与里程碑验收：关注某个节点是否达到约定标准、是否通过评审，属于里程碑管理的范畴。里程碑出现在进度计划中，但节点验收的判定标准与流程归里程碑管理。
划清这条边界，讨论进度时就能聚焦在时间维度的计划与执行上，不把综合汇报和节点验收的结论直接当作进度结论。
项目进度是如何形成和推进的
进度是一项动态的管理对象，并非一张排好就不再变动的静态表。它的形成和推进大致经过以下环节。
第一步：分解活动并估算工期
先把项目范围分解为可管理的工作单元，形成工作分解结构（WBS，Work Breakdown Structure，即按交付物或阶段逐层拆解工作的树状结构），再对每个活动估算工期。工期估算可以依据历史数据、专家判断或类比方法，估算结果应写明假设条件和依据，便于后续复核。
第二步：确定依赖关系并排期
明确活动之间的前后置约束，识别哪些活动可以并行、哪些必须串行，据此排出时间顺序和起止时间，形成进度计划。排期时还要检查资源是否支撑这样的安排，避免计划在纸面上成立、执行中无法落地。
第三步：执行中记录实际进展
活动开始和完成后，记录实际开始时间、实际完成时间和剩余工作量。这些记录是后续对比的基础，缺失或滞后记录会让偏差识别失真。
第四步：对比计划与实际、识别偏差
将实际进展与计划基准比较，找出哪些活动提前、哪些滞后，判断偏差是否影响后续活动和关键节点。偏差分析要落到具体活动上，说明偏差幅度和可能的原因。
第五步：采取纠偏措施并视情况更新基准
根据偏差性质选择措施，例如调整资源投入、压缩后续活动工期、调整活动顺序，或与相关方协商范围与时间的取舍。进度基准（经确认后作为对比依据的进度计划版本）的更新应有明确触发条件和审批约定：一般性纠偏在基准内完成，只有范围、关键节点或重大前提发生变更时才更新基准，并保留变更记录，否则计划与实际的对比会失去参照意义。
在工具层面，进度形成与推进的各个环节需要有承载对象。ONES 支持用「项目计划」创建工作分解结构，制定项目进度计划，按目标、交付物或项目阶段等维度分解计划和工作；支持为任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点。在偏差管理上，ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并可通过对比版本细节追溯变更。ONES 还提供从项目到任务的多层级管理，支持自下而上的进度反馈和自上而下的进度监控；ONES Plan 支持制定里程碑与甘特图，多时间跨度查看进度。这些能力对应的是上述流程中的分解、排期、对比与追溯动作，具体版本与部署方式需另行核验。
项目进度与相邻概念的区别
进度、进度控制、状态报告、里程碑和健康度经常被混用。下表按同一口径对照它们的关注对象和典型问题。
| 概念 | 关注对象 | 回答的问题 | 典型产物 |
|---|---|---|---|
| 项目进度 | 时间维度上的计划安排与实际推进状态 | 什么时候做什么、做到哪一步 | 进度计划、活动起止时间、实际完成记录 |
| 进度控制 | 计划与实际的偏差及纠偏动作 | 偏差多大、影响什么、怎么调整 | 偏差分析、纠偏措施、基准变更记录 |
| 项目状态报告 | 范围、进度、成本、质量、风险等综合状态 | 项目整体现在怎么样 | 周期性的状态汇报材料 |
| 里程碑管理 | 关键节点的达成与验收 | 这个节点是否达到约定标准 | 节点验收结论、评审记录 |
| 项目健康度 | 多维度指标综合形成的评估结论 | 项目整体风险水平如何 | 健康度评级与预警 |
从表中可以看出，进度是状态报告和健康度评估的一项输入，进度控制是作用于进度的管理过程，里程碑管理则聚焦节点是否达成。四者相互关联，但回答的问题不同，混用会导致结论失焦。
一个具体例子与常见误解
假设一个网站改版项目，计划中列出“需求确认”“视觉设计”“前端开发”“联调测试”“上线”五项活动，工期分别为5天、10天、15天、5天、1天，并设置“设计定稿”和“上线”两个里程碑。执行到第12天时，需求确认按期完成，视觉设计延迟2天完成，前端开发因此顺延开始。此时准确的进度表述是：视觉设计活动滞后2天，前端开发计划开始时间相应后移，需评估这2天延迟是否影响“上线”里程碑；如果前端开发可以通过增加人手吸收延迟，则整体进度仍可控。这个例子说明，进度判断要落到具体活动、时间和依赖关系上。
围绕进度，有两个常见误解值得澄清。
误解一：完成百分比等于进度
完成百分比只是进度的一种度量口径。它依赖活动权重和统计口径，容易掩盖结构性问题：一个项目可能整体完成70%，但剩余30%集中在关键路径上的活动，实际风险远高于数字显示的水平。判断进度时，应结合活动权重、依赖关系、剩余工作量和关键路径影响综合评估，不能只看一个百分比。
误解二：进度落后等于项目失败
进度落后是偏差，不是结论。是否构成严重问题，要看偏差幅度、是否影响关键节点、剩余时间是否足以纠偏，以及可动用的资源空间。小幅滞后通过调整资源或顺序即可吸收；只有偏差持续扩大且缺乏纠偏手段时，才需要升级为项目层面的风险讨论。把滞后直接等同于失败，容易引发过度反应，也会削弱团队如实报告偏差的意愿。
常见问题
项目进度落后了，应该先调整计划还是先加资源？
先判断偏差的性质和影响范围，再决定动作。如果滞后发生在非关键路径上、且后续有浮动时间可以吸收，通常只需在基准内调整活动顺序或微调资源；如果滞后已经影响关键节点，且剩余时间不足以自然吸收，才考虑增加资源、压缩后续工期或与相关方协商范围与时间的取舍。
调整计划基准要谨慎：一般性纠偏在基准内完成，只有范围、关键节点或重大前提发生变更时才更新基准，并保留变更记录。先改基准再补动作，会让后续的计划与实际对比失去参照。
活动完成百分比很高，为什么项目仍可能延期？
完成百分比是按活动权重折算的度量口径，它反映的是“已完成工作量占比”，不反映剩余工作集中在哪些活动上。如果剩余工作恰好落在关键路径上，或者集中在依赖关系密集的环节，即使整体百分比看起来不错，后续可压缩的空间也很小。
判断时要看三件事：剩余工作量分布在哪些活动、这些活动是否在关键路径上、剩余时间与所需工期是否匹配。百分比可以作为汇报口径，单独用它下结论容易失真。
进度基准在什么情况下应该更新？
进度基准是经确认后作为对比依据的进度计划版本，更新它意味着对比参照发生变化。通常只在范围、关键节点或重大前提发生变更时更新，例如客户新增交付物、上线时间被正式调整、关键技术方案更换导致活动结构变化。
日常的偏差纠偏，如调整资源投入、压缩个别活动工期、改变非关键活动的顺序，应在基准内完成，不触发基准更新。更新时应保留变更记录，说明触发原因和审批结论，否则后续无法解释计划与实际的差异来源。
里程碑都按时达成了，能说明项目进度健康吗？
不能直接等同。里程碑标记的是重要时间点、事件或决策点，节点按时达成说明这些位置没有延误，但进度还包括各活动的实际推进状态、剩余工作量和依赖关系是否顺畅。
一种常见情形是团队为保住节点集中投入资源，节点达成后后续活动积压，整体进度反而更紧张。因此里程碑达成情况应和活动层面的计划与实际对比一起看，节点验收结论归里程碑管理，进度判断仍要回到时间维度的计划与执行状态。
用工具管理项目进度，最低限度要具备哪些能力？
从进度形成与推进的流程看，至少需要三类承载：能把范围分解为活动并估算工期，能设置活动之间的前后置依赖并排出起止时间，能记录实际进展并与计划对比。
在此基础上，基线对比和变更追溯会明显提升偏差管理的可操作性。以 ONES 为例，支持用「项目计划」创建工作分解结构、为任务设置前后置依赖、用里程碑标记重要时间点，并支持设置项目计划和里程碑基线以对比计划与执行的偏差、通过版本对比追溯变更；ONES Plan 支持制定里程碑与甘特图、多时间跨度查看进度。具体版本与部署方式需结合实际情况核验。
