掌握项目里程碑定义：5个步骤让你的项目管理更上一层楼

掌握项目里程碑定义：5个步骤让你的项目管理更上一层楼

很多项目延期，并不是团队没有排计划，而是里程碑只写了一个日期：3月15日完成开发、3月30日完成测试、4月10日上线。到了截止日，开发团队说“代码写完了”，测试团队说“还有严重缺陷”，业务方则认为“用户流程还没准备好”。这说明一个关键问题：日期不是里程碑，能够被共同验收的结果才是里程碑。

我在梳理项目计划时，通常不会先问“项目要设置几个里程碑”，而会先问三个问题：这个节点完成后，项目能否进入下一阶段？是否会产生可交付成果或重大决策？如果节点延期，谁需要立即调整资源、范围或时间？如果这三个问题都回答不清，计划表里所谓的里程碑，大概率只是普通任务换了一个名称。

一、先讲核心结论：里程碑是项目控制点，不是日期标记

1. 用一句话重新定义项目里程碑

项目里程碑，是用于确认关键成果、阶段目标或重大决策是否达成的项目控制点。它本身通常不描述大量工作量，而是描述一个重要结果是否已经具备进入下一阶段、接受下一次决策或完成交接的条件。

因此，“完成接口开发”可能是一项任务，“核心业务接口完成联调并通过集成测试，允许进入用户验收”才更接近有效里程碑。前者强调团队做了什么，后者强调项目现在是否具备下一步条件。

2. 一个可执行的里程碑定义公式

我建议项目负责人用下面这个公式检查每一个节点：

里程碑 = 关键结果或决策节点 + 交付物 + 完成标准 + 责任人 + 验收人 + 截止时间 + 未达成时的处理动作

这套公式的价值在于，它把“项目计划语言”转换成了“项目执行语言”。团队不再只看到一个模糊日期，而是能知道要交付什么、如何判定完成、由谁确认，以及出现偏差后该采取什么行动。

3. 里程碑数量不是越多越专业

如果一个项目有120项任务，却设置了80个里程碑，项目管理者实际上很难从中识别真正的风险。里程碑过多会带来三个后果：团队需要频繁更新状态，管理层无法看出重点，关键路径上的重大偏差容易被普通节点淹没。

里程碑过少也有问题。一个持续半年的复杂项目如果只有“启动”和“上线”两个节点，项目负责人通常要到很晚才发现范围膨胀、外部依赖延期或技术方案不可行。

我的判断标准是：只有当一个节点会触发阶段切换、成果验收、资源调整、重大决策或对外承诺时，才值得被提升为里程碑。

二、背景和真实场景：为什么计划表有节点，项目仍然会失控

1. 同一个“完成”，不同角色有不同理解

以企业系统上线项目为例，研发负责人认为“完成开发”意味着代码已经合并，测试负责人认为“完成开发”意味着可以稳定测试，业务负责人则认为“完成开发”意味着主要业务流程已经能被真实用户使用。

如果项目计划只写“5月20日完成开发”，三方都会按照自己的标准解释。到了5月20日，任何一方都可能认为其他人没有完成工作。此时争论的表面是进度，实质是项目从一开始就没有定义共同的完成标准。

2. 里程碑失效通常发生在上游，而不是延期当天

我观察过不少延期项目，真正的问题往往早在里程碑前两三周就出现了：需求范围没有冻结，外部接口没有确认，验收人没有排期，关键资源同时被另一个项目占用，或者供应商交付物没有明确格式。

如果团队只在截止日查看“完成/未完成”，就只能记录结果，无法提前处理原因。有效的里程碑管理应该把验收条件、前置依赖和风险信号提前放进计划，让项目负责人在节点到期前就能看到偏差。

3. 一个节点真正有价值的地方在于它能触发行动

里程碑不是项目周报里的一行装饰。它应该让相关人员在节点附近做出明确动作，例如批准范围、释放预算、启动采购、安排验收、切换资源或决定是否继续投入。

如果一个节点完成后没有任何人需要确认、没有任何阶段需要切换、没有任何资源需要调整，那么它可能只是任务清单中的一个普通检查点，不必占用管理层级别的里程碑位置。

三、五个步骤定义真正有效的项目里程碑

1. 第一步：明确项目目标、范围和关键成果

