里程碑节点状态全流程：跨部门团队入门指南与一文讲清

三周前，我参与复盘了一个 137 人的软硬件联合团队项目。他们的核心里程碑在系统里连续 21 天显示同一个状态，"进度 80%"。第 22 天，供应链侧的准入评审卡住，整条产线排期被迫后推 6 周，直接损失约 240 万元。复盘会的第一个问题是：为什么系统里那个 80%，没有任何人觉得有问题？答案很朴素，市场部说的 80% 是"宣传物料准备到 80%"，研发说的 80% 是"接口联调完成 80%"，而项目经理看到的 80%，是两边上报数字的平均值。

同一个里程碑，三套语义，一个数字。这不是执行问题，是状态定义问题。这篇文章把跨部门里程碑状态的全流程拆开讲清楚：状态怎么定义、谁来判定、证据是什么、什么时候流转、卡住了怎么升级、关掉了怎么归档。

一、先说结论：里程碑状态不是进度百分比，而是承诺兑现的证据等级

如果你只从这篇文章带走一句话，我希望是这句：里程碑状态不是一个"多少"的问题，而是一个"凭什么"的问题。进度百分比回答的是"做了多少"，而里程碑状态回答的是"我们能不能在这个时间点对外承诺这件事已经成立"。前者是内部估算，后者是对外部世界（客户、老板、监管、下游团队）的一份契约。

把这两件事混在一起，是跨部门团队最容易犯、也最贵的错误。因为进度百分比天然是模糊的、可协商的、可以"再努力一点就上去了"的；而契约状态必须是二元的、有证据的、可以追溯到某个人某个时间的。

1. 三条可以立刻验证的硬结论

结论一：状态由证据定义，不由百分比定义。一个里程碑能不能标成"已达成"，取决于是否存在一份可被第三方独立验证的交付物，一份签字的评审记录、一个通过全部用例的测试报告、一张现场验收单。如果没有这份东西，它就是"未达成"，哪怕所有人都说"差不多了"。这条规则的残酷之处在于它不给"努力"留位置，但它给"可预测"留了位置。

结论二：状态判定权必须与执行权分离。谁写代码谁说自己完成，这不是不行，但风险极高。跨部门场景下更可靠的做法是：执行方提交证据，判定方（通常是里程碑 Owner 或独立的 PMO/质量角色）确认状态。这不是不信任，而是把"我尽力了"和"它成了"两件事分开记录，防止语义漂移。

结论三：每一次状态流转都必须带时间戳和责任人，否则归档不可信。我见过太多项目，里程碑最终"达成了"，但没人能说清楚是哪一天达成的、依据什么达成的。这在事后复盘、审计、客户追责、甚至内部结算时都是灾难。状态流转日志不是给流程看的，是给未来的人看的。

2. 这套方法论能解决什么，不能解决什么

它解决的是"信息不对称"和"责任稀释"。当三条业务线的里程碑状态都建立在证据和统一判定标准上时，项目经理的周会就不会变成语义辩论会，延期会提前 2-4 周暴露，而不是在上线前 10 天。

它解决不了"资源不足"和"目标本身不合理"。如果里程碑的日期从一开始就是拍脑袋定的，状态管理做得再好，也只是把一个错误更早、更清楚地暴露出来。这其实已经是巨大收益了，早暴露的错误是可修复的，晚暴露的错误只剩余额。

二、背景与真实场景：跨部门里程碑为什么总是"看起来在推进"

要理解里程碑状态为什么会失真，得先理解跨部门协作的物理结构。同一个里程碑，在不同部门眼里是完全不同的东西：对研发它是技术就绪，对市场它是可宣传，对供应链它是可备料，对法务它是可签合同，对财务它是可确认收入。这些"就绪"的时间点、判定标准、证据形式都不一样。

1. 一个真实场景：137 人团队的智能硬件首发项目

这个项目我介入时已经进入第三个版本迭代。三条线：研发线（约 60 人）、供应链线（约 30 人）、市场与渠道线（约 47 人）。核心里程碑叫"产品可量产首发"，计划时间是 6 月 30 日。

系统里，这个里程碑的状态从 5 月初开始就是"进行中"，附带的进度是 80%。到了 6 月 8 日，供应链侧突然反馈：关键物料的替代料验证还没做完，量产评审无法通过。此时距计划首发只有 22 天。而市场侧的预售已经铺出去了。

