去年我复盘一个 9 个月周期的企业级项目时，看到一组让我印象很深的数字：周报里里程碑的“绿灯率”常年维持在 92%，但最终 5 个关键里程碑按原计划完成的只有 2 个。更荒诞的是，直到交付前两周，甘特图上还挂着四个绿色的菱形。这不是某个团队马虎，而是里程碑状态被当成“心情播报”之后的必然结果。
里程碑节点状态这件事，看起来是个填色块的小动作，实际上它决定了三件事：资源还要不要继续投、风险要不要提前暴露、上级的预期要不要现在修正。这三个决策一旦建立在失真的颜色上，后面所有的补救都是加倍成本的。
这篇文章我把过去几年做项目治理、工具落地和复盘时积累的判断整理出来，包括一套可落地的五态判定模型、八个高频误区、以及不同组织规模下该怎么取舍。如果你正在负责一个跨部门、周期超过 3 个月的项目，这篇内容可以直接拿去改你现在的里程碑模板。
一、核心结论：里程碑状态是决策信号，不是进度装饰
先把结论说清楚：里程碑状态的本质，是给决策者提供一个“是否继续按当前方式投入”的判断依据。它不负责描述工作量完成了多少，也不负责表达团队的辛苦程度。一旦你把状态当成进度条来用，它就必然失真。
1. 里程碑状态回答的是“能不能继续投”的问题
任务进度回答的是“做了多少”，里程碑状态回答的是“这个阶段的目标是否已经达成、能不能进入下一阶段”。这两件事的判定依据完全不同。
我见过太多团队把里程碑状态等同于“关联任务完成度”：任务完成 90% 就打绿灯，完成 60% 就打黄灯。问题是，一个支付模块的 90% 完成度，可能刚好卡在“联调没做、对账没验、异常分支没测”的位置上，它的实际可交付性是零。
里程碑状态的判定依据必须是“证据”，而不是“完成比例”。证据是可以被第三方验证的产物：评审记录、测试报告、上线截图、验收签字、接口联调日志。没有证据的进度，在里程碑层面一律不算数。
2. 三种状态不够用，需要五态模型
红黄绿三态模型最大的问题是：它把“还没开始”“正在进行”“已经延期”压缩进了同一个颜色里，导致汇报人和决策者对同一个颜色的理解完全不同。项目负责人说黄灯的意思是“我在努力追”，领导看到黄灯理解成“还有救，不用管”。
我现在统一使用的是五态模型：未开始、进行中、有风险、已延期、已达成。关键区别在于把“进行中”和“有风险”彻底分开。前者是正常推进、证据链完整；后者是出现了明确的偏差信号，需要决策者介入。
再补一个实践细节：每个状态都必须绑定一个“进入条件”，而不是靠感觉切换。比如“有风险”的进入条件可以是“关键路径上的依赖项延迟超过 3 个工作日”或“已完成任务中返工率超过 15%”。条件写死在模板里，汇报时就没有讨价还价的空间。
3. 状态的颜色由证据决定，不由汇报人决定
这句话听起来有点绝对，但它是我踩过最大的坑之后总结出来的。只要状态还是“汇报人主观评定”，那么组织压力、面子、季度考核就会不断把红色染成黄色。
正确做法是把状态判定变成一次可复算的操作：给定一组证据，任何人都能得出同一个颜色。这就要求里程碑定义里必须写清楚“完成证据清单”和“状态判定规则”。下面这段配置是我在一个中大型项目里实际使用的里程碑定义片段，可以直接参考：
milestone:
name: 核心交易链路联调完成
owner: 后端负责人（唯一责任人）
due_date: 2024-08-16
evidence_required:
联调环境全链路用例通过率 >= 95%
性能压测报告（P95 = 1 且未触发风险条件
at_risk: 关键路径依赖延迟 > 3 工作日 或 返工率 > 15%
delayed: due_date 已过 且 证据未齐
achieved: 全部 evidence_required 已归档且通过评审
这段配置的意义在于，它把“状态”从一个形容词变成了一个函数。项目负责人不再需要为颜色辩护，只需要说清楚哪条证据还没到位。
二、背景与真实场景：里程碑状态为什么会系统性失真
失真的原因不是某个人不诚实。我观察下来，它是组织激励、汇报结构和工具设计共同作用的结果。理解这一点很重要，否则你会把治理重点放在“要求大家如实汇报”上，而这几乎不可能奏效。
1. 一个 9 个月项目的三次“绿灯翻车”
那个项目有三个关键里程碑：架构评审通过、核心链路联调完成、UAT 验收通过。三次翻车的过程几乎一模一样。
第一次，架构评审在截止日前一天被标为绿灯，理由是“评审会已经开过了”。但实际情况是会上有 3 个技术选型争议没有结论，只是被记为“会后跟进”。第二次，联调完成被标为绿灯，理由是“接口全部开发完毕”，但上下游环境还没打通，真实联调一次都没跑过。第三次，UAT 验收绿灯，理由是“业务方口头确认没问题”，而正式的验收签字单拖了三周。
三次翻车指向同一个机制缺陷：里程碑状态的判定，被交给了“最希望它是绿灯的那个人”。
2. 失真有组织原因，不是个人诚信问题
第一个原因是汇报链的逐层美化。一线负责人报黄灯，部门负责人在汇报前会倾向于“再看看”，到了项目层往往就变成了绿灯。每一层修正的幅度可能只有 10%，但 4 层叠加之后就是完全不同的结论。
第二个原因是里程碑与考核挂钩。当里程碑达成率直接进入团队绩效，理性选择就是尽量延后承认风险。这不是道德问题，是激励设计问题。
第三个原因是工具层面的模糊。很多项目管理工具的里程碑只是个日期字段加一个颜色标签，没有任何证据挂载点，也没有状态变更历史。这等于把判定权完全交给个人记忆。
3. 里程碑状态与任务完成度的混淆是根源
大部分团队的项目管理工具里，里程碑只是一个特殊类型的任务，或者一个带日期的标签。这种设计天然鼓励人们用任务思维管理里程碑，看完成度、看剩余工时、看燃尽图。
但里程碑和任务在管理逻辑上是两类对象。任务是可拆分的、可并行的、可替代的；里程碑是不可拆分的、串行的、不可替代的。一个里程碑只有“达成”和“未达成”，没有“达成 70%”这种中间态。
我现在的做法是：里程碑不设完成百分比字段，只保留状态、证据、责任人、判定日期四个核心字段。把百分比从里程碑上拿掉之后，团队讨论的焦点自然就从“做了多少”转向“证据够不够”。
三、拆解八个高频误区
下面这八个误区是我在不同规模团队里反复见到的。它们的共同点是：单看都很合理，组合起来就把里程碑状态彻底架空了。
1. 误区一：用任务完成百分比折算里程碑状态
典型做法是“里程碑下所有任务完成 80% 以上打绿灯”。问题在于，项目后期最难的部分往往集中在剩余 20% 里。集成、联调、性能、安全、验收，这些工作的难度曲线是非线性的。
更隐蔽的问题是任务权重。如果里程碑下有 50 个任务，其中 45 个是文档和小修改，5 个是核心开发，那么按数量算完成度会严重虚高。除非你给每个任务单独定权重，否则百分比就是一个没有意义的数字。
2. 误区二：把“没有坏消息”当作绿灯
这是最普遍的一种。负责人没有收到问题反馈，就把状态标为绿灯。但“没有坏消息”和“有证据证明达成”是两件完全不同的事。
我在评审时习惯问一个问题：“如果现在让你拿出这个里程碑已完成的证据，你能拿出来几份？”如果答案是零，那么无论进度看起来多顺利，状态都不应该是绿灯。
3. 误区三：里程碑只设一个负责人
反过来，有些团队走另一个极端：里程碑不设明确责任人，或者设了一堆“共同负责人”。结果是没人真正对状态负责。
我的建议是单一责任人 + 协作人清单。责任人负责状态判定和证据归档，协作人负责提供各自领域的证据。责任人的名字必须出现在里程碑卡片上，而不是藏在会议纪要里。
4. 误区四：用顶点评审代替过程验证
很多团队只在里程碑到期那天做一次评审。这种做法的问题是把风险发现的时间点推到了最晚。等到评审时才发现证据不全，补救周期已经被压缩到极限。
更好的做法是设置“中期证据检查点”，大约在里程碑周期的 50%-60% 位置。这个检查点不判定状态，只检查证据链的完整性，用来提前暴露缺口。
5. 误区五：状态只向上汇报，不向下对齐
里程碑状态如果只出现在给领导的周报里，团队一线是感受不到的。结果就是上层以为一切正常，下层知道问题很大，信息在中间断裂。
我的做法是把里程碑状态和证据清单放进团队日常可见的项目视图里，任何人都能看到当前状态和缺失的证据项。透明本身就是一种压力。
6. 误区六：里程碑定在交付日而不是交付前
把里程碑日期定在最终交付日，等于取消了里程碑的缓冲价值。里程碑的意义是在交付前给你一个“还来得及调整”的检查点。
我一般会把关键里程碑的日期设置在对外承诺日期前 10%-15% 的位置。9 个月的项目，就是提前 3-5 周。这段时间就是给状态失真的修正留的窗口。
7. 误区七：状态更新频率跟着会议走
如果状态只在周会上更新，那么它的时效性就是一周。对于关键路径上的里程碑，一周的延迟足以让整个计划崩掉。
我的经验是分频率管理：关键路径里程碑每天或每两天更新一次状态，非关键路径每周更新一次。更新频率应该由里程碑在关键路径上的位置决定，而不是由会议节奏决定。
8. 误区八：不做里程碑状态的复盘归档
项目结束后，里程碑卡片就被归档了，没人去看当时的状态变更历史。这浪费了最有价值的一类数据：你什么时候第一次意识到风险、当时做了什么判断、判断对不对。
我现在要求项目复盘时必须拉出里程碑状态变更时间线，重点看三个点：第一次从绿灯转黄灯的时间、黄灯持续时长、以及转红灯之前有哪些信号被忽略了。
四、专业判断逻辑：里程碑状态的判定标准
讲完误区，接下来是我实际在用的判定方法。它包含四个部分：证据定义、五态规则、置信度分层、趋势替代快照。
1. 定义每个里程碑的“完成证据”
这是所有工作的起点。如果里程碑的完成证据没定义清楚，后面所有的状态判定都是主观的。
证据定义要满足三个条件：可归档、可验证、可由第三方复现。比如“性能达标”不是证据，“压测报告显示 P95 为 620ms 且报告已归档到指定目录”才是证据。
我常用的证据类型清单包括：评审纪要（含结论和待办）、测试报告、接口契约冻结单、上线记录、验收签字、监控数据截图。每类证据都要指定归档位置，否则到期时会出现“报告在某人电脑里”的情况。
2. 五态判定规则与进入退出条件
下面这张表是我现在使用的标准五态定义，可以直接作为模板使用：
| 状态 | 进入条件 | 退出条件 | 需要的动作 |
|---|---|---|---|
| 未开始 | 里程碑周期未启动，无证据提交 | 提交第 1 份证据 | 确认责任人与证据清单 |
| 进行中 | 证据提交 ≥ 1 且未触发风险条件 | 证据齐全或触发风险条件 | 按节奏更新证据状态 |
| 有风险 | 关键依赖延迟 > 3 工作日，或返工率 > 15%，或证据缺口 > 30% | 缺口收敛或转为已延期 | 24 小时内给出补救方案并上报 |
| 已延期 | 截止日已过且证据未齐 | 证据补齐并完成评审 | 重排下游计划，修正对外承诺 |
| 已达成 | 全部证据归档并通过评审 | ， | 归档状态变更记录 |
这张表的关键在于每个状态的进入条件都是可观测的。“返工率超过 15%”和“证据缺口超过 30%”这类阈值，让状态判定从一场争论变成了一个计算。
3. 置信度与状态分开记录
我把“状态”和“置信度”设计成两个独立字段。状态描述当前的事实，置信度描述对按期达成的把握程度，用高/中/低三档。
举例来说，一个里程碑可以是“进行中 + 置信度低”。这种组合比“有风险”更有信息量：它说明目前没有明确的偏差信号，但团队对能否按期完成没有把握。这两类问题需要完全不同的应对方式。
4. 用燃尽趋势代替单点快照
单点状态最大的问题是它没有历史。我看到一个绿灯，不知道它是从黄灯变过来的，还是一直就是绿的。
所以我要求每个里程碑保留状态变更记录：谁在什么时候、基于什么证据、把状态从什么改成了什么。这条时间线在复盘时的价值，远高于任何一份周报。
五、数据与案例观察：一个中大型组织的里程碑治理改造
下面这个案例来自我参与过的一个 300 人左右研发组织的治理项目，周期 6 个月，涉及 4 个业务线和 2 个平台团队。这个规模的组织正好处在“小团队靠沟通、大团队靠机制”的临界点上，问题暴露得比较充分。
1. 改造前的基线情况
改造前的状况很有代表性：里程碑在工具里只是一个带日期的标签，没有责任人字段，没有证据挂载点。状态靠周会口头汇报，会后再由 PMO 统一填色。
我们做基线测量时发现几个数据：里程碑状态的平均更新间隔是 7.2 天，状态变更记录为零（因为系统里没有这个功能），跨团队依赖有 61% 只存在于文档和聊天记录中，没有进入任何可追踪的字段。
改造前的最后一个季度，有 3 个关键里程碑出现了“到交付日才发现未达成”的情况，平均补救成本是 86 人天。
2. 工具层落地：从标签到可追踪对象
这个组织原本使用的是海外商业项目管理工具，后来因为合规和成本原因做了一次迁移。他们最终选择的是 PingCode，主要考虑是支持私有化部署，同时支持从原有工具平滑迁移历史数据。
迁移过程中有一个细节值得说：历史里程碑数据能不能完整带过来，直接决定了治理改造能不能站在历史基线上。如果迁移后所有历史里程碑都变成空白，那么你的第一次复盘就失去了参照系。PingCode 在这方面的迁移能力，让这次改造少走了至少一个月的弯路。
迁移完成后，我们把里程碑从标签升级为独立对象，补齐了四个字段：唯一责任人、证据清单、状态（五态）、置信度（高中低）。
3. 改造后的数据变化
改造运行两个季度后，我们对比了几个关键指标。状态平均更新间隔从 7.2 天降到 1.8 天（关键路径里程碑），依赖项进入系统字段的比例从 39% 提升到 94%，里程碑状态变更记录实现了 100% 留存。
最能说明问题的是“到交付日才发现未达成”的次数：从每季度 3 次降到 0.3 次。折算下来，单季度节省的补救成本大约在 200 人天量级。
这里必须说清楚一点：这些改善不是工具自动带来的，工具只是让机制变得可执行。如果没有五态定义和证据清单，换成任何工具都只是把标签换了个地方放。
4. 颗粒度实验：里程碑数量与预测准确度的关系
改造过程中我们还做了一个小实验：把同一个项目的里程碑从 8 个拆到 23 个，再合并到 5 个，观察哪种颗粒度下的状态预测最准。
结论是 8-12 个里程碑区间表现最好，预测偏差率约为 11%。拆到 23 个时，管理开销急剧上升，负责人每周花在更新状态上的时间超过 5 小时，反而导致更新质量下降，偏差率上升到 19%。合并到 5 个时，颗粒度太粗，风险暴露不及时，偏差率高达 27%。
这个实验支持了一个判断：里程碑不是越多越精细越好，存在一个管理成本与预测精度的平衡点。对一个 6-9 个月的项目，8-12 个里程碑是比较务实的区间。
六、不同情况下的行动建议
里程碑治理没有一套通用方案。下面按组织规模和场景给出四组建议，你可以直接对照自己的情况取用。
1. 100 人以下团队：轻机制、重透明
这个规模的团队沟通链路短，不需要复杂的审批流。核心是把状态和证据放进一个所有人都能看到的地方。
第一步，给每个里程碑指定唯一责任人，写进项目视图。第二步，定义 2-4 条完成证据，不用多，但要可验证。第三步，状态用五态，但允许一周更新一次，关键路径例外。
这个阶段最容易犯的错是引入过重的流程。100 人以下的团队，如果每个里程碑都要走评审会，管理成本会超过收益。这个阶段的目标是让状态可信，而不是让流程完备。
2. 100-500 人、多项目并行：机制化、可追踪
这个规模是里程碑管理最容易失控的区间。跨部门依赖变多，汇报层级变长，单靠沟通已经无法保证信息准确。
关键动作有三个：一是把跨团队依赖从文档搬进系统字段，让依赖可视化；二是设置中期证据检查点，在里程碑周期 50%-60% 位置做一次证据完整性检查；三是强制留存状态变更记录，为复盘提供数据。
工具选择上，这个规模的组织通常需要支持多项目视图、依赖关系管理和权限分层。PingCode 主要服务中大型企业及 100 人以上组织，在这类场景下的多项目依赖追踪和 私有化部署 能力是可以覆盖的。
3. 强合规或私有化部署场景：数据主权优先
金融、政务、军工类客户对数据存放位置有硬性要求。这时工具选型的首要标准不是功能丰富度，而是能不能私有化部署、能不能保证里程碑状态和证据数据不出内网。
同时要考虑迁移成本。很多组织是从海外工具迁过来的，历史里程碑数据的完整性直接影响治理基线。支持平滑迁移的方案，能省掉大量人工补录工作，也让第一次复盘有据可依。
这个场景下还有一个常被忽略的点：审计要求往往需要状态变更的完整追溯链。所以从第一天起就要打开状态变更记录，而不是等到审计前再补。
4. 外包与多方协作场景：证据前置、责任切分
多方协作最大的风险是责任边界模糊。里程碑状态在这里的作用是切分责任：谁的证据没到位，谁承担延期。
我的做法是把证据清单写进合同附件，明确每项证据的交付时间和格式要求。状态判定以证据为准，不接受口头确认。里程碑节点的付款条件也和证据挂钩，这样双方对状态的理解就自然对齐了。
七、不同情况下的取舍
里程碑治理本质上是一组取舍。想清楚取舍边界，比追求完美方案更重要。
1. 状态精度 vs 更新成本
五态模型比三态模型精确，但也意味着更多判断和更多沟通。如果一个项目的周期只有 6 周，团队 8 个人，那么用三态加一个置信度字段可能就够了。
判断标准是：状态失真的代价是否大于精确管理的成本。如果一次误判会导致几十人天的返工，那就值得上五态；如果误判的影响在两天内可以消化，就没必要。
2. 统一模板 vs 项目自治
统一模板便于横向对比和向上汇总，但会牺牲项目特性。研发项目和实施项目的里程碑结构差异很大，强行统一会导致模板被形式化填写。
我的折中方案是统一元数据，放开内部结构。状态定义、证据类型、责任人字段、更新频率这些必须统一；里程碑的数量、名称、具体证据内容由项目自己定。
3. 工具自动化 vs 人工判断
自动化能解决状态更新的及时性问题，比如通过代码提交、构建结果、测试通过率自动推算状态。但自动化也有边界：它只能推算可量化的部分，无法替代对“证据是否充分”的判断。
我的做法是自动化负责触发提醒和汇总数据，人工负责最终状态确认。任何自动推算出的状态变更，都必须由责任人在 24 小时内确认或修正，否则视为未确认。
4. 强管控 vs 团队自驱
强管控能在短期内提升状态真实性，但长期会消耗团队信任。如果每个里程碑都要上级审批状态，团队会倾向于把精力放在“怎么让状态通过审批”上，而不是解决问题。
更可持续的做法是把状态透明化而不是审批化：状态和证据对所有人可见，但不需要层层审批。用透明带来的同伴压力替代审批带来的行政压力。
八、把里程碑状态变成组织能力
回到开头那个 92% 绿灯率的项目。它真正的问题不是有人撒谎，而是整个组织没有一套能把“感觉”翻译成“证据”的机制。里程碑状态失真只是这个机制缺失的一个表征。
我的核心观点是：里程碑状态的价值不在于它有多准确，而在于它是否能触发正确的决策。一个准时变黄的里程碑，比一个迟到的红灯有价值得多。前者给了你调整的窗口，后者只给了你追责的理由。
如果你现在就想动手改，我建议按这个顺序推进：
- 先挑一个正在进行的项目，把它的里程碑数量控制在 8-12 个，把完成百分比字段删掉。
- 给每个里程碑写 2-4 条可验证的完成证据，指定归档位置和唯一责任人。
- 把状态改成五态，把进入条件写进模板，尤其是"有风险"的量化阈值。
- 在里程碑周期的 50%-60% 位置加一个证据完整性检查点。
- 打开状态变更记录，坚持一个季度后做一次复盘，看第一次转黄灯的时间是否提前了。
这五步做完，你大概率会发现一个反直觉的结果：里程碑变黄、变红的次数变多了，但项目的实际交付反而更稳了。因为风险终于在你还有时间处理的时候浮出了水面。
最后提醒一句：不要指望一次改造就到位。里程碑治理是个持续迭代的过程，第一个季度能把证据链跑通就已经很好了。真正难的不是定义规则，而是在压力来临时，仍然坚持用证据说话。
常见问题解答（FAQ）
1. 里程碑状态到底怎么判定，任务全部关闭就算完成了吗？
我第一次带项目时，看到里程碑下面的任务都关闭了，就直接在周报里写已完成，结果客户验收时发现交付物还没签字。后来我被追问进度时特别没底，因为不知道任务关闭和里程碑完成之间到底差什么。到底应该用哪些证据来判断里程碑状态？
不能把任务关闭等同于里程碑完成。建议给每个里程碑定统一完成口径：交付物产出、验收标准满足、关键干系人确认三项都满足才算已完成；只有任务关闭但未验收，应标待验收或进行中。状态建议固定为未开始、进行中、风险中、已完成、已取消五种，项目负责人每周至少更新一次，关键里程碑每天或隔天更新。
判定证据至少留三类：交付物链接、验收记录或邮件确认、依赖方书面回复。进度计算不要按任务数量简单平均，可按里程碑权重或交付物权重，例如交付物完成占百分之四十，验收通过占百分之四十，干系人确认占百分之二十，这样周报上的百分比才有解释力。
2. 里程碑状态更新总是失真，项目负责人怎么做才能让状态可信？
我遇到过团队每周都报进行中，到了截止日才发现关键依赖没到位，状态一下子从正常变成延期。我作为项目负责人很怕被问为什么之前没有预警，也担心自己变成只会催进度的传声筒。状态更新到底应该看哪些信号，才能提前发现风险而不是事后补锅？
状态可信的关键不是让成员口头报百分比，而是把状态绑定到可验证信号。建议每周固定一次状态校准会，只做三件事：核对交付物是否更新、核对依赖方是否回复、核对验收标准是否变化；任何一项没有证据，状态就不能写正常。
可以用红黄绿三色加风险中状态，绿灯要求关键路径无阻塞且未来七天无未决依赖，黄灯要求有阻塞但有明确解决人和日期，红灯要求已影响里程碑日期或验收标准。更新频率按里程碑风险分级，高风险里程碑每周两次，普通里程碑每周一次。若连续两周状态没有实质变化，项目负责人要主动发起根因分析，而不是等截止日。
3. 里程碑节点应该拆多细，项目负责人怎么避免节点太多或太粗？
我以前做计划时，为了显得控制力强，把里程碑拆得很细，结果每周都在更新状态，团队觉得形式主义。后来拆得太粗，又发现中期根本没有检查点，风险全堆到最后。我到底应该按什么原则来划分里程碑，才能既管得住又不增加无效工作量？
里程碑应挂在阶段结果上，而不是日常任务上。判断标准有三条：每个里程碑必须有明确交付物、明确验收人、明确最晚确认日期；两个里程碑之间建议控制在两到六周，超过六周就增加检查点，少于一周则合并成任务。数量上，一个季度项目控制在五到九个里程碑比较实用，超过十二个通常说明拆得太碎。
拆解时先写阶段输出，再倒推依赖和决策点，最后才排日期。项目负责人要重点管三类节点：需要外部确认的节点、跨团队交付的节点、影响预算或上线决策的节点，其余内部任务不必都升级成里程碑。
4. 里程碑已经延期或风险很大时，状态怎么改、基线要不要调？
我经历过一次里程碑延期，团队有人建议直接把日期往后改，这样周报看起来就不算延期。我也拿不准，怕不改基线所有人都盯着旧日期，改了又像在掩盖问题。作为项目负责人，面对延期时到底应该怎么处理状态、基线和向上沟通？
先区分事实状态和应对状态。事实状态要如实标风险中或已延期，不能因为调整目标日期就把历史延期抹掉；应对状态可以提出重新基线，但必须附带原因、影响和补救计划。建议动作是：二十四小时内确认延期事实并记录原基线日期；三天内给出影响范围，包括后续里程碑、资源、预算和验收；一周内和关键干系人评审是否重新基线。
重新基线要满足两个条件：原日期已不可能达成，且新计划有可验证的依赖承诺。沟通时用三段式：当前事实、影响判断、需要谁在什么日期前做什么决定。数据口径上，建议同时保留原计划和当前预测两个日期，避免用新日期覆盖历史，这样复盘时才能看出延期发生在哪个环节。
核心关键词
文章包含AI辅助创作：里程碑节点状态教程：项目负责人最佳实践，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/344444
读者评论
五态模型里把“进行中”和“有风险”分开这点我认同，但落地时遇到一个问题：进入条件写得越死，汇报人越容易在边界上做文章，比如返工率 14.9% 就坚决不报有风险。后来我们在模板里加了一条，证据归档滞后超过两个工作日也自动转有风险，才算堵住这个口子。工具支持状态自动流转比人肉判定重要得多。
瀑布图那个逐层抬色的归因我持保留态度。8 个百分点的汇报美化看着不多，但实际项目里更常见的是中层自己也不知道一线真实情况，不是善意修正而是信息根本没传上来。我们做过一次跨部门项目，问题出在依赖方压根没把延迟同步给下游，不是谁在粉饰。所以治理顺序上，我可能会先解决依赖同步机制，再谈颜色纪律。
把里程碑的完成百分比字段直接删掉这个做法我试过，短期有效，但团队会想办法在别的地方补回来，比如在里程碑描述里手写“已完成 80%”。后来我们改成保留一个只读的进度参考字段，但不参与状态判定，反而争论少了。另外提前 10%-15% 设里程碑日期，对小团队可能过重，三个月项目提前四五周，很多需求还没冻结。