里程碑设计不能从日历开始，而要从项目目标开始。先写清楚项目最终要改变什么、交付什么，以及哪些范围明确不在本次项目内。范围不清时，里程碑越详细，后续返工越严重。

我通常会要求项目负责人先回答以下问题：

• 项目最终要解决哪个业务问题？
• 什么结果会被客户、管理层或监管方正式认可？
• 哪些成果完成后，项目才能进入下一阶段？
• 哪些工作虽然重要，但并不影响项目整体决策？
• 如果目标延期，最先受到影响的是收入、成本、合规还是客户承诺？

其中最重要的问题是：如果这个节点没有达成，项目是否无法进入下一阶段，或者无法实现核心业务目标？如果答案是否定的，该节点更可能是任务或阶段交付物，而不是核心里程碑。

2. 第二步：拆解工作并筛选关键节点

明确目标后，再使用工作分解结构、流程图或任务清单拆解项目。拆解的目的不是把所有工作写得越细越好，而是看清任务之间的依赖、交付物之间的关系，以及哪些成果会影响后续决策。

可以按照“任务，交付物，评审，决策”的路径筛选节点。例如，调研、原型设计和需求访谈属于任务；需求说明书属于交付物；需求评审属于评审活动；范围冻结或批准进入开发则属于决策节点。最后一个节点通常更适合作为里程碑。

常见的里程碑来源包括：

• 项目正式立项或启动批准；
• 需求、范围或预算基线确认；
• 方案评审通过；
• 样品、原型或关键模块验收；
• 关键依赖完成交付；
• 测试达到上线条件；
• 正式上线、批量交付或现场投产；
• 项目移交、复盘和结项。

筛选时不要只看节点名称，还要检查它是否具有三个特征：对项目目标有影响、能够被客观验证、完成后会触发下一步行动。缺少其中两个特征的节点，通常不应被列为核心里程碑。

3. 第三步：把里程碑写成可验收的定义

这是五个步骤中最容易被忽略、但对执行影响最大的部分。一个好的里程碑名称应当使用结果型动词，例如“通过评审”“完成验收”“获得批准”“正式上线”“完成交接”，而不是“持续推进”“进入开发”“加强沟通”等无法判定完成的表达。

下面是产品上线项目中的一个改写示例：

原始写法：完成新用户系统开发。

可验收写法：用户系统完成注册、登录和权限管理等核心流程开发，集成测试通过，严重缺陷已关闭，版本部署至预生产环境，并由产品负责人和测试负责人共同确认。

改写后的节点包含了五类信息：结果是核心流程可用，交付物是可运行版本和测试记录，质量门槛是严重缺陷关闭，环境条件是部署至预生产，验收角色是产品与测试负责人。即使项目最后延期，团队也能知道究竟卡在哪个条件上。

每个里程碑至少应填写以下字段：

4. 第四步：安排时间、责任和前置依赖

里程碑日期不能凭感觉填写，也不能简单把项目最终日期平均分成几段。安排时间时，至少要检查前置任务、外部审批、供应商交付、关键资源冲突、测试返工和缓冲时间。

项目排期通常有两种方式。正推法从启动日期出发，根据工作量和依赖关系推算各个节点；倒推法从最终交付日期出发，反向计算每个里程碑最晚何时完成。对于有明确客户承诺或监管期限的项目，我更倾向于先倒推，再用正推法验证资源和工期是否现实。

一个里程碑至少要明确推动责任人和最终验收人。推动责任人不一定亲自完成所有任务，但必须负责协调资源、暴露风险和推动决策。验收人则负责判断交付结果是否达到标准，两者不能默认由“项目经理”一人承担。

前置依赖也要写得具体。比如“等待外部团队支持”不是有效依赖，应该写成“外部身份认证接口在5月12日前完成联调，并提供接口文档、测试账号和异常码说明”。依赖越具体，越容易跟踪，也越容易在延期前发出预警。

5. 第五步：建立跟踪、预警和复盘机制

里程碑计划不是发布后就结束，而是需要持续跟踪。建议至少设置三种状态：正常、预警和偏离。正常代表按计划推进；预警代表存在较高延期风险但仍有补救空间；偏离代表已经影响节点或关键路径，需要调整计划、资源、范围或相关方预期。

每次里程碑评审，我会要求团队回答以下问题：

