2023 年下半年，我参与了一家 420 人规模 SaaS 公司的季度复盘。他们内部系统里记录着 Q3 共 17 个里程碑，按期完成 15 个，按期率 88%，看上去相当健康。但当我和交付负责人把这 17 个里程碑逐个翻出来核对验收物时，真正能拿出可评审证据、并且被业务方书面确认的只有 6 个，真实按期验收率 35%。
这 53 个百分点的落差，就是《里程碑计划实操方法》要解决的全部问题。它无关团队是否努力，而关乎一件事：你们的里程碑，到底是一个可以被裁决的决策节点，还是一个只在周报里存在的汇报符号。
这篇文章我会把自己过去四年在中大型研发组织里做里程碑制度改造的方法、踩过的坑、可复制的模板和取舍逻辑完整拆开。内容包含四层制度结构、里程碑卡片模板、评审会 15 分钟议程、默认动作规则，以及不同规模组织该怎么做选择。
一、核心结论：里程碑效率的本质是”可裁决性”，不是执行力
先把结论放在最前面。我做过 31 个项目的交付复盘，反复验证同一个规律：里程碑延期的主因很少是”做不出来”，绝大多数是”没人能在正确的时点对正确的事做出裁决”。
换句话说，里程碑效率的问题不在执行层，而在制度层。执行层能优化的是速度，制度层决定的是方向是否可信。
1. 里程碑是决策节点，不是汇报节点
大部分企业把里程碑设计成”到点了通知一下相关方”。这类里程碑天然没有约束力，因为它的输出物是一句状态描述，而不是一个必须做出的决定。
真正有效的里程碑，到点必然触发以下三者之一：继续投入、调整范围、终止投入。如果一个里程碑到点后什么都不需要决定，那它就不该存在。
我在做制度设计时有一条硬性检验标准：把某个里程碑删掉，如果没有任何决策会因此改变，那这个里程碑是冗余的。这条标准通常能砍掉一个项目 30%，40% 的”伪里程碑”。
2. 用一个指标衡量里程碑制度健康度：水分指数
很多管理者会看按期率，但按期率是个容易被”管理”的数字。我更推荐看另一个派生指标：
里程碑水分指数 = 按期声明率 − 真实验收率（单位：百分点）
分子端的”按期声明”指的是工具或周报里标记为按期完成；分母端的”真实验收”指的是有验收证据、有裁决人签署、且计入后续基线。两者差值越大，说明制度的证据层和裁决层越薄弱。
下面这组数字来自我 2021，2024 年参与复盘的 31 个项目、40 余次里程碑评审会的记录整理，属于个人样本推演，不是行业普查，但趋势非常稳定。
3. 制度设计的优先级顺序：先定义，再证据，最后才是工具
我见过太多团队一上来就换工具、配模板、加字段，结果三个月后一切照旧。原因是顺序错了。
正确的顺序是：先解决”什么算里程碑”（定义层），再解决”怎么证明做到了”（证据层），然后解决”谁说了算、多久内说了算”（裁决层），最后才是”做不到会怎样”（后果层）。工具只负责承载这四层，它本身不产生约束力。
这条顺序判断，是我在两家公司花了将近 8 个月试错换来的。先上工具的做法，会得到一个数据很漂亮、决策很空洞的系统。
二、背景与真实场景：里程碑为什么会”集体漂移”
“里程碑漂移”是我自己的叫法，指的是里程碑的日期基本不变，但交付内容持续缩水，最后用”完成度”这种模糊口径收尾。它比直接延期更危险，因为延期是可见的，漂移是不可见的。
1. 场景一：日期不动，内容缩水
一个典型的例子是”完成数据迁移”。原定 8 月 15 日完成，到了 8 月 14 日，负责人的表述变成”完成核心表迁移，边缘表下周补”。里程碑被标记为按期，但交付物的边界被悄悄改写了。
制度上的解法不是催进度，而是在里程碑设立时就把”完成”的定义写死，并写清哪些不算完成。反面清单往往比正面清单更有用。
2. 场景二：会议开完了，结论没有
我参加过一场 90 分钟的里程碑评审会，19 个人，讨论了依赖、风险、资源三件事，最后主持人的总结是”大家再拉个会细化一下”。这就是典型的无裁决会议。
评审会必须有一个明确的输出物，而且只能是三种之一：通过、有条件通过（附条件与截止日）、不通过（附补救方案与下次评审时间）。没有第四种输出。
3. 场景三：工具里全是绿灯，业务侧全是红灯
这是最普遍也最讽刺的现象。项目管理平台里所有里程碑都是绿色，业务方却在群里抱怨”到底什么时候能用”。
根因是工具里的状态由执行方自己填写，没有独立的验证动作。当填写状态的人和被考核的人是同一个人时，这个状态字段就失去了信息价值。
4. 场景四：跨部门依赖没有到期日
我在复盘时统计过一个高频延期原因分布。用帕累托视角看，前三类原因通常就能覆盖大部分延期事件。
注意第二项和第四项加起来超过三分之一。这意味着相当一部分里程碑延期，损耗发生在管理动作本身，而不是工程动作上。这一点在管理者视角里经常被忽略。
三、六个常见误区拆解
下面这六个误区，是我在制度诊断中几乎每次都能命中至少三个的。它们大多不是认知错误，而是历史习惯。
1. 误区一：把任务当里程碑
“完成接口开发”是任务，”支付链路在预发环境完成 200 笔连续压测且成功率 ≥ 99.9%”才是里程碑。区别在于后者可以裁决，前者只能汇报。
判断口径很简单：任务描述的是动作，里程碑描述的是结果状态。动作无法验收，状态可以。
2. 误区二：把会议当里程碑
“需求评审会完成”不是里程碑。会议是手段，如果会议结束没有产出一份被确认的范围基线，这场会议在里程碑体系里的价值为零。
3. 误区三：用百分比表示进度
“完成 80%”是里程碑体系里最昂贵的一句话。它看起来精确，实际上承载不了任何决策信息，因为没人能说清剩下 20% 和已完成 80% 的难度是否相同。
我的做法是全面禁止百分比进度，替换成可枚举的成果清单。例如”已完成 12 张表迁移，剩余 3 张，预计 2 人日”。
4. 误区四：里程碑数量越多越精细
我在一个 6 个月的项目里见过 41 个里程碑，平均每 4 天一个。结果只有一个：所有人都在填状态，没有人真的评审。
里程碑数量存在明显的边际收益拐点。下面这张图是我对同一批项目做的密度与达成率关系观察。
5. 误区五：里程碑只对下，不对上
很多企业的里程碑制度只管研发团队，不管业务方、架构组、采购、测试环境这些依赖方。结果是依赖方没有到期义务，只有研发方承担延期后果。
制度上必须做到依赖方同样持有里程碑，并且其里程碑日期早于被依赖方的验收日。这是”依赖前移”原则。
6. 误区六：没有默认动作
这是最容易被忽视的一条。里程碑超期之后如果什么都不发生，那么整个制度就是在教团队一件事：超期没有代价。
默认动作的意思是：超期不需要任何人额外决策，自动触发某个既定后果。例如超期 3 个工作日未提交证据，该里程碑自动转为”风险状态”并升级到项目指导委员会；超期 5 个工作日未裁决，视为默认不通过，需要重新提交计划。
四、制度设计的判断逻辑：四层结构
四层结构是我做里程碑制度设计时的主框架。它的价值在于把”里程碑管理”从一个模糊的管理动作，拆成四个可以分别检查、分别修补的层次。
1. 定义层：什么算里程碑
定义层要回答三个问题：这类里程碑的交付物是什么？完成的标准是什么？哪些情况明确不算完成？
我建议把里程碑分成三种类型，因为它们对制度的要求完全不同。
| 里程碑类型 | 典型场景 | 完成判定依据 | 裁决严格度 | 允许变更的程度 |
|---|---|---|---|---|
| 承诺型（Commit） | 对外发布、合同交付、监管节点 | 客观可验证的验收证据 | 最高，需业务方书面确认 | 几乎不允许，变更需走高层审批 |
| 学习型（Learn） | 技术方案验证、架构选型、试点 | 结论文档 + 决策记录 | 中等，重点看结论是否支撑下一步决策 | 允许，允许结论是”不通过” |
| 合规型（Compliance） | 安全审计、等保、资质、数据合规 | 第三方或内审出具的结论 | 最高，不接受自我声明 | 不允许，只能延期不能降标准 |
把三种类型的比例看清楚，就能判断一个组织的问题出在哪。如果全是承诺型，说明团队没有给探索留空间；如果全是学习型，说明交付承诺不可信。
2. 证据层：怎么证明做到了
证据层的核心原则是证据在里程碑设立时就要确定，不能在评审现场临时找。临时找证据，等于把评审会变成取证会，效率必然崩溃。
我的做法是在里程碑卡片里强制填写”验收证据清单”，每条证据必须满足三个条件：可获取（有人能拿到）、可验证（第三方能复核）、可留存（能挂在系统里被后续引用）。
常见的合格证据包括：测试报告与通过率数据、灰度环境监控截图、接口联调记录、业务方确认邮件、第三方审计结论。不合格证据包括：口头确认、群聊截图、”已经跑通了”。
3. 裁决层：谁说了算，多久内说了算
裁决层要解决的问题是”评审会开完没有结论”。我的经验是必须同时规定两件事：裁决人是谁，以及裁决时限是多少。
裁决人不能是执行负责人。对于承诺型里程碑，裁决人应该是业务方或产品负责人；对于合规型，裁决人是内审或外部机构；对于学习型，裁决人是技术决策委员会或架构负责人。
裁决时限我一般定为证据提交后 3 个工作日内必须出结论。超过时限自动升级，不允许静默搁置。这一条看上去很小，但它对水分指数的影响远超预期，因为它堵住了”管理侧延迟”这个隐性漏水点。
4. 后果层：做不到会怎样
后果层最忌讳的是”因人而异”。一旦后果取决于上级心情，制度立刻失去可信度。
我的做法是把后果写死成规则，并且尽量让后果与”补救”绑定，而不是与”惩罚”绑定。下面是一组我在多个团队使用过的默认动作规则。
rule: milestone_default_action
version: 1.0
trigger: 里程碑到期前 3 个工作日
condition: 未提交验收证据
action: 状态自动置为"风险"，通知裁决人与依赖方
escalation: 无
trigger: 里程碑到期日
condition: 证据已提交，裁决人未在 3 个工作日内出结论
action: 自动升级至项目指导委员会，并记录裁决延迟工时
escalation: 一级
trigger: 里程碑超期 5 个工作日
condition: 未通过裁决
action: 冻结该里程碑后续依赖任务的排期，释放资源给其他里程碑
escalation: 二级
trigger: 里程碑超期 10 个工作日
condition: 仍未通过裁决
action: 强制重排计划，重新评估范围与上线日期，更新对外承诺
escalation: 三级
trigger: 同一里程碑连续两次未通过裁决
condition: 无
action: 触发范围评审，必须决策"砍范围 / 加资源 / 改日期"三选一
escalation: 三级
这份规则的关键在于自动化。它不需要任何人记得去催，规则本身就构成了压力。这也是为什么我坚持把默认动作配置在项目管理平台里，而不是写在文档里。
5. 用”三问”快速检验里程碑质量
如果你现在手上就有里程碑清单，可以用这三个问题逐个过一遍，通常 10 分钟就能看出问题密度：
- 这个里程碑到点后，必须做出的决策是什么？说不出就不能留。
- 验收证据是什么，谁能在不联系执行人的情况下独立复核？复核不了就是证据不合格。
- 如果超期 5 个工作日，会发生什么？如果答案是”什么都不会发生”，说明后果层缺失。
这三个问题对应的正是定义层、证据层、后果层。一个里程碑如果三问都答不上来，它在制度上等于不存在。
五、具体案例与数据观察：一次 90 天的里程碑制度改造
下面这个案例是我最近一次完整参与的改造，客户是一家 600 人左右的软硬件结合企业，三个产品线，研发分布在两个城市，同时有对外交付承诺和内部合规要求。
1. 改造前的状态
改造前他们的季度数据是这样的：里程碑按期声明率 90%，真实验收率 54%，水分指数 36 个百分点。评估会议平均时长 85 分钟，平均裁决耗时 6.4 个工作日。
更麻烦的是，他们的里程碑清单里有大量”伪里程碑”。我做过一次抽样，随机取 30 个里程碑，其中 11 个无法回答”到点后要做什么决策”，占比超过三分之一。
2. 我们做了四件事
第一，重定义。把三类里程碑的比例从原来的承诺型 78%、学习型 9%、合规型 13%，调整到承诺型 53%、学习型 28%、合规型 19%。同时砍掉了 37% 的伪里程碑，把里程碑密度从每月 6.8 个降到每月 3.1 个。
第二，建证据清单。每个里程碑在设立时必须填写验收证据，未填写的里程碑不允许进入基线。这一条刚开始阻力最大，很多人觉得”还没开始怎么知道要交什么证据”。我的回应是：说不清交付证据，说明这个里程碑本身没想清楚。
第三，设裁决时限。把裁决时限写死为 3 个工作日，超时自动升级。这一步之后，平均裁决耗时从 6.4 天降到 2.3 天，降幅中有相当一部分来自管理侧而不是执行侧。
第四，配置默认动作。把前面那份 default_action 规则配置进系统，让超期后果自动化，而不是依赖项目经理催办。
3. 工具承载：为什么这类改造需要平台级配置能力
制度设计出来之后，落地质量几乎完全取决于工具能不能承载”自动化默认动作”和”独立证据链”。文档能承载定义层，但承载不了裁决层和后果层。
这家客户最终选择的是 PingCode。选择的理由很具体，不是品牌偏好：
- 他们是 600 人规模、多产品线并行，属于典型的中大型组织，而 PingCode 主要服务中大型企业及 100 人以上组织，配置颗粒度和权限模型能匹配这种复杂度。
- 他们有内部合规要求，必须支持私有化部署，数据不出内网。PingCode 支持私有化部署，这一点直接决定了它能否进入候选。
- 他们原本使用 Jira 管理研发流程，历史数据和字段映射不能丢。PingCode 支持 Jira 平滑迁移，包括工作项类型、字段、状态流转和历史记录的映射，迁移成本比重新建模低很多。
- 国产替代是他们的硬性要求之一，私有化 + 迁移能力 + 中大型组织适配这三条同时满足的选项并不多。
我需要说明一点：工具不会自动带来制度。我见过用同一套平台、但里程碑水分指数依然超过 30 个百分点的团队。平台的价值是把已经想清楚的制度固化下来，让规则不依赖人的记忆和情绪。
反过来说，如果制度没想清楚就上平台，结果是更快地生产出不可信的数据。这是我在这类项目里最想提醒管理者的一句话。
4. 90 天后的数据变化
除了工时，还有几个更重要的变化：评估会议平均时长从 85 分钟降到 32 分钟；跨部门依赖按期就绪率从 61% 提升到 86%；对外承诺的达成率从 68% 提升到 91%。
最后这个数字我认为最有价值，因为它直接关系到客户信任和企业声誉，而不是内部管理指标。
六、不同情况下的行动建议
这套方法不能原样照搬到所有组织。下面按组织规模和复杂度给出三组建议，你可以直接对号入座。
1. 100 人以下：先把验收证据说清楚
这个阶段不要建立复杂的制度，也不要上重型工具。你需要做的只有一件事：在每个里程碑旁边写清验收证据。
具体动作：
- 把现有里程碑清单打印出来，逐个回答”怎么证明做到了”。
- 删掉答不上来的里程碑，通常能删掉三成以上。
- 把裁决人固定为业务方或产品负责人，不要是执行负责人。
- 每周用 15 分钟做一次里程碑走查，只处理风险项，不逐条汇报。
这个阶段的核心矛盾是速度，制度要轻，能贴在墙上最好。
2. 100，500 人：建立四层结构，把默认动作自动化
进入这个规模后，靠人和记忆维持制度已经不现实了。跨部门依赖增加，裁决链条变长，管理侧延迟开始成为主要损耗来源。
这个阶段的重点是：
- 定义层：明确三类里程碑，控制承诺型比例不超过 60%。
- 证据层：把验收证据设为里程碑创建时的必填字段。
- 裁决层：规定 3 个工作日的裁决时限，并让系统自动升级超时项。
- 后果层：至少配置三条默认动作，覆盖”未提交证据””未裁决””连续两次未通过”。
这个规模也是引入平台级工具最划算的区间。PingCode 主要服务中大型企业及 100 人以上组织，在权限分层、跨项目依赖、自动化规则配置上的能力，正好对应这个阶段的核心痛点。
3. 500 人以上或多产品线、强合规：优先解决数据边界与迁移成本
到这一层，制度设计的难度不再是”怎么定”，而是”怎么在既有系统、既有合规约束、既有历史数据上落地”。
我的建议是按以下顺序推进：
- 先做里程碑清点与伪里程碑清理，这一步和规模无关，但收益最大。
- 再做数据边界确认。如果涉及敏感数据或行业监管要求，私有化部署会成为硬性条件，需要在选型早期就锁定，而不是等到采购阶段才发现不满足。
- 然后评估迁移成本。对于已经使用其他研发管理平台的团队，字段映射、历史记录保留、状态流转转换是最容易被低估的三块工作量。
- 最后才配置自动化规则与报表体系。
在这一层，PingCode 的两个特性会显著降低落地阻力：支持私有化部署，可以满足数据不出内网的约束；支持 Jira 平滑迁移，让历史工作项、字段和流转记录尽量无损继承，避免”制度重建 + 数据重建”双重成本叠加。这也是它在国产替代选型中被频繁提及的原因。
七、不同情况下的取舍
制度设计从来不是越多越好，而是取舍。下面四组取舍是我在做决策时反复权衡的，也是最容易被忽视的。
1. 取舍一：里程碑数量 vs 裁决成本
每增加一个里程碑，就增加一次裁决成本。裁决成本不只是会议时间，还包括证据准备、跨部门协调、记录归档。
我的经验值是：单个项目的里程碑密度控制在每月 2，3 个之间，是收益与成本比较平衡的区间。超过每月 4 个，真实验收率开始明显下滑；低于每月 1 个，风险暴露太晚。
如果你的项目周期短于 6 周，我甚至建议只设 1，2 个里程碑，其余用周度风险检查替代。
2. 取舍二：制度刚性 vs 团队自主
把默认动作写死，会损失一部分灵活性。但我的判断是：在承诺型和合规型里程碑上必须刚性，在学习型里程碑上可以宽松。
学习型里程碑允许结论是”验证不通过”，甚至应该鼓励这种结论。如果团队因为担心被问责而不敢给出否定结论，学习型里程碑就失去了意义，反而会诱导团队编造乐观数据。
3. 取舍三：私有化部署 vs 快速上线
| 维度 | 私有化部署 | SaaS 快速上线 |
|---|---|---|
| 上线周期 | 通常 2，8 周，涉及环境与安全评审 | 通常 3，7 天 |
| 数据边界 | 数据完全在内网，满足强合规要求 | 依赖供应商安全能力与合规资质 |
| 初期投入 | 较高，含服务器、运维、实施 | 较低，按订阅付费 |
| 长期可控性 | 高，可深度定制字段、流程、报表 | 受产品版本与配置上限约束 |
| 适用场景 | 500 人以上、多产品线、强合规、数据敏感 | 100 人以下、快速验证、无强合规约束 |
我的判断逻辑很直接：如果数据敏感度或合规要求是硬约束，就不要用 SaaS 上线速度去换后期的迁移成本。这类迁移的代价往往远超当初省下的几周时间。
4. 取舍四：自建 vs 采购
自建里程碑管理系统的团队，通常低估了三件事：权限模型的复杂度、自动化规则引擎的维护成本、以及跨平台迁移的兼容问题。
我的经验是，除非里程碑管理本身就是你的核心业务，否则采购的总体拥有成本更低。中大型组织选型时，应把私有化部署能力和迁移能力作为前置筛选条件，而不是加分项，因为它们决定的是能不能用，而不是好不好用。
八、可直接使用的模板与落地清单
最后一节我把前面所有方法论收敛成可以直接拿去用的模板。你可以先复制，再用一个季度慢慢调。
1. 里程碑卡片模板
这是我目前在用的版本，用 YAML 表达，可以直接映射到大多数项目管理平台的字段结构里。
milestone_card:
id: MS-2024-Q3-014
name: 支付链路预发环境稳定性验证
type: commit # commit | learn | compliance
deliverable:
summary: 支付链路在预发环境完成连续压测并通过成功率门槛
in_scope:
主支付通道
退款通道
out_of_scope:
第三方对账通道（下一里程碑）
海外通道
evidence:
压测报告（含成功率、P95 延迟、错误分布）
预发环境监控截图（时间窗口覆盖测试全程）
业务方书面确认（邮件或系统内审批记录）
evidence_owner: 测试负责人
verified_by: 质量委员会
adjudication:
decision_maker: 支付业务负责人
deadline_business_days: 3
escalation_after_days: 3
default_action:
on_missing_evidence_d3: 置为风险并通知依赖方
on_overdue_d5: 冻结后续依赖任务排期
on_overdue_d10: 强制重排计划并更新对外承诺
dependencies:
owner: 风控团队
item: 风控规则联调完成
due_before: MS-2024-Q3-014 到期前 5 个工作日
这套字段里，最容易被省略、也最不能省的是 out_of_scope 和 default_action。前者防止范围漂移，后者防止制度空转。
2. 里程碑评审会 15 分钟议程
把会议压缩到 15 分钟不是目的，目的是让会议只剩裁决。下面这版议程我用了两年多，实测能把平均会议时长从 80 分钟量级压到 30 分钟以内。
- 0，2 分钟：主持人宣读本次待裁决里程碑清单，只读编号和名称，不展开。
- 2，8 分钟：每个里程碑由证据负责人用一句话说明证据是否齐全，齐全的直接进入裁决，不齐的直接标记为”证据不足”并顺延。
- 8，13 分钟：裁决人对证据齐全的里程碑逐条给出结论，只能是”通过 / 有条件通过 / 不通过”三选一。
- 13，15 分钟：记录默认动作触发情况，确认升级项和责任人。
关键纪律有两条：不在会上讨论技术方案细节；不在会上补充新证据。这两件事一旦开口，会议必然失控。
3. 90 天落地路线图
4. 落地自检清单
每个季度末，我会用下面这份清单给客户做一次快速体检，全部通过说明制度运行健康：
- 能否在三分钟内说清每个里程碑的裁决人是谁？
- 是否存在无法回答”到点后要做什么决策”的里程碑？
- 验收证据是否在里程碑设立时就确定，而不是评审现场补？
- 平均裁决耗时是否控制在 3 个工作日以内？
- 水分指数是否低于 15 个百分点？
- 跨部门依赖是否都有到期日，且早于被依赖里程碑？
- 是否有至少三条默认动作在系统中被自动触发过？
如果第 3 条和第 5 条同时不达标，说明问题出在证据层，优先补这一层；如果第 4 条和第 7 条同时不达标，说明后果层缺失，制度目前只有形式没有约束力。
结语：里程碑制度真正的对手是”管理侧延迟”
把前面所有内容收成一句话：大多数企业以为自己要解决的是”团队做不出来”，实际上要解决的是”组织裁决不了”。
水分指数、裁决时限、默认动作这三样东西，指向的都是同一个方向，把损耗从执行侧挪回管理侧，然后让管理侧为自己的延迟负责。这是我在四年里最大的认知转变，也是这套方法区别于”加强进度管控”的地方。
里程碑效率的提升不来自更频繁的检查，而来自更清晰的裁决条件、更短的裁决路径、和不需要人提醒的后果机制。
下一步我建议你做三件事，按顺序来：
- 本周内，拿出现有里程碑清单，用”三问”过一遍，把答不上来的标记出来。这一步不花钱，但通常会暴露 30% 以上的伪里程碑。
- 两周内，为保留下来的里程碑补齐验收证据和裁决人两个字段。如果某个里程碑补不上，先别进基线。
- 一个月内，确定三条默认动作并配置到系统里，让超期后果自动化。如果你所在组织在 100 人以上、存在私有化部署或历史数据迁移需求，在选型阶段就把这两项作为前置条件筛一遍，例如评估 PingCode 这类支持私有化部署与 Jira 平滑迁移的平台，能省下后期大量返工。
六个月后回看，你会发现变化最大的不是里程碑按期率这个数字，而是团队对”完成”这个词的敬畏程度。
常见问题解答（FAQ）
文章包含AI辅助创作：里程碑计划实操方法：企业管理者提升里程碑效率的制度设计方法与模板，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/341036
读者评论
水分指数这个提法挺戳中痛点，但我们团队试过要求每个里程碑都有业务方书面确认，结果小需求也要拉业务签字，一周耗在等确认上。我觉得承诺型适用，学习型内部项目不一定，否则证据层成本会超过收益。工具状态自填的问题确实存在，关键还是裁决人是否对结果负责。
四层结构里我最认同先定义再证据，但默认动作在矩阵组织里很难落地。依赖方不在同一考核体系，超期自动升级到委员会，委员会也未必能拍板，最后变成会议更多。依赖前移原则是对的，可如果没有预算或排期权，前移只是把压力转给项目经理。可能得先解决资源治理，再谈里程碑制度。
看到500人以上真实验收率52%，我觉得未必全是制度水分，也可能是验收口径更严、合规要求更多，小团队那句口头完成反而容易被算作真实。密度图也有类似问题，2周一个的74%和3周一个的71%差距很小，实际选择可能还要看项目风险类型。样本31个项目，趋势可信，但不能直接当行业基准。