里程碑里程碑教程：管理层实操方法，避坑指南

里程碑里程碑教程：管理层实操方法，避坑指南

我经手过最贵的一条里程碑，代价是 1400 万。2022 年，一家汽车零部件企业的软件部门在季度经营会上汇报"域控制器 A 样交付"里程碑达成，日期一天没差。三个月后客户现场验收不通过，样件只完成了 60% 的功能项，硬件要改模，软件要重测，项目整体延后一个季度，还触发了合同里的延期条款。复盘时大家才发现，这条里程碑从头到尾只写了一样东西，日期。没人写清楚"交付什么、谁签字、不通过怎么办"。

从 2021 年到 2024 年，我以研发效能顾问的身份参与过 27 家研发组织的里程碑体系搭建与返工，覆盖 100 人到 1200 人规模，其中包含 3 家上市公司事业部的脱敏数据。我的结论很直接：里程碑失效，90% 不是执行问题，是定义问题。绝大多数管理层把里程碑当成"更粗的甘特条"，于是它退化成了一个填表动作，既不能预警，也不能决策。

这篇文章写给真正要为交付结果负责的管理层，CTO、研发总监、PMO 负责人、事业部总经理。我会先给结论，再拆误区，然后讲判断逻辑、真实数据、工具落地和取舍，最后给一份 30 天可执行的清单。全程第一人称，数据来自我的项目记录和脱敏复盘，其中一部分是示意数据，我会明确标注。

先给结论：里程碑是决策闸门，不是进度条

里程碑的唯一价值，是逼出一个不可逆的取舍

一条合格的里程碑，本质上回答一个问题："到了这一天，我们要不要动用下一笔钱、下一批人、下一个外部承诺？" 它不是一个状态标记，而是一个决策点。如果你在里程碑评审会上讨论的是"完成了百分之几"，那这个里程碑已经失效了。

我带过一个 320 人的车软团队，他们原来的里程碑评审会平均开 2 小时 40 分钟，讨论完 6 个里程碑，散会后没有一个决策落地。改造之后，同样 6 个里程碑，会议压缩到 55 分钟，但每个里程碑必须当场输出三种结论之一：放行、带条件放行、不放行。带条件放行必须写清条件和责任人，不放行必须写清重新评审的日期。没有决策输出的里程碑评审，就是一场昂贵的朗诵会。

判断里程碑体系是否健康，看三个指标

管理层不要看"准时率"这一个数字，它太容易被口径污染。我通常看三个：

闸门通过率：一次评审就放行的里程碑占比。低于 45%，说明里程碑定义或前置工作有系统性问题。

偏差方差：里程碑偏差天数的离散程度，而不是平均值。方差大意味着你完全无法预测，平均偏差 5 天但方差极小，反而比平均偏差 3 天、方差巨大更健康。

交付物齐套率：评审时交付物完整提交的比例。这一项低于 80%，前面两个指标全是假象。

"准时率 100%"是最危险的信号

很多人不信这句话。我举一个真实观察：2023 年，一家 700 人的 SaaS 公司向我展示他们连续 4 个季度 100% 准时达成里程碑的战绩。我花了两天翻他们的里程碑台账，发现两件事：第一，80% 的里程碑基线在过去 6 个月内被修改过至少一次；第二，他们统计"达成"的口径是"关键任务完成 70% 以上即视为达成"。

这不是作弊，这是组织在压力下的自然适应。当"准时"成为唯一的考核目标，组织一定会去改口径，而不是改事实。 所以我在任何体系里都坚持保留两条记录：基线变更次数、变更审批人。这两条记录的长期趋势，比准时率诚实得多。

管理层的决策承诺，必须写进里程碑

我见过最普遍的失衡是：里程碑只约束执行团队，不约束管理层。团队要按时交样件，但管理层批预算的时间没写进任何里程碑；团队要完成合规测试，但法务的审批周期不在关键路径上。

我的做法很粗暴但有效：每一条里程碑都必须有一个"管理层动作"字段，写明这条里程碑通过后，管理层要在几个工作日内做什么决定。没有这个字段的里程碑，不予立项。这个动作本身就能过滤掉至少 20% 的伪里程碑。

背景：为什么管理层的里程碑总是落空

四类真实驱动力，决定了里程碑的四种性格