1. 交付物是否齐全，版本是否正确？
2. 完成标准是否全部满足，是否存在未关闭问题？
3. 前置依赖是否已经完成，是否有外部条件尚未兑现？
4. 当前偏差是否影响后续关键路径？
5. 是否需要调整资源、范围、时间或质量目标？
6. 下一步动作是什么，由谁负责，何时完成？

里程碑延期后的处理流程可以固定为：发现风险，判断影响，制定补救方案，更新计划，同步相关方，记录原因并复盘。最忌讳的做法是只把日期往后拖，却不说明延期原因和后续影响。那样做只是让报表看起来正常，并没有让项目重新获得控制。

四、常见误区：项目里程碑为什么越写越多，控制力却没有变强

1. 把所有重要任务都升级成里程碑

“重要”并不等于“里程碑”。一项任务可能需要投入大量人力，但它只影响局部工作，不会触发阶段切换或管理决策。比如完成一份内部分析报告，可能很重要，但如果不需要正式评审、不影响后续资源和范围，就没有必要作为项目核心里程碑。

更稳妥的做法是把任务保留在任务层，把任务群产生的关键交付或决策节点提升到里程碑层。这样既不丢失执行细节，又能保持管理视图的简洁。

2. 只写日期，不写验收标准

“6月30日完成测试”这句话缺少至少四个信息：测试什么范围、达到什么质量、谁来确认、哪些问题允许遗留。没有这些信息，团队到了日期只能凭感觉报告“差不多完成”。

对于软件项目，完成标准可以包括核心流程通过、阻断级缺陷为零、关键性能指标达到项目约定、上线文档齐全等。对于市场活动，可以包括物料审核、供应商交付、现场演练和应急预案确认。标准不应照搬其他项目，而应从本项目的风险和业务目标中推导。

3. 用“进行中”“持续推进”描述里程碑状态

“进行中”只能说明有人在工作，不能说明距离完成还有多远。项目负责人需要把状态拆成可观察条件，例如“需求评审完成80%”“外部接口尚未提供测试账号”“核心缺陷剩余3项，其中1项阻断后续联调”。

状态信息越具体，管理层越容易判断是否需要介入。反过来，如果所有节点都只有“进行中”，项目周报看起来很忙，实际上没有提供任何决策依据。

4. 没有验收人，只有执行责任人

执行责任人负责把工作推进到可验收状态，验收人负责确认结果是否达标。缺少验收人时，项目经常出现“研发说完成、业务说不能用”的争议。

验收人也不一定是最高级别的管理者。更合理的做法是让最接近结果使用场景、同时拥有确认权限的人承担验收。必要时，可以设置主验收人和会签人，但不要把所有相关方都列为默认审批人。

5. 延期后只修改日期，不处理项目基线

里程碑延期可能只是局部问题，也可能意味着项目整体目标已经不再现实。两者需要不同处理。局部延期可以通过并行作业、增加资源或调整任务顺序解决；关键路径延期则可能必须重新谈判范围、质量、预算或最终交付日期。

五、专业判断逻辑：什么样的节点才值得设为里程碑

1. 用“五问法”筛选候选节点

面对一个候选节点，我通常会连续追问五个问题：

1. 它是否对应关键结果？如果节点完成与项目目标没有明显关系，通常只是普通任务。
2. 它是否影响下一阶段？如果后续工作不依赖这个结果，节点的治理价值可能有限。
3. 它是否能够被客观验收？如果只能用“基本完成”“大致可用”描述，就需要继续细化标准。
4. 它是否需要正式决策或交接？如果完成后会触发批准、切换、采购、发布或移交，里程碑价值较高。
5. 它延期后是否会造成明显影响？如果延期不会影响任何承诺、资源或路径，可能不必提升为核心里程碑。

这五个问题不是为了制造复杂流程，而是为了防止团队把“看起来重要”的工作全部放到管理层视图中。真正有效的里程碑应该帮助人做决定，而不是增加信息噪声。

2. 区分交付型、决策型和切换型里程碑

并非所有里程碑都必须有一个大型成果文件。有些里程碑是交付型，例如样品验收、测试报告批准；有些是决策型，例如是否进入下一轮投资、是否冻结范围；还有一些是切换型，例如系统正式上线、流程从旧系统切换到新系统。

3. 不要把质量指标当成统一答案