事后拆解发现，这 80% 是怎么来的：研发侧完成度按任务数算是 85%，供应链侧的"物料寻源"任务标了完成，但"替代料可靠性验证"这个子任务当时还没建进系统，市场侧按铺货进度算是 70%。三个数字平均一下，约 80%。这个 80% 不是任何一个人的真实判断，它是系统按权重算出来的一个数字，而这个数字被当成了事实。

2. 跨部门里程碑的四组结构性矛盾

矛盾一：目标不同步。研发的关键路径是技术风险收敛，供应链的关键路径是提前期，市场的关键路径是渠道窗口期。三条路径长度不同，但在同一个里程碑上被强行对齐到同一天。

矛盾二：语言不同频。"完成"在研发语境里可能是"代码合入主干"，在供应链语境里是"供应商确认交付"，在市场语境里是"素材可发"。同一个词，三种门槛。

矛盾三：责任不同层。研发的里程碑负责人通常是技术负责人，能当场决策；供应链的负责人往往需要向上走一层审批；市场的负责人可能只能承诺资源不能承诺时间。决策层级不同，导致状态流转速度天然不同。

矛盾四：节奏不同拍。研发按两周迭代走，供应链按周走，市场按活动节点走。三种节拍叠加，状态更新的时间点在系统里看起来是错乱的。

3. 状态失真的三条典型路径

路径一：延迟上报。执行人倾向于等到"有把握"再更新状态，于是状态更新天然滞后。这不是撒谎，是人性的乐观偏差。后果是风险暴露时间被系统性地压缩。

路径二：语义漂移。"完成 80%"这种表述是最危险的，因为它没有定义分母。同样的 80%，分子可能是"任务数"，可能是"工时"，可能是"人们对它的信心"。

路径三：责任稀释。当三条线共同负责一个里程碑时，"谁先说实话谁吃亏"的现象就会出现。先承认自己这条线有风险的一方，往往在资源争夺中处于不利位置，于是所有人都倾向于保持乐观口径。

这三条路径的共同点是：它们都不会被"更努力地执行"解决，只能被"更严格的状态定义"解决。

三、拆解常见误区：为什么大多数团队的状态管理一开始就错了

我在超过 40 个团队的流程评审里反复看到同样的五个误区。它们看起来都很合理，甚至被写进了流程文档，但每一条都会在跨部门场景下放大失真。

1. 误区一：用完成百分比表达里程碑状态

这是最普遍也最致命的一条。百分比在跨部门场景下的问题不是"不准"，而是"不可比"。研发的 60% 和市场部的 60%，经过汇总后得到的数字，数学上成立，业务上无意义。

我的判断很直接：里程碑层面不应该存在任何百分比字段。里程碑状态只允许是离散的枚举值，比如"未开始 / 进行中 / 有风险 / 已阻塞 / 待验证 / 已达成 / 已取消"。百分比只允许出现在里程碑内部的工作项层面，而且必须明确分母是什么。

（1）百分比会掩盖三种不同性质的问题

技术问题（还差多少工作量）、依赖问题（等别人交付）、判定问题（做完了但验收没过），这三类问题在百分比里长得一模一样，但需要的应对动作完全不同。技术问题要加人，依赖问题要升级，判定问题要走评审。一个 80% 让管理者无法分辨该做哪件事。

（2）百分比会制造"虚假的进度感"

从 70% 到 80% 感觉很快，从 90% 到 100% 感觉很难，这不是错觉，是真的难。越接近终点，剩余问题越可能是最难的那些。用百分比表达，恰好掩盖了这个最需要被看见的规律。

2. 误区二：把"任务完成"等同于"里程碑达成"

任务完成是过程指标，里程碑达成是结果指标。一个里程碑下面的所有任务都标了完成，里程碑依然可能是未达成的，因为验收标准可能在任务列表之外。

我常用的检验方法是：问一句"如果现在对外宣布这个里程碑达成了，谁会第一个跳出来说'等等'？" 如果这个问题有明确答案，说明还缺一个关键证据，或者缺一个关键判定人。

3. 误区三：把状态更新的责任完全交给执行人

执行人更新状态的动机是"汇报"，不是为了"风险预警"。这两个动机天然冲突。当一个人的绩效和"我负责的部分是否延期"绑定时，指望他主动把状态改成"有风险"，是结构性的不现实。