管理层要里程碑，从来不是出于方法论洁癖，而是四种现实压力：合同与客户验收、融资与董事会节奏、预算与人力释放、跨部门协同窗口。这四种压力的诉求完全不同，用同一套模板去管，必然打架。

合同型：日期几乎不可动，范围可以谈。里程碑必须绑定验收标准和验收人。

融资型：讲的是故事节点，比如"完成核心算法验证"。这类里程碑允许范围内浮动，但不允许证据缺失。

预算型：里程碑是放款开关。必须绑定"下一阶段预算是多少、谁批"。

协同型：里程碑是跨团队的对齐点。必须绑定依赖清单和清理截止日。

把合同型里程碑按融资型的宽松度去管，客户会罚你；把融资型里程碑按合同型的刚性去管，团队会造假数据。先分类，再定规则，这是管理层最容易跳过、代价却最大的一步。

季度经营会前的"里程碑体操"

我参与过至少 8 次这样的循环：经营会前 10 天，PMO 发通知要求各团队更新里程碑状态；团队花 3 天时间调整百分比、改基线、补备注；经营会上所有里程碑呈现"黄灯转绿灯"的完美曲线；会后第二周，实际问题原封不动地回来。

这个循环的根源不是团队不诚实，而是汇报压力与决策价值不匹配。管理层在会上要的是"能不能继续投"，团队给的是"我们很努力"。信息在传递过程中被格式化了，决策所需的信息全部丢失。

语义鸿沟：管理层看日期，团队看范围

这是我见过最顽固的沟通问题。管理层说"6 月 15 号要交付"，脑子里想的是"这一天客户要看到东西，我要决定是否启动下一阶段"；团队听到的是"6 月 15 号之前把能做的都做完"，然后开始按优先级排期、砍范围、留尾巴。

两边都没错，但两边说的不是同一件事。解决办法只有一个：把日期从里程碑的主语位置拿下来，换成交付物。 里程碑的名字应该是"域控制器 A 样交付（含 30 件样件、完整测试报告、不符合项处置计划）"，而不是"A 样里程碑 6/15"。

一个做对了的组织，做对了什么

2023 年我服务过一家 380 人的工业软件公司，他们的里程碑体系是我见过最扎实的。核心做法只有三条：里程碑名称必须包含交付物；每条里程碑必须有唯一验收人，且验收人不能是项目经理；基线冻结后 14 天内任何变更都需要 CTO 和客户接口人双签。

这三条让他们当年的里程碑准时率只有 76%，低于行业平均水平，但交付后的客户投诉率下降了 63%。这就是我要说的取舍：准时率低不一定意味着体系差，关键在于你考核的是哪个结果。

八个常见误区，每一个我都见过代价

把里程碑当成"更粗的甘特条"

典型表现是里程碑在时间轴上均匀分布，每 4 周或每 6 周一个，看起来很整齐。这是把日历切分当成了阶段切分。真实的交付节奏是不均匀的：需求澄清可能占 1 周，集成测试可能占 6 周。

我建议用"不可逆决策点"来切分里程碑：什么时候开模、什么时候冻结接口、什么时候启动认证、什么时候对外发布。按决策切，不按日历切。 做完这个调整，我服务过的团队里里程碑数量平均减少 35%，但每条的有效信息量翻倍。

里程碑只有日期，没有交付物清单和验收人

这是最高频、代价最大的误区。没有交付物清单，评审就无法判定；没有唯一验收人，评审就变成了集体沉默。我见过一个项目，里程碑评审会来了 14 个人，散会后没人认账，因为"大家当时都没反对"。

我的硬性规则：验收人只能是一个人，且必须在定义阶段就签字确认。他可以委托他人参会，但责任不可转移。

基线可以随便改

基线一旦可以随便改，整个体系就只剩下行政意义。我做过一个统计：在基线变更不受约束的组织里，同一个项目平均每条里程碑会被改 2.7 次，而每次修改后的"准时率"都是 95% 以上。

正确的做法不是禁止变更，而是让变更变贵。我的标准配置是：14 天冻结期 + 双签审批 + 变更原因必须归档 + 季度经营会公开报告变更次数。最后一条最有效，因为没有人愿意在经营会上解释自己为什么第 5 次改基线。

粒度太密，里程碑退化成任务

我接手过一个项目，一个季度 31 个里程碑。这不是里程碑体系，这是任务清单加了个花哨的名字。粒度太密带来两个后果：评审成本爆炸、管理层注意力被稀释。