质量指标必须服务于项目目标，而不是为了显得专业而堆砌数字。比如，接口响应时间低于某个数值、测试覆盖率达到某个比例，可以作为特定软件项目的验收条件，但不能直接变成所有项目的通用标准。

在定义指标时，我会先判断它属于哪一类：功能是否可用、质量是否达标、风险是否可接受、文档是否齐全，还是业务是否愿意接收。指标应当与使用场景和风险等级绑定，否则团队可能为了达到漂亮数字，投入大量时间优化对业务无关的部分。

六、具体案例：用产品上线项目演示五步定义法

1. 项目背景和原始计划

假设一家面向企业客户的公司，计划在四个月内上线一套在线服务系统。项目涉及产品、研发、测试、信息安全、客服和运营六个团队，并且需要与客户现有身份认证系统对接。

项目初版计划只有五行：需求完成、开发完成、测试完成、准备上线、正式上线。表面上结构很清晰，但每一行都存在验收争议。尤其是“准备上线”，没有说明监控、回滚、客服培训和权限配置是否已经完成。

我会把它重新拆成以下里程碑：

2. 这个案例中最重要的变化

第一，原来的节点名称从“完成某项工作”改成了“通过某项确认”。这使里程碑从执行活动转变成了结果判断。

第二，每个里程碑都增加了验收证据。团队不再依靠口头汇报，而是通过需求说明书、测试报告、发布方案和交接清单确认状态。

第三，延期影响被提前写出来。比如技术方案评审延期，不只是技术团队晚几天，而可能直接压缩开发和联调时间；上线条件确认延期，则意味着正式切换风险尚未被管理。

第四，里程碑之间形成了因果链，而不是孤立日期。需求基线影响方案设计，方案评审影响开发，核心版本影响用户验收，上线条件影响正式切换。

3. 这个案例可以观察哪些数据

在项目复盘中，我更关注三类数据，而不是只看“按时完成率”。第一类是里程碑准时率，即实际完成日期与计划日期的偏差；第二类是一次验收通过率，反映里程碑定义是否清楚；第三类是里程碑后返工量，反映节点虽然被批准，但交付质量是否真正达标。

例如，一个项目可能有90%的里程碑按时完成，但一次验收通过率只有50%，并且每个节点通过后都产生大量返工。这个项目不能被判断为管理良好，因为团队只是按时“汇报完成”，并没有按时获得可靠结果。

七、不同情况下的行动建议：不要用同一套里程碑管理所有项目

1. 小型、周期短的项目

如果项目周期只有两到四周，参与人数少、依赖关系简单，就不必建立过于复杂的审批链。可以只设置启动确认、核心成果验收和最终交付三个里程碑，每个节点配一张简短的里程碑卡片。

这类项目最需要防范的是范围悄悄扩大。建议在启动节点明确“不包含什么”，在中间验收节点确认新增需求是否进入本次交付，在最终节点记录遗留事项，避免短项目被零散需求拖成长期项目。

2. 中大型、跨部门协作项目

当项目涉及多个部门、外部供应商或复杂系统集成时，里程碑必须同时记录依赖关系和验收责任。不能只由项目经理维护一张总表，而应让各责任团队对自己负责的交付物和风险状态承担确认责任。

对于100人以上组织或多个业务单元共同参与的项目，建议采用项目管理平台统一维护里程碑、任务、文档、缺陷和变更记录。这样做的重点不是“把表格搬到软件里”，而是让同一个里程碑关联完整的执行证据，减少信息散落在邮件、聊天记录和个人表格中的情况。

3. 研发和软件上线项目

研发项目可以把里程碑与需求基线、代码版本、测试结果、缺陷状态和发布记录关联起来。不要把“代码提交完成”直接当成“功能完成”，因为代码完成距离业务可用往往还隔着集成、测试、权限、监控和上线准备。

如果团队正在从其他项目管理系统迁移，尤其是从海外工具迁移到国产项目管理平台，应先梳理原有项目中的状态、字段、权限、工作流和历史数据，再设计迁移映射。支持平滑迁移并不意味着可以不做数据治理，历史字段命名混乱、重复项目和无效状态仍然需要在迁移前清理。

对于对数据隔离、合规和内部网络有要求的中大型企业，可以评估支持私有化部署的项目管理平台。私有化部署的取舍不只是采购价格，还包括基础设施、升级维护、权限治理、备份策略和运维责任。它更适合对数据控制和部署环境有明确要求的组织，不一定适合人员少、项目简单的小团队。