更可行的设计是：执行人只负责提交证据和阻塞项，状态判定由里程碑 Owner 或独立的项目办公室角色完成。这样执行人没有"改状态"的心理负担，反而更愿意早说问题。

4. 误区四：用一个共享表格管理跨部门状态

共享表格在 20 人以下团队里是够用的。但到了 100 人以上、三条以上业务线并行时，表格会暴露三个致命缺陷：没有权限边界（谁都能改）、没有变更历史（改了什么不可追溯）、没有自动化校验（状态和证据之间没有约束关系）。

我见过最典型的场景是：一个 12 列的状态表，三条线各自维护自己的列，颜色标记靠手动涂。到第 8 周时，表里同一行出现了互相矛盾的三种颜色，最后靠一次两小时的会议才对齐。这不是工具问题，是"表格无法承载状态机的约束"。

5. 误区五：状态只上报，不下发

很多团队的状态流转是单向的：下级报给上级，上级汇总后再报给更上级。但跨部门协作中，真正需要状态信息的是平级的下游团队，他们需要知道上游能不能按时交付，才能决定自己要不要启动。

状态不透明给下游，等于让下游用猜的方式排自己的计划。这是跨部门延期最常见的传导机制。

四、专业判断逻辑：里程碑状态全流程的六段式模型

把上面的问题反过来设计，就是一套可执行的流程。我把它归纳为六段：定义入口、统一判定、绑定证据、约束流转、强制升级、闭环归档。这六段是顺序依赖的，跳过任何一段，后面都会出问题。

1. 第一段：入口，里程碑的准入定义

一个里程碑要能被建进系统，必须先回答六个问题：它的目标是什么（一句话，不含术语）、它的达成标准是什么（可验证的）、它的证据是什么（具体到文件类型）、它的 Owner 是谁（唯一一个人）、它的依赖方是谁（具体到团队和个人角色）、它的最晚决策时点是什么（倒推出来的）。

这六个问题答不全的，不进系统。听起来严格，但它节省的是后面无数次的争议成本。我在一个 500 人规模的研发组织推这套规则时，第一周被卡掉了 14 个"里程碑"，其中 9 个后来被证明本质上是任务而不是里程碑。

（1）准入定义的模板

下面是我在 PingCode 里常用的里程碑定义模板，写成结构化字段后可以直接作为工作项描述模板复用。每一行都有实际约束作用，不是格式装饰。

milestone:
name: "产品可量产首发"

owner: "供应链-张（唯一责任人）"

target_date: "2026-06-30"

decision_deadline: "2026-06-08" # 最晚决策点，超过则触发升级

success_criteria:

"替代料可靠性验证报告通过（三方实验室出具）"

"量产评审会议纪要签字完成"

"首批 500 台良率 ≥ 96%"

evidence_required:

type: "实验室报告"

submitter: "供应链"

verifier: "质量"

type: "评审纪要"

submitter: "研发"

verifier: "产品"

dependencies:

"研发-固件 V2.3 冻结"

"市场-预售物料合规审查"

state_enum: ["未开始","进行中","有风险","已阻塞","待验证","已达成","已取消"]

state_authority: "里程碑 Owner"

auto_escalate:

on_state: "已阻塞"

after_hours: 48

to: "项目办公室 + 各线负责人"

2. 第二段：判定，状态枚举与严格定义

状态枚举的数量不重要，重要的是每个状态都有"什么情况下必须选它"的硬规则。多数团队的问题是枚举太少（只有进行中/已完成），导致所有细微差别都被压进"进行中"这一个黑洞里。

这张表的价值在于"最长停留"这一列。状态本身不产生压力，状态停留时长才产生压力。当一个里程碑在"有风险"状态停留超过 7 天没有变化时，系统应该自动提醒，要么给出应对方案，要么升级，不能一直挂着。

3. 第三段：证据，每个状态背后必须有可验证的交付物

"已达成"必须有证据，"待验证"必须有已提交的证据，"有风险"必须有书面记录的应对方案，"已阻塞"必须有明确的阻塞描述和期望解决时间。这四个状态如果只是文字描述，就等于没有。

我通常要求证据满足三个条件：可独立查看（不是口头说明）、有明确产出时间、有明确责任人。管理层的角色不是去看每一份证据，而是知道"这份证据存在且可以被抽查"。这个可信度是整套机制的基石。