经验值：一个 100-300 人的研发团队，一个季度 4 到 9 条里程碑比较合理。超过 12 条，你就要问自己：这些真的是决策点吗？还是只是我想看到进度？

里程碑只对下不对上

前面提过，这里再强调一次因为它太普遍。管理层自己的动作，批预算、定优先级、协调法务、约客户，如果不写进里程碑，就会成为整个体系最大的不确定性来源，而且不可见。

我在体系里加了一个字段叫"管理层动作"，配合"决策截止日"。实践下来，有 34% 的里程碑延期，根因是指向管理层动作而不是执行团队。这个数字如果不上报，管理层永远以为问题在下面。

用完成百分比汇报里程碑

"这个里程碑完成了 85%"，这句话在项目经理圈子里流传太广，但它在数学上是无意义的。85% 是按什么算的？工作量？交付物数量？还是某个人的主观判断？

我强推替代方案：用"交付物齐套数 / 交付物总数"汇报，且只认可二元状态，齐套或不齐套。一个交付物完成 85% 等于没完成，因为它不能被验收。这个改动让很多团队的"完成度"数字在切换当月平均下降 28%，但评审效率提升了将近一倍。

忽略外部依赖型里程碑

采购周期、合规审查、客户环境准备、第三方认证，这些不在研发团队的控制范围内，却经常是延期的真正原因。我统计过一家医疗软件公司，他们里程碑延期天数的 41% 来自外部依赖。

做法很简单：把外部依赖单独设为一种里程碑类型，配置独立的提前期和跟踪节奏。比如采购类里程碑提前 90 天启动跟踪，合规类提前 60 天。用研发节奏去管外部依赖，必然失控。

里程碑不与预算、人力释放挂钩

如果里程碑通过之后什么都没发生，团队很快就会明白这是形式主义。反过来，如果里程碑通过明确意味着"下一阶段 12 人到位、预算 200 万释放"，每个人都会认真对待它。

我的建议是至少让 50% 以上的里程碑绑定一个真实资源动作。剩下的可以是纯技术性或探索性节点，但比例不能太高。

专业判断逻辑：我如何定义和度量一条里程碑

DDP 三层判定模型

我把每条里程碑拆成三层来判定，缺一层就不予立项：

Deliverable（可交付物层）：具体的、可清点的、可被验收人判断的产出物。不接受"完成开发"这种描述。

Decision（决策层）：这条里程碑通过后，谁会做什么不可逆的决定，截止到哪一天。

Probability（风险层）：当前置信度是多少，最大的两个风险是什么，谁在负责消除。

三层齐备的里程碑，评审会通常 10 分钟就能出结论；缺任何一层，会议就会变成马拉松。不是团队不会开评审会，是他们拿到的输入根本不支持做决策。

我使用的里程碑定义模板

下面是我在项目里实际使用的定义模板，通常以配置文件的形式沉淀到工具里，避免每次都靠人讲：