4. 市场活动和非研发项目

市场活动的里程碑不应套用“开发，测试，上线”的研发语言。更贴合的节点可能是活动方案批准、核心物料验收、供应商进场确认、现场演练完成、正式发布和效果复盘完成。

这类项目的风险通常集中在外部交付和时间窗口。活动一旦开始，延期几乎没有补救空间，所以应把“可替代方案是否准备好”纳入里程碑标准。例如主供应商未按时交付时，备用供应商、替代物料和审批路径是否已经准备完成。

5. 工程、采购和交付项目

工程项目需要特别重视现场条件和正式验收。设备“已发货”不等于设备“可以安装”，设备“已安装”也不等于“系统已经具备投产条件”。里程碑应区分到货、开箱验收、安装完成、单机试运行、联动试运行和正式移交。

对于采购和供应商协作，建议将合同约定、交付物格式、验收人和不合格处理方式写进里程碑定义。否则项目团队可能在供应商交付后才发现缺少检测报告、合规证明或操作手册。

八、不同情况下的取舍：时间、范围、质量和成本如何调整

1. 时间不能变时，先判断哪些范围可以后移

如果上线日期由客户合同、市场窗口或监管期限锁定，项目团队不能简单要求所有工作都按原范围完成。此时应把需求分为必须交付、可以降级和可以后移三类，并在里程碑评审时明确哪些内容进入本次版本。

这种取舍的关键不是“少做一些功能”，而是保护核心业务路径和质量底线。可以后移的是非关键功能，不能轻易牺牲的是安全、合规、数据完整性和关键交易流程。

2. 范围不能变时，要正视资源和成本增加

如果范围已经对外承诺，且不能通过拆分版本解决，就需要评估增加人力、延长工作时间、引入外部资源或调整优先级的成本。项目经理不能只向团队施加“加快速度”的压力，却不提供资源和决策支持。

资源增加也不是万能方案。新成员加入复杂项目需要熟悉业务和系统，短期内可能增加沟通成本。因此，在关键路径上增加资源前，应先判断任务是否可以并行、是否存在足够清晰的接口，以及新增人员能否在目标窗口内产生有效产出。

3. 质量底线不能变时，应允许交付日期变化

涉及资金、安全、合规、生命安全或核心客户数据的项目，不应为了守住日期而随意降低质量标准。此时应把延期风险量化，明确延期会影响什么、增加多少成本，以及谁有权批准最终取舍。

里程碑的作用之一，就是把这种取舍提前暴露出来。没有里程碑时，团队容易在最后一周被迫做出仓促决定；有清晰里程碑时，管理层可以在方案评审、测试验收或上线条件确认时进行选择。

4. 成本不能增加时，要优先降低复杂度

预算固定时，可以通过减少并行项目、复用已有组件、分批交付和推迟低价值功能来降低复杂度。但必须同步修改里程碑定义，否则原计划仍然会要求团队交付已经被取消或后移的成果。

每一次取舍都应留下记录，包括原始目标、调整内容、影响范围、批准人和新的验收标准。这样做既便于项目复盘，也能避免后续相关方按照旧计划追责。

九、用项目管理平台把里程碑从计划表变成执行证据

1. 什么时候值得使用专业平台

如果项目只有几个人、周期很短，一张共享表格就可能足够。但当团队超过100人、项目同时存在多个版本、跨部门依赖和复杂权限时，单纯依靠表格很容易出现版本不一致、状态更新滞后和验收证据分散的问题。

这时，项目管理平台的价值主要体现在四个方面：把里程碑与任务和交付物关联，把风险和缺陷挂接到具体节点，保留变更和审批记录，以及通过看板、甘特图或路线图提供不同层级的视图。

2. 以中大型组织的使用场景为例

以PingCode为例，它主要面向中大型企业以及100人以上组织。对于同时管理产品需求、研发任务、测试缺陷和发布计划的团队，可以将“需求基线确认”“版本验收”“上线条件确认”等里程碑作为跨团队协作的连接点，而不是单独维护一张项目日期表。

在实际落地时，我建议先从一个项目试点，不要一开始就把所有历史项目全部迁移。试点应重点观察三个结果：里程碑状态是否能及时更新，验收证据是否能够集中查看，延期后是否能快速识别受影响的任务和相关方。