4. 第四段：流转，状态变更的触发与时限

跨部门场景下，状态流转最大的敌人不是"没人更新"，而是"更新了但没人知道"。所以流转机制里必须包含通知规则：谁的状态变了，要通知哪些下游团队，用什么方式通知。

我建议的最小规则集是：状态变为"有风险"时，通知所有下游依赖方；变为"已阻塞"时，通知下游依赖方 + 上级 + 项目办公室；变为"已达成"时，通知下游依赖方，触发其前置条件解除。

5. 第五段：升级，阻塞的升级路径与时效

升级机制最关键的不是"往哪升"，而是"多久升"。我见过太多团队写了升级路径，但没有时限，结果阻塞状态挂了三个星期才被讨论。

一个可用的经验值是：团队内无法解决的阻塞，48 小时内必须升级到上一层；上一层 72 小时内无法解决的，继续升级并同步影响面。这个时限要在系统里自动计时，而不是靠人记得。

6. 第六段：归档，里程碑关闭与复盘

归档不是把状态改成"已达成"就结束了。归档要留存四样东西：最终状态与达成时间、支撑证据清单、状态流转历史（完整时间线）、与计划的偏差及原因。这份归档是下一个项目估算的现实依据，比任何估算模型都准。

五、具体案例与数据观察：100 人以上团队怎么真正跑通

上面讲的是方法，接下来讲落地。中大型组织（100 人以上）和中小团队最大的差别是：中小团队靠人和默契就能把状态对齐，而 100 人以上的组织必须靠系统约束，因为跨过部门边界后，默契就失效了。

1. PingCode 上的里程碑建模实践

PingCode 主要服务中大型企业及 100 人以上组织，这一点在我的实践中体现得很明显：它把"计划/里程碑"和"工作项/迭代"分成两层对象，而不是把里程碑当成一个特殊的任务类型。这个设计选择对状态管理很关键，因为里程碑的状态判定逻辑和工作项完全不同，硬塞在一起会导致判定标准被稀释。

具体做法是：里程碑作为计划层的对象，只保留离散状态字段、Owner、决策时点、证据清单和依赖关系；具体执行放在工作项层，保留百分比、工时、迭代等过程字段。两层之间通过关联关系连接，但不共享状态字段。这样管理层看的是里程碑状态，执行层看的是工作项进度，两者不会互相污染。

在数据观察上，我给一个真实的对比参照。一个 180 人的研发组织在迁移到这套机制前后，我跟踪了 12 周：

• 里程碑延期发现时点：从平均"计划日前 6 天"提前到"计划日前 24 天"
• 跨部门状态对齐会议时长：从每周 5.5 小时降到 2 小时
• 状态变更的可追溯率：从 0%（表格覆盖式更新）提升到 100%（每次变更留痕）
• "已达成"后被推翻的比例：从 19% 降到 3%

最后这个数字是最有价值的。"已达成后又推翻"是状态系统可信度的终极指标，它下降意味着组织真的开始相信系统里的状态了。

2. Jira 生态迁移场景下的里程碑状态映射

大量中大型组织面临的实际问题不是"从零开始"，而是"从 Jira 迁过来"。这里有一个非常具体的坑：Jira 的 Epic 常常被拿来当里程碑用，但 Epic 的状态枚举是围绕工作流设计的（To Do / In Progress / Done），没有"有风险""待验证"这些跨部门判定所需的状态。

PingCode 支持 Jira 平滑迁移，也是国产替代的常见选择之一。但我要提醒的是：迁移的时候如果只是把 Epic 的状态字段原样搬过去，你会把旧问题一起搬过去。正确的做法是借迁移这个窗口做一次状态枚举的重新设计，把 Epic 映射为里程碑对象，丢掉原有的工作流状态，按跨部门判定需求重新定义状态机。

迁移时我建议重点核对三件事：一是历史状态变更记录是否随对象一起迁移（这决定了归档是否可用）；二是权限模型是否能把"状态判定权"和"执行权"分开配置；三是自动化规则能否在状态停留超时时触发通知。

3. 私有化部署与权限边界对状态流转的影响

PingCode 支持私有化部署，这在跨部门状态管理上有一个容易被忽略的好处：状态数据的可见范围可以被精确控制。在很多组织里，"状态不透明"不是不想透明，而是不敢透明，有些里程碑涉及商务条款、人事调整或未公开的产品计划，不适合全员可见。