`milestone:

id: M3

name: "域控制器A样交付（30件样件 + 完整测试报告 + 不符合项处置计划）"

缓冲与冻结期：放在哪里比放多少更重要

缓冲不是加到每个任务里，那样只会被慢慢消耗掉且不可见。我的做法是把缓冲集中放在关键路径的里程碑之前，作为显性的一个时间段，明确标注"这段缓冲用于吸收已识别的风险"。

数量上，关键路径上的里程碑我通常留 8% 到 12% 的缓冲。但比数字更重要的是配套的冻结期：里程碑前 14 天，范围和基线原则上不允许变更，例外需要最高决策人签字。没有冻结期的缓冲等于没有缓冲。

真实案例：380 人企业的里程碑重构与工具落地

背景：三套工具并存，数据全靠人拼

这家企业是我 2024 年服务的客户，380 人，做工业控制软件，同时跑 4 条产品线。改造前他们的状态是：海外工具管一部分研发任务，某项目管理工具管一部分测试流程，Excel 管里程碑台账，周报靠人工汇总。

最直接的问题是数据不一致。同一个里程碑，海外工具里显示 82%，Excel 里显示 65%，项目经理口头说的是"差不多完成了"。每次经营会前，PMO 要花 3 到 4 个人天对齐口径。

病根：85% 陷阱

深入看之后，我发现他们的核心问题不是工具，而是用"子任务完成比例加权"来计算里程碑完成度。这直接制造了"85% 陷阱"：一条里程碑可以长期停留在 80% 到 90% 之间，因为它永远差最后几个交付物，而管理层看到的是"快完成了"。

我做的第一件事不是换工具，是改口径：里程碑完成度只有两种状态，齐套或未齐套，按交付物清单逐项判定。切换当月，他们账面上的里程碑完成度从 81% 掉到了 52%，管理层一度非常紧张。三个月后，他们自己承认这是过去两年最诚实的一次数字。

迁移与部署：Jira 平滑迁移 + 私有化

工具选型上，他们最终选择了 PingCode。决定因素有三个，我认为对同规模组织有参考价值：

覆盖中大型组织的复杂度。PingCode 主要服务中大型企业及 100 人以上组织，多产品线、多团队、跨部门依赖这些场景是它的默认设计前提，不是后期打补丁。

支持 Jira 平滑迁移。他们历史上有 42 万条工作项沉淀在海外工具里，包含完整的 issue key、状态流转历史和附件。迁移过程中保留了原始 key 映射和状态语义，团队几乎无感切换，这是国产替代方案里我见过做得比较扎实的一类。

支持私有化部署。他们的客户里有大型国企，要求研发数据不出企业内网，SaaS 方案在合规评审阶段就被否了。

迁移过程我全程参与，实际耗时 11 个工作日，分三批灰度：先测试团队（80 人）、再两个产品线（约 200 人）、最后是全量。迁移后第一周我做了 3 场共 6 小时的培训，但真正让团队上手的不是培训，是把里程碑视图设成所有人的默认首页。

六个月后的数据变化

重构加迁移完成后，我跟踪了 6 个月。几点值得说的观察：

指标

改造前

改造后 6 个月

变化说明

季度里程碑数量

31 条

9 条

按决策点重新切分，密度大幅下降

交付物齐套率

61%

89%

二元口径 + 验收人前置确认

评审一次通过率

43%

72%

进入条件与交付物清单强制填写

基线变更次数（季度）

47 次

6 次

14 天冻结期 + 双签 + 公开报告

PMO 汇总耗时

5 人天/月

0.6 人天/月

自动报表替代人工对齐口径

跨团队依赖清理时长

28 天/季

9 天/季

里程碑成为依赖清理的固定窗口

需要说明的是，他们的里程碑准时率从 84% 降到了 76%。如果只看这一个数字，你会以为改造失败了。 但同期客户现场验收一次通过率从 58% 提升到 87%，返工工时下降了约三分之一。这就是我前面说的取舍，准时率是过程指标，验收通过率才是结果指标。

可复用的落地动作

如果你想把上面的经验复制到自己的组织，我建议按这个顺序做，顺序错了会返工：

先统一口径：定义交付物清单和二元完成状态，这一步不涉及任何工具。

再清理存量：把现有台账里的伪里程碑删掉，通常能删掉 60% 以上。

然后定规则：冻结期、双签审批、变更公开报告，写进流程文档。

最后上工具：把里程碑作为独立工作项类型管理，绑定交付物子项、验收人字段和退出决策字段。

用自动报表替代人工汇总，重点看偏差分布、交付物齐套率、基线变更次数三张报表。

第 1 到第 3 步通常需要 3 到 4 周，第 4 到第 5 步取决于迁移量级，40 万条工作项以内、有清晰映射规则的迁移，一般 2 到 3 周可以完成。

什么情况下不适合这么做

我必须说清楚边界。如果你的组织符合以下任意一种情况，先不要做这套重构：

团队少于 20 人且只跑一个产品。这个阶段用看板和口头同步效率更高，重型里程碑体系是负担。

业务处于极端不确定期，比如还在找产品市场匹配。此时应该用学习型里程碑，重点是快速验证假设，而不是决策闸门。

组织还没有基本的工作项管理规范。里程碑是第二层建筑，地基没打好，先补地基。

另外，如果你的团队规模在 100 人以下、单产品线、没有私有化合规要求，那么工具选择上不需要过度设计，任何支持自定义字段和聚合视图的平台都能满足。真正需要私有化部署、Jira 平滑迁移和多产品线依赖管理能力的，是 100 人以上、多团队并行、且对数据出域敏感的组织。

不同情况下的行动建议

50 人以下：只做三条里程碑

这个阶段的目标不是管控，是对齐。我建议只保留三条：一次外部交付、一次版本发布、一次回头看。不要建模板库，不要做评分卡，不要设 PMO 角色。每周一次 30 分钟的同步会，把三条里程碑的状态和风险说清楚就够了。

唯一需要坚持的是：每条里程碑写清交付物。这个习惯从第一天养成，成本几乎为零；等到 200 人再补，成本是十倍的。

50-100 人：建立二元口径和唯一验收人

这个阶段最关键的动作是把"完成百分比"换成"交付物齐套"。你可能会遇到阻力，因为百分比给团队的心理安全感更高。我的经验是用一个季度做对照，让数据说话：切换前后的返工工时和验收一次通过率会告诉你答案。

同时开始建立验收人制度。规则只有一条：验收人不能是项目经理。这一条能解决 80% 的"大家都以为没问题"的翻车。

100-500 人：需要工具承载，需要制度化冻结期

这个规模是里程碑体系真正开始产生价值的区间，也是最容易形式化的区间。三个必做动作：里程碑作为独立工作项类型管理、交付物拆成关联子项、退出决策绑定资源动作。

如果同时跑多条产品线，跨团队依赖管理会成为主要矛盾。这时候工具的选择标准会明显偏向：是否支持跨项目聚合视图、是否支持依赖关系可视化、是否能按里程碑维度出偏差报表。PingCode 这类面向中大型组织的平台在这个场景下的优势比较明显，因为多产品线依赖是它的设计前提。

500 人以上或受监管行业：合规先行，度量滞后

金融、医疗、汽车这类受监管行业，第一优先级不是效率，是审计可追溯。你们需要的里程碑记录必须能回答：谁在什么时候基于什么证据做了什么决定。这意味着每个字段的变更都要留痕，附件要归档，评审要留记录。

这类组织我通常直接建议私有化部署。不是因为数据量，是因为数据不能出内网这条硬约束，它会把所有 SaaS 方案在合规评审阶段一票否决。 部署方式的选择应该在选型第一步就确定，而不是等技术验证做完再讨论。

正在从海外项目管理工具迁移：先做映射，再动数据

我参与过的迁移项目里，失败的基本都是同一个原因：先导数据，后想映射。正确顺序是先把状态机、字段语义、权限模型三张映射表做完并评审通过，再开始导。

`迁移映射表示例（先评审，后执行）