对于有数据隔离、合规审查或内部网络要求的企业，PingCode支持私有化部署，可以作为国产化项目管理平台选型时的一个评估对象。若团队正在从Jira迁移，还应重点核对项目、任务、工作流、字段、权限、附件和历史记录的迁移范围，不能只看“是否支持迁移”这一项功能描述。

3. 平台选型不能只看功能数量

我在选型时更关注平台能否支持项目的真实管理动作，而不是功能列表有多长。建议从以下问题开始验证：

• 里程碑是否可以关联任务、交付物、缺陷、风险和变更？
• 是否可以为不同项目设置不同的验收字段和审批流程？
• 延期后能否查看受影响的后续节点和关键路径？
• 是否支持私有化部署、权限分级、数据备份和审计要求？
• 能否从现有工具平滑迁移，而不丢失关键历史记录？
• 管理层、项目经理和执行人员能否看到适合自己的视图？

如果平台只能展示日期，不能沉淀验收标准和执行证据，那么它只是更漂亮的日历。如果平台能把里程碑与任务、风险、文档和决策关联起来，才真正有机会成为项目治理的一部分。

十、可直接复制的项目里程碑模板与检查清单

1. 里程碑定义模板

下面这份模板适合放入项目计划、项目周报或项目管理平台的里程碑字段中：

里程碑名称：
所属项目/阶段：

目标结果：

关键交付物：

完成标准：

验收方式：

推动责任人：

最终验收人：

计划完成日期：

前置依赖：

当前状态：正常 / 预警 / 偏离

延期影响：

补救措施：

评审结论：

如果团队刚开始建立里程碑管理，不必一次填写所有复杂字段。最少也要保留“结果、交付物、完成标准、责任人、验收人、日期”六项。等团队形成习惯后，再增加风险、依赖、变更和复盘字段。

2. 里程碑评审清单

• 交付物是否已经提交，是否为最终版本？
• 完成标准是否逐项满足，而不是只听口头汇报？
• 是否存在阻断级问题、重大遗留事项或未确认依赖？
• 验收人是否已经给出明确结论？
• 项目是否具备进入下一阶段的条件？
• 延期是否影响关键路径、资源安排或外部承诺？
• 是否需要发起范围、预算、质量或时间变更？
• 下一步动作是否明确到具体负责人和日期？

3. 项目负责人可以立刻执行的三个动作

第一个动作，是从当前项目中挑出一个争议最大的节点。不要先改整张计划表，先选择一个最容易出现“有人认为完成、有人认为未完成”的节点，按照结果、交付物、标准、验收人和日期重新定义。

第二个动作，是把验收证据放到节点旁边。需求基线附需求清单，测试里程碑附测试报告，发布里程碑附发布和回滚方案，交接里程碑附交接记录。证据越接近节点，争议越少。

第三个动作，是在周会上只讨论有变化的里程碑。正常节点可以快速带过，把时间用于讨论预警和偏离节点：风险是什么、是否影响关键路径、谁需要做决定、下一次更新时间是什么。

十一、总结：好的里程碑，应该让项目更容易做决定

项目里程碑定义的核心，不是把计划表写得更满，也不是给每个任务增加一个醒目的标记。它真正解决的是项目协作中的共同判断问题：项目是否完成，是否可以进入下一阶段，是否需要调整资源，是否应该缩减范围，以及谁有权确认最终结果。

一套可执行的里程碑管理，至少包含五个步骤：明确目标和范围，拆解工作并筛选关键节点，把节点写成可验收的定义，配置时间、责任人和前置依赖，最后通过跟踪、预警和复盘形成闭环。

我最建议项目负责人记住的一句话是：不要问“这个里程碑什么时候完成”，先问“什么结果出现时，我们才有资格说它完成”。这个问题一旦回答清楚，日期、责任、交付物、验收和延期处理就会自然变得具体。

下一步，可以从当前项目中选择一个最关键的节点，使用下面这句话重新定义：在【截止日期】前，由【责任人】完成【关键成果】，交付【成果物】，并由【验收人】依据【验收标准】确认通过；如未达成，则在【时间点】前完成【补救动作】。

当团队能够用同一套标准判断一个节点是否完成，里程碑才不再是项目报表上的日期，而会真正成为项目管理中的决策支点。