私有化部署加上细粒度权限后，可以实现"状态对下游团队可见、证据对特定角色可见"的分层透明。这解决了一个真实矛盾：下游需要状态才能排期，但不应该看到全部细节。公有云工具在这个场景下往往需要靠额外脱敏流程来补，成本高得多。

4. 不同规模组织在状态维护上的成本结构差异

有一点必须说清楚：状态管理不是免费的。它消耗的是执行人的填报时间和判定人的确认时间。如果不承认这个成本，流程一定会退化成形式主义。

我观察到的规律是：50 人以下团队，状态维护成本主要落在项目经理一个人身上，人均负担高但总量小；100-500 人团队，成本分散到各线对接人，总量上升但可控；500 人以上或跨多条产品线时，如果没有系统和自动化支撑，成本会非线性上升，因为对齐会议的时长是按线数平方增长的。

5. 一次里程碑延期的成本叠加实录

回到文章开头那个硬件项目。我把那次延期的成本拆开算过一遍，值得所有做硬件的团队参考：物料替代验证延期 6 周，导致产线排期后推，产生产线空置成本约 90 万元；预售已铺出，改期产生渠道补偿约 62 万元；团队在最后 3 周集中攻坚，加班成本折算约 48 万元；后续客户信任修复投入约 40 万元。合计约 240 万元。

而如果在 5 月初就把状态标成"有风险"并触发升级，最早能做的是提前启动替代料的并行验证，成本大约是 12 万元的加急验证费。也就是说，状态管理这件事在那一个项目上的杠杆率大约是 20 倍。

六、不同情况下的行动建议

方法论是通用的，但落地路径必须按组织情况裁剪。下面是按规模和场景分层的具体建议，可以直接拿去对照自己的团队。

1. 50 人以下团队：先加一个"待验证"状态就够

小团队不需要复杂的七状态机。最有效的单点改动是：在"进行中"和"已完成"之间插入"待验证"，并规定必须由非提交人确认。仅这一条，就能消除大部分"我以为做完了"的问题。

同时建议取消里程碑层面的百分比字段，改为三个离散状态。执行成本几乎为零，收益立竿见影。

2. 100-500 人团队：建立判定权和升级时效

这个规模的关键动作有两个：一是指定每个里程碑的唯一 Owner，且 Owner 不一定是执行负责人；二是给"有风险"和"已阻塞"设定停留时限，超时自动升级。这两条要在系统里配置成规则，不能靠人记。

工具层面，这个规模已经不适合用共享表格承载状态机了。PingCode 这类面向 100 人以上组织的平台，在里程碑与工作项分层、权限边界、变更留痕上的支持会比较顺手；关键在于配置方式要与前面的六段式模型对应，而不是简单套用默认模板。

3. 500 人以上或多产品线：先做状态标准化，再谈自动化

大组织的失败模式通常是"先上工具、后定标准"，结果是把混乱搬进了系统，还额外付出了工具成本。正确的顺序是：先统一定义（目标是达成标准的表述模板）、再统一状态枚举、然后才配置系统和自动化。

自动化能做的事有三类：状态停留超时提醒、依赖解除自动通知、证据提交后的验证任务自动创建。这三类覆盖了 80% 的人工协调工作。

4. 正在从 Jira 迁移的团队：借迁移窗口重构状态

不要把迁移做成"数据搬家"。迁移是最好的重构时机，因为此时大家对变更的容忍度最高。重点是把旧的 Epic 工作流状态丢弃，按跨部门判定需求重新定义里程碑状态机，同时确保历史变更记录一并迁移，否则归档会断档。

PingCode 支持 Jira 平滑迁移，这能显著降低搬迁成本；但迁移方案的设计质量，仍然取决于你有没有先把状态定义想清楚。

5. 有数据敏感性或合规要求的组织：把权限边界当第一需求

如果组织涉及未公开产品、商务条款或受监管数据，私有化部署不是"可选加分项"，而是前置条件。PingCode 支持私有化部署，这类场景下要重点验证的是：状态可见范围能否按角色和团队分层、证据附件能否单独授控、变更日志能否导出用于审计。

七、不同情况下的取舍：没有一套配置适合所有团队