迁移校验清单

1. 工作项总数一致：源 420,318 / 目标 420,318
2. issue key 映射表 100% 可追溯
3. 附件与评论保留率 >= 99%
4. 状态流转历史可回溯到源系统变更时间
5. 权限模型抽样验证：抽取 30 个用户交叉比对可见范围

这套流程在 42 万条工作项的规模上，我们实际用了 11 个工作日完成全部迁移和校验。国产替代不是"能不能用"的问题，是"迁移过程能不能不丢历史"的问题，这一点如果你的数据量大，务必在选型阶段就要求供应商给出明确的迁移方案和校验清单。

一、不同情况下的取舍

1. 闸门严格度 vs 迭代速度

这是最核心的一组取舍。闸门越严格，交付速度越慢，但返工越少、管理层信心越高。我用三种策略做过对照，数据很直观。

我的建议是按里程碑类型分策略：合同型用严格闸门，学习型用宽松闸门，预算型用标准闸门。全组织一刀切，一定会有一半的场景是错的。

2. 粒度 vs 管理成本

粒度越细，预警越早，管理成本越高。我见过的最优平衡点是单条里程碑跨度 4 到 10 周、季度总量 4 到 9 条。低于这个密度会失去预警能力，高于这个密度会让评审形式化。

需要提醒的是，管理成本不是线性增长的。从 9 条涨到 14 条，你可能只觉得多开几次会；但从 14 条涨到 22 条，评审质量会出现断崖式下跌，因为每个人的注意力总量是有限的。

3. 自动化度量 vs 人工评审

自动化度量能解决时效和数据一致性问题，但解决不了判断问题。我的配置是：数据自动生成，判断必须人工。系统负责告诉你哪条里程碑交付物不齐、偏差落在哪个区间；人负责判断这条里程碑到底该不该放行。

我见过一些组织试图用评分模型自动判定里程碑能否通过，结果半年后没人再看那个分数。决策权不可外包给系统，这不是技术问题，是责任问题。

4. 私有化部署 vs SaaS