流程设计本质上是取舍。我在推这套机制时被问得最多的不是"怎么做"，而是"做到什么程度才够"。下面是我对五个主要取舍点的判断。

1. 状态粒度 vs 维护成本

状态越多，表达越精确，维护成本越高。我的经验是：状态数量控制在 5-7 个是甜点区。少于 5 个会丢失关键区分（比如"有风险"和"已阻塞"必须分开），多于 7 个则会出现大量状态长期无人使用，反而增加判定争议。

另一个技巧是：把"程度"信息从状态里剥离出去，放到备注或标签里，不要让状态承担程度表达。状态描述的是"性质"，不是"严重性"。

2. 强制证据 vs 推进速度

要求每个状态都绑定证据，会让流转变慢。这个代价是值得付的，但要有选择地付。我的做法是："已达成"和"待验证"强制绑定证据，"有风险"只强制绑定应对方案（可以是一句话），"进行中"不要求任何额外输入。

这样既保证了终点的可信度，又不会让日常推进负担过重。

3. 统一平台 vs 各团队自治

统一平台的价值在于状态可比、数据可汇总；代价是各团队的个性化流程被压缩。在大组织里，我倾向于"状态枚举统一、工作流可自治"，里程碑的状态定义必须全组织一致，因为跨部门判定需要共同语言；而工作项层面的流程允许各团队按需调整。

这个分界点很重要。把统一做到状态层，把自由留给执行层。

4. 自动化判定 vs 人工判定

自动化适合处理"条件明确"的判定，比如"证据文件已提交且验证人已确认"→ 自动流转到"已达成"。但涉及风险评级、影响面评估这类需要判断的，仍然应该由人来做。

一个实用的分界线是：如果判定标准可以用一句 if-then 说清楚，就自动化；如果需要解释背景，就留给人。

5. 升级机制的"硬度"

升级机制太软，阻塞会被无限挂起；太硬，会制造大量"形式升级"，占用管理层时间。我的建议是分级：影响单一团队的阻塞，48 小时团队内升级；影响跨部门交付的，24 小时升级；影响对外承诺日期的，立即升级并同步所有下游。

关键不是升级到多高，而是升级后必须有人明确"接住"，给出决策或者重新分配资源。没有人接住的升级，等于把问题换了个地方放着。

八、一页纸落地清单：从下周一开始做什么

方法论讲完，最后给一份可以直接执行的清单。我不建议一次性全上，那必然失败。按两周一个批次推进，每批次只改一件事，改完观察两周再继续。

1. 第一批次（第 1-2 周）：把状态定义改对

1. 选 3 个正在进行的跨部门里程碑做试点，不要全量。
2. 为每个里程碑指定唯一的 Owner，且这个人不一定是执行负责人。
3. 删除里程碑层面的百分比字段，改成 5-7 个离散状态。
4. 为每个状态写清楚"什么条件下必须选它"，写成一句话，贴在团队可见的地方。

2. 第二批次（第 3-4 周）：把证据和判定权接上

1. 为每个里程碑列出"已达成"所需的证据清单，具体到文件类型。
2. 指定每个证据的提交方和验证方，验证方不能是提交方。
3. 把"进行中 → 待验证 → 已达成"这条链路跑通一次真实的里程碑。

3. 第三批次（第 5-6 周）：把时限和升级开起来

1. 为"有风险"设 7 天停留时限，为"已阻塞"设 48 小时时限。
2. 在系统里配置超时自动提醒，提醒对象包括下游依赖方。
3. 记录每一次升级的响应时间，作为下一轮优化的依据。

4. 第四批次（第 7-8 周）：归档与复盘

1. 把试点里程碑的状态流转历史完整导出一次，看是否可读。
2. 统计延期发现时点、对齐会议时长、"已达成后推翻"比例这三个指标。
3. 用这三个指标和试点前的基线对比，决定是否扩大范围。

这三个指标里，我最看重的是"已达成后推翻"比例。它衡量的是组织对系统状态的信任度。如果这个比例在 3 个月后降到了 5% 以下，说明这套机制真的在起作用，而不只是一份漂亮的流程文档。

回到最初那个 240 万元的教训。它真正的成本不是那 6 周，而是那 21 天里，137 个人都在看着一个不可信的数字，却没有任何机制迫使他们说出真相。里程碑状态管理的全部意义，就是让真相有一个必须被说出来的地方。