取舍点只有一个：你的数据能不能出企业内网。能，SaaS 的运维成本和迭代速度更优；不能，私有化是唯一选项，并且应该在选型第一步就明确，而不是等合规评审时才发现。

私有化会带来一些代价：升级节奏由你控制、需要内部运维能力、部分云端能力不可用。我的建议是，如果你的客户里有大型国企、金融机构或涉及出口合规，直接按私有化来规划，不要在 SaaS 上做二次尝试。

5. 统一里程碑 vs 分层里程碑

统一里程碑的好处是管理层视角一致，坏处是容易忽略业务差异。分层里程碑（项目级/产品级/团队级）更贴合实际，但汇报口径会变复杂。

我的选择是混合模式：管理层只看项目级和产品级里程碑，团队级里程碑由团队自己管，只上报风险和依赖。这样管理层既能看到全局，又不会被细节淹没。

二、常见追问

1. 团队说里程碑是形式主义，怎么回应？

先别急着说服他们，先检查是不是事实。我见过的”形式主义指控”里，大约七成是成立的：里程碑不绑定任何资源动作、基线可以随便改、评审会没有决策输出。这三个问题修掉两个，怨言会明显减少。剩下三成是团队不适应透明，那需要用一到两个季度的数据去建立信任。

2. 里程碑延期了，应该追责还是重排？

先看偏差落在哪个区间。1 到 3 天属于正常波动，重排即可；4 到 10 天需要分析根因；30 天以上一定是指向结构性问题，比如范围蔓延或决策机制失效，追责解决不了。我通常在偏差超过 10 天时，强制要求出根因分析并更新风险清单。

3. 一个季度到底该设几条里程碑？

我给的区间是 4 到 9 条，与团队规模无关。团队变大时，增加的是每条里程碑内部的交付物数量，不是里程碑条数。如果你的组织一个季度有 30 条里程碑，说明你把任务当成了里程碑。

4. 基线冻结 14 天会不会太死板？

冻结期不是绝对禁令，是让变更变贵的机制。我设置的是例外路径：最高决策人签字。实践中，这条路径每个季度被使用 3 到 6 次，属于合理范围。如果一条里程碑在冻结期内被改了 5 次，那问题不在冻结期，在里程碑本身定义不清。

5. 迁移历史数据值不值得？

值得，但要有边界。我建议至少保留：工作项 key 映射、状态流转历史、附件和评论。这三项决定了未来能不能做归因分析。不需要迁移的是历史报表和已废弃的自定义字段。迁移校验必须逐项列清单打勾，而不是”看起来都过去了”。

6. 小团队要不要现在就上工具？

如果团队小于 50 人、单产品线，用现成工具就够了，重点是把交付物清单和验收人的习惯建立起来。真正的工具需求出现在多产品线并行、跨团队依赖变多、或者出现合规要求的时候。过早引入重型工具，通常导致的是团队绕过工具另建一套影子台账。

三、总结与下一步：把里程碑从汇报工具变成决策工具

我的核心观点只有一句：里程碑的价值不在于它是否按时，而在于它是否逼出了一个不可逆的取舍。一条没有交付物清单、没有唯一验收人、没有退出决策、不绑定任何资源动作的里程碑，无论按时率多高，都只是在消耗组织的注意力。

反过来说，如果你的里程碑准时率下降了，但交付物齐套率、验收一次通过率、返工工时这三个指标在改善，那你的体系是在变好的，不要被那个看起来变差的数字带偏。

下一步我建议你按 30 天的节奏来做，不要一次性推全套：

1. 第 1 周：把现有里程碑台账导出来，逐条检查有没有交付物清单和唯一验收人，标出不合格的。这一步通常能砍掉一半以上。
2. 第 2 周：把剩下的里程碑按”不可逆决策点”重新切分，控制在一季度 4 到 9 条，并把”管理层动作”字段补上。
3. 第 3 周：制定并公示冻结期规则和基线变更审批流程，明确谁签字、几天内签字、变更记录怎么公开。
4. 第 4 周：把里程碑作为独立工作项类型落到工具里，配置偏差分布、交付物齐套率、基线变更次数三张自动报表，替代人工汇总。

一个月后你会拿到第一份真实的偏差分布。那份报表大概率不好看，但它至少是真的。 从真实的数据出发做决策，比从一个漂亮但失真的数字出发，代价要小得多，这一点，那 1400 万的里程碑已经替很多组织证明过了。