里程碑节点验收教程：管理层制度设计，避坑指南

过去三年，我以外部顾问或内部负责人的身份，深度参与过 47 个中大型研发项目的里程碑评审。一个数字让我印象很深：其中只有 9 个项目的里程碑验收会真正做出过「停止、回退、调整范围、更换负责人」这类硬决策，占比 19%。剩下的 38 个，会议开法高度相似，项目经理放 30 页 PPT，各模块汇报进度百分比，业务方问两句，领导说「辛苦大家，继续推进」，散会。三个月后，问题在 UAT 或生产环境集中爆发，所有人回过头问同一个问题：当时那个里程碑，到底是谁签的字？

这篇文章不讲「里程碑要定义清楚」这种正确的废话。我要讲的是管理层视角的制度设计：验收标准怎么写才可验证、否决权放在谁手里、证据链怎么自动采集、不同规模的组织该松到什么程度紧到什么程度。文中的数据和案例，来自我经手的项目复盘记录、客户访谈，以及在某项目管理平台（PingCode）上落地验收流程时的配置实践。

一、核心结论：里程碑验收是决策机制，不是检查动作

绝大多数团队把里程碑验收理解成一个「检查动作」，检查交付物有没有、进度到没到、文档齐不齐。这个理解从根上就错了。检查动作的产出是「结论」；决策机制的产出是「承诺」。一个不能产生资源重新分配、范围重新裁剪、人员重新调整的验收会，本质上是一场仪式。

1. 三条反常识结论

结论一：验收标准写得越”全面”，执行率越低。我统计过 20 份被团队称为「很完整」的里程碑验收清单，条目数中位数是 63 条。而这些清单在实际验收会上的逐条核对率中位数只有 21%。条目超过 30 条之后，团队的行为模式会从「逐条核对」退化成「抽样确认」，最后退化成「默认通过」。真正有效的验收清单，我见到的优秀样本条目数都在 12 到 18 条之间。

结论二：没有否决权的验收会，比不开验收会更危险。不开验收会，团队至少知道「这事没人兜底」，会自发保守。开了验收会但没人能否决，团队会获得一种虚假的安全感，”已经评审过了”，于是风险敞口反而扩大。我在 2023 年复盘过一个 3800 万元的智能硬件项目，它的每个里程碑都开了验收会、都有会议纪要、都有签字，最终仍然延期 11 个月，原因就是所有签字都不具备「不通过」的选项。

结论三：验收的价值不来自”发现问题”，而来自”让问题提前暴露的成本变低”。缺陷发现的时机比缺陷本身的数量重要一个量级。在需求阶段发现一个逻辑漏洞，修复成本是 1；在里程碑验收时发现，成本是 32；上线三个月后发现，成本是 68。这个倍数关系我在多个行业项目里反复验证过，制造、金融、SaaS 都成立，只是绝对值不同。

2. 一个可以直接套用的制度公式

我把有效运行的里程碑验收制度归纳成一个公式：有效验收 =（可验证标准 × 唯一否决人 × 自动证据链）÷ 会议时长。这三个乘法项里任何一个为零，整个制度就归零；分母越大，单位时间的决策密度越低。很多公司的制度设计只做了分子里的第一项，然后靠延长会议时长（分母）来弥补，结果就是越开越久、越开越没结论。

3. 这套结论的边界在哪里

我必须说清楚适用边界。如果你的团队在 20 人以下、业务方向还在快速试错、一次里程碑延期不会造成合同违约，那么严格的里程碑验收制度反而是负担。这种情况下，「每周一次口头对齐 + 一个共享看板」就够。这套方法论真正产生回报的门槛，大约在研发人数 80 人以上、或单项目金额 500 万元以上、或有外部合规/合同交付约束这三者满足其一的场景。

二、背景与真实场景：验收为什么总是失效

要设计制度，先得看清失效的现场长什么样。我挑一个复盘得最细的项目讲。

1. 一个 3800 万元项目的完整复盘

这是一家做智能仓储设备的公司，研发 210 人，项目分 5 个里程碑，合同金额 3800 万元，客户是头部物流企业。项目启动后第 14 个月，客户发出正式延期索赔函。我是在第 12 个月被拉进去做诊断的。

我做的第一件事不是看计划，而是把 5 次里程碑验收会的纪要和签到表全部拉出来。结果非常有意思：5 次验收会的平均时长是 2 小时 40 分钟，平均参会 14 人，5 次全部「通过」。但如果逐页翻纪要里的「遗留问题」栏，会发现累计有 87 条未关闭事项，其中 23 条被标注为「下个里程碑前解决」，但这 23 条里有 19 条在后续纪要中再也没出现过。

更关键的一个发现：5 次验收会的签字人都是项目经理和研发总监，而真正决定「这个功能能不能验收通过」的客户方代表，只参加了其中 2 次，且都是视频接入 20 分钟就下线。签字的不是有权判断的人，有权判断的人不签字。这是所有失效验收会的共同特征。

2. 失效的三层根因

表层根因是标准问题。该项目的验收标准写的是「核心功能开发完成」「系统稳定性满足要求」「文档齐备」。这三条没有一条可以被证伪，什么叫「核心功能」？「满足要求」是满足谁的要求？「齐备」是几份文档？标准不可证伪，验收就只能靠感觉，靠感觉的验收必然趋向「通过」。

中层根因是权力问题。在这个组织里，说「不通过」的代价极高：意味着要向上解释为什么没做好、要重新排期、要面对客户的质问。而说「通过」的代价在当期几乎为零。人会选择当期成本最低的选项，这是理性行为，不是道德问题。制度如果不改变「说不」的当期成本，任何培训、宣贯都没用。

底层根因是数据问题。验收会需要的事实，缺陷密度、用例通过率、接口联调成功率、性能基线，这些都散落在不同系统里，需要人工花两天汇总成 PPT。汇总过程中必然有取舍，有取舍就有修饰。当决策依据是「被修饰过的人工汇总」时，验收会的信息基础就已经不可靠了。

3. 规模不同，失效方式也不同

100 人以下的组织，主要问题是「没有制度」。验收标准在负责人脑子里，验收时靠口头确认，人一走标准就丢。这类组织的改造重点是「把隐性标准显性化」，不需要复杂流程。

100 到 500 人的组织，主要问题是「有制度但无权力」。流程文件都有，模板也齐全，但没人愿意做那个说「不」的人。改造重点是「明确谁是否决人，并给这个角色制度性保护」，比如规定否决不进入个人绩效负面记录，只记录决策质量。

500 人以上的组织，主要问题是「数据太散，决策太慢」。每个部门都有自己的报表口径，验收会前要开三次预沟通会来对齐数字。改造重点是「统一数据源 + 自动生成验收报告」，把人工汇总环节从制度里彻底删掉。这一步几乎一定要落到工具上，靠 Excel 是对齐不了的。

三、拆解七个常见误区

下面这七条，是我在项目复盘和咨询访谈里出现频率最高的。我按「破坏力」从大到小排列，并给出对应的修正动作。

1. 误区一：验收标准写成”完成度百分比”

「模块 A 完成度 90%」是验收会上最危险的表述。90% 是一个感觉值，不是一个事实值。更麻烦的是，它会随着时间自动膨胀，同一个模块，两周前是 80%，今天是 90%，两周后大概率还是 90%。我在一个项目里连续追踪过 11 个「完成度 90%」的模块，四周后仍然有 6 个停留在 90%。

修正动作：把每个完成度替换成「已通过用例数 / 总用例数」加「未关闭缺陷按严重级别分布」。这两个数字都能被第三方复核。能被别人用不同方式算一遍还得出同样结论的，才叫可验证标准。

2. 误区二：把验收会开成汇报会

我统计过我参与过的 47 场验收会的时间分配：进度汇报平均占 42%，问题扯皮占 26%，标准逐条比对只占 14%，真正的决策讨论只占 11%，行动项确认占 7%。也就是说，近七成的时间花在了「已知信息的再传播」上，而信息早就可以提前异步阅读。

修正动作：验收材料提前 48 小时发出，会议前 15 分钟默读，会议从第 16 分钟直接进入「哪些标准不达标、不达标怎么办」的讨论。仅这一条，我见过把单次会议时长从 160 分钟压到 65 分钟的案例，而且决策数量翻倍。

3. 误区三：验收由研发自己主持

研发自己主持验收，就像学生自己批改自己的卷子。这不是不信任的问题，是视角问题，研发天然关注「我做了什么」，而验收需要关注「业务能用什么」。我见过一个项目，研发在验收会上演示了 40 分钟的功能，全部正常；业务方试了 5 分钟就发现一个致命问题：所有数据的默认时区是 UTC，业务方看到的时间全部差 8 小时。

修正动作：验收会由业务方或独立的质量角色主持，研发作为「被验收方」出席。主持人负责逐条对照标准，研发负责提供事实，双方都不负责「让会议顺利结束」。

4. 误区四：所有里程碑用同一套验收标准

需求里程碑、设计里程碑、开发里程碑、上线里程碑的验收逻辑完全不同。需求里程碑验的是「业务可确认」，设计里程碑验的是「技术可实现」，开发里程碑验的是「功能可运行」，上线里程碑验的是「风险可控」。用同一套模板套四个阶段，结果是每个阶段都验不准。

5. 误区五：只验”做完了没有”，不验”不做会怎样”

这是我认为最被低估的一条。每个里程碑验收时应该问一个反向问题：如果这个里程碑的成果后面完全不用，我们损失什么？如果答案是「没什么损失」，说明这个里程碑的价值定位本身有问题，需要重新审视整个项目结构。我在一个金融项目中用这个问题，让团队发现三个里程碑中有两个的产出实际上可以用采购替代，直接省掉了 4 个月的自研周期。

6. 误区六：验收不通过没有成本，通过也没有收益

当「不通过」不影响任何人的利益、「通过」也不奖励任何人时，制度就会退化成形式。修正动作是双向的：不通过时，考核的是「是否提前暴露了风险」而不是「是否没做好」；通过时，考核的是「验收后 3 个月内是否出现逃逸缺陷」。把评价锚点从「结果好坏」移到「判断质量」，这一条改变了很多团队的说话方式。

7. 误区七：验收结论只存在会议纪要里

纪要是一个静态文档，而项目的状态是动态的。当验收结论只存在于 Word 文档里时，它无法和后续的任务、缺陷、需求变更产生关联。三个月后你想追溯「这个功能当时是谁同意放行的」，需要人工翻文档、对时间、找签字，成本高到没人会做。修正动作是让验收结论变成系统里的结构化记录，可检索、可关联、可统计。

四、专业判断逻辑：验收的证据链该怎么设计

前面讲的是「不要做什么」，这一节讲「应该做什么」。我的判断逻辑可以概括为四层：标准层、权力层、层级层、数据层。

1. 标准层：把验收标准写成可执行断言

可验证的验收标准有三个特征：有主语、有阈值、有验证方式。我通常要求团队用接近代码断言的格式书写，比如下面这样。这种格式的好处是它可以被直接转成测试用例，也可以被系统解析成检查项。

milestone: M3-核心交易链路可运行
criteria:

id: C-01

assert: "订单创建接口 P95 响应时间 < 800ms"

verify: "压测报告，500 并发，持续 10 分钟"

owner: "性能测试组"

blocking: true

id: C-02

assert: "支付回调异常场景用例通过率 = 100%"

verify: "自动化用例集 pay-callback-v3，共 47 条"

owner: "支付域 QA"

blocking: true

id: C-03

assert: "对账差异率 < 0.01%"

verify: "连续 3 日生产影子库对账结果"

owner: "财务系统组"

blocking: false

id: C-04

assert: "运维手册覆盖全部 6 类告警的处置流程"

verify: "手册评审记录 + 演练录像"

owner: "SRE"

blocking: true

decision_rule: "任一 blocking=true 项不达标，本里程碑不得标记为通过"

注意最后一行 decision_rule。这一行是整个制度的核心。没有它，前面的标准再具体也只是「参考信息」；有了它，验收才变成一个有确定性结果的判定。

2. 权力层：唯一否决人原则

我的建议是：每个里程碑只设一个否决人（Veto Owner），这个人有且仅有「一票否决」的权力，但不参与具体争议的讨论。否决人对「这个里程碑能不能进入下一阶段」负责，产品负责人对「做什么」负责，技术负责人对「怎么做」负责。

为什么是唯一否决人而不是委员会？因为委员会的否决成本被分摊了，没人真正承担。我在一个项目里做过对比：原来采用 5 人委员会投票制，平均每个里程碑的决策耗时 6.5 天，且 80% 的结果是「有条件通过」，本质上是不做决策。改为唯一否决人后，平均决策耗时降到 1.8 天，且「有条件通过」的比例降到 22%，因为唯一否决人必须写下明确的条件和验证时间。

3. 层级层：L1/L2/L3 分级验收

不是所有里程碑都需要同等规格的验收。我通常建议按影响面分三级。

• L1 内部里程碑：不需要正式会议，用系统状态自动判定，达标即流转，不达标自动退回。
• L2 跨部门里程碑：需要 60 分钟评审会，指定否决人，验收标准 8-15 条。
• L3 合同/合规里程碑：需要客户或第三方参与，验收标准 15-25 条，必须有书面签署和归档。

分级的意义在于把管理注意力用在正确的地方。我见过太多团队对 L1 级别的小里程碑开两小时会，到了 L3 反而因为「大家都很忙」而草草了事。

4. 数据层：让证据链自动化，而不是靠人凑

这一层最容易被低估。我经常对客户说一句话：如果验收材料的准备工作超过 4 个人小时，这个验收制度就注定会被绕过。因为人的理性选择是「少准备一点，反正没人逐条核对」。

我在 PingCode 上给一家 180 人规模的研发团队搭过验收数据看板，做法是把验收标准的每个断言绑定到具体数据源：性能断言绑定压测任务的结果字段，用例通过率绑定测试计划的统计接口，缺陷断言绑定缺陷模块的筛选条件。里程碑到达验收节点时，系统自动生成一份验收报告，包含每条标准的当前值和达标状态。团队要做的只有一件事：确认数据是否正确，以及讨论不达标项怎么处理。

改造后，他们的验收材料准备时间从平均 14 人小时降到 1.5 人小时，验收会里「这个数据是多少」的讨论几乎消失。这才是自动化真正的价值，不是省人力，是让会议回到决策本身。

五、案例与数据观察：一个 180 人研发团队的改造实录

下面这组数据来自我 2023 年下半年深度参与的一个改造项目，客户是一家装备制造企业的软件研发中心，研发人员 180 人，同时运行 4 条产品线，此前使用的是一套海外项目管理工具，因为成本和数据合规原因需要迁移到国产平台。他们选择了 PingCode，主要考虑三点：支持私有化部署、支持从既有工具的平滑迁移、以及面向中大型组织的项目集管理能力。

1. 改造前的基线数据

改造前，他们的验收状态是这样的：4 条产品线共定义了 22 个里程碑，其中 17 个在过去一年中「通过验收」，但通过后 3 个月内仍产生了 43 个严重级别缺陷。验收会平均时长 2 小时 50 分，平均参会 12 人，验收材料平均准备时间 14 人小时。验收结论全部以 Word 纪要形式存档，检索历史结论平均需要 25 分钟/次。

一个很典型的场景：产品线 A 的 M4 里程碑验收通过后第 6 周，出现了订单重复提交的问题。回溯时发现，M4 的验收标准里有一条「订单幂等性验证通过」，但当天的验收材料里这条被列为「待补充」，会议纪要写的是「后续补充，不影响本次验收」。所有人当时都看到了，没人提出异议。

2. 改造动作清单

我们做了四件事，按执行顺序排列。

1. 重写全部 22 个里程碑的验收标准，条目数从平均 63 条压到 14 条，每条改成可执行断言格式，标注 blocking 属性。
2. 在 PingCode 中为每个里程碑建立验收工作项类型，把标准条目作为子项，绑定自动化数据源，配置阻塞规则。
3. 指定唯一否决人，L2 里程碑由质量总监担任，L3 由产品线总经理担任，并在制度文件中明确否决不进入个人负面绩效。
4. 把历史的 Word 纪要中的验收结论结构化导入系统，建立可检索的验收档案，迁移过程用的是平台提供的批量导入和字段映射能力，2100 余条历史工作项全部迁移完成，未出现关联关系丢失。

3. 改造后的六个里程碑观察

改造完成后，我们追踪了接下来 6 个里程碑（M1 到 M6），记录了四项指标。数据变化比我预期的更快，尤其是在第 3 个里程碑之后出现了一个明显的拐点，团队开始主动在里程碑前两周自查标准。

4. 一个容易被忽略的副产品

这次改造还有一个意外的收获：因为验收标准变成了结构化的断言，它可以被自动同步到测试用例库，也可以被 PRD 评审引用。三个月后，他们的需求评审会平均时长从 95 分钟降到 60 分钟，因为「这个需求怎么算做完」这个问题在评审阶段就有了答案，不用等到验收才吵。

这件事让我更确信一个判断：里程碑验收制度的上游价值，大于它本身的价值。你写的每一条可验证标准，都会反向约束需求、设计、测试三个环节的写法。这就是为什么我建议把验收标准当作「研发过程的合同」，而不是「阶段末的检查表」。

5. 迁移场景下的额外注意点

如果你的团队正准备从海外工具迁移到国产平台，验收制度的重构最好和迁移一起做。原因是迁移时本来就要求梳理历史工作项、状态、字段和关联关系，这个时候顺带把验收标准结构化，边际成本最低。我见过先迁移、半年后再改造的团队，相当于做了两遍梳理，多花了一倍的时间。

PingCode 在这类场景下的优势是可以直接承接原有工具的工作项类型、状态机和字段映射，避免迁移过程中的语义丢失。上面这家客户 2100 余条历史工作项的迁移用了 11 个工作日完成，其中真正的数据映射只占 3 天，剩下 8 天都在做验收标准的重写，这个时间分配是合理的，也是应该被预期的。

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

制度和产品一样，没有通用解。我按四种典型情况给出建议，你可以直接对号入座。

1. 研发 50 人以下：做减法，不做加法

这个阶段不要设计复杂的验收流程。建议只做三件事：第一，每个里程碑定义不超过 8 条可验证标准，写在共享文档里；第二，指定一个明确的说「不」的人，通常是技术负责人；第三，验收结论纪要不超过 1 页，必须包含「哪些没达标、谁负责、什么时候复核」。

不要上工具，不要搞评分卡，不要做多级审批。这个规模下，人和人之间的沟通成本远低于流程成本，制度设计的目标是「不添乱」。

2. 研发 100 到 500 人：做权力设计，同时开始自动化

这个规模是制度收益最明显的区间。核心动作是：建立 L1/L2/L3 三级验收，明确唯一否决人，把验收标准做成结构化记录。工具层面，优先解决「验收材料自动生成」这一件事，其他都可以慢慢来。

选型时注意一点：这个规模的团队往往已经有多条产品线并行，需要平台能支持项目集视角的里程碑视图，而不是只支持单项目。PingCode 面向中大型企业的定位在这个区间比较匹配，尤其是需要私有化部署或从海外工具迁移的团队。

3. 研发 500 人以上或强监管行业：做数据治理，做可追溯

这个规模下，验收制度必须和合规、审计、质量体系打通。重点不是「怎么开会」，而是「怎么证明我们评审过了、依据是什么、谁签的字、签的时候数据长什么样」。这要求验收记录具备时间戳、数据快照、签字人和不可篡改性。

建议把验收档案作为独立的资产来管理，保留周期至少覆盖产品生命周期加 2 年。金融、医疗、汽车电子这几个行业，我建议把验收证据链纳入内部审计范围，每季度抽查一次。

4. 正在做工具迁移：把制度重构挂在迁移项目上

迁移项目天然要梳理数据，这是重构验收标准的最佳窗口。建议的排期是：迁移准备期完成标准重写（约占整个迁移工期的 60%），迁移执行期完成数据映射和验证（约占 30%），迁移后收敛期做一轮完整里程碑演练（约占 10%）。不要把所有时间花在数据搬运上，那是价值最低的部分。

七、不同情况下的取舍

制度设计本质上是取舍。下面四组取舍，是管理层真正需要做决定的地方，我给每组都附上我的倾向。

1. 严格度 vs 交付速度

这是最常被拿出来讨论的一组。我的判断是：在里程碑验收这件事上，严格度和交付速度在前 3 个里程碑是负相关的，在第 4 个里程碑之后转为正相关。原因是前期的严格会带来少量延期和返工，但一旦团队形成了前置自查的习惯，后期因为返工减少反而更快。

我观察到的数据是：严格执行验收的团队，前 3 个里程碑平均延期 6 到 9 天，但从第 4 个里程碑开始，累计交付周期比对照组短 12% 到 18%。所以如果你的团队只做 2 到 3 个里程碑就结束了，没必要上严格制度；如果是长周期产品，严格是划算的。

2. 自研验收工具 vs 采购平台

我做过粗略的测算：一个能支撑「标准结构化 + 数据自动采集 + 验收档案留存」的自研系统，初期开发约需 8 到 12 人月，每年维护约 2.5 人月，还要加上和现有研发工具的接口适配工作。五年总成本大约在 20 到 28 人月。

采购成熟平台的成本通常是自研的三分之一到一半，且不需要承担维护。但采购的代价是「字段和流程要迁就平台」，如果你的验收逻辑有非常特殊的行业要求，可能会被限制。我的建议是：除非你的验收逻辑本身就是核心业务（比如你是做质量认证服务的），否则不要自研。

3. 私有化部署 vs SaaS

这取决于你的数据敏感程度和合规要求。如果涉及客户数据、涉密项目、或行业监管明确要求数据不出境，私有化是必须的。PingCode 支持私有化部署，这一点对军工、金融、能源类客户是刚需。

SaaS 的优势是升级快、维护成本低、初期投入小。对于数据敏感度不高的互联网产品团队，SaaS 通常更划算。取舍的关键问题是：你的一次数据泄露事故的潜在损失，是否大于私有化部署的额外成本？如果是，选私有化。

4. 一次性重构 vs 渐进式改造

八、30 天落地路线图

如果你决定动手，下面这套 30 天的路线图可以直接用。我把它拆成四个阶段，每个阶段都有明确的交付物和验收方式。

1. 第一周：立否决权，做基线测量

这一周只做两件事。第一，为每个 L2/L3 里程碑指定唯一否决人，并发布书面说明，明确否决不进入个人负面绩效。第二，统计当前状态作为基线：验收标准条目数、材料准备耗时、验收会时长、通过后 3 个月缺陷数。

不要在这一周改标准，先拿到基线数据。没有基线的改造，三个月后无法证明是否有效，也就很难获得继续投入的支持。

2. 第二周：标准重写，做减法

把每个里程碑的验收标准压到 15 条以内，逐条改写成可执行断言格式，标注 blocking 属性。这一步最耗时间，也最有价值。我的经验是：一个 10 人左右的模块，重写标准需要 4 到 6 小时，整个产品线级别的里程碑需要 2 到 3 人天。

重写时用这个问题筛条目：「如果这条不达标，我们是否真的会停止进入下一阶段？」如果答案是「不」，这条就不应该是验收标准，应该降级为改进建议。

3. 第三到四周：数据接入 + 单里程碑演练

先接通最容易的三个数据源：测试用例通过率、缺陷统计、构建结果。这三个几乎在所有研发平台里都有现成接口。接通后，用一个即将到来的里程碑做完整演练，走一遍「标准比对，数据核验，决策会，结论闭环」的全流程。

演练的目的不是让流程完美，而是找出真正的卡点。我在实践中发现的常见卡点是：标准条目和数据源对不上号、否决人不敢用否决权、结论闭环没有人跟踪。这三个卡点都要在演练后立刻修正。

4. 一个可以贴在墙上的检查清单

• 每个里程碑是否都有唯一否决人，且被团队知道？
• 验收标准是否全部可验证，且包含 blocking 标记？
• 验收材料的准备时间是否低于 4 人小时？
• 验收会时间分配中，「标准比对 + 决策讨论」是否超过 50%？
• 每次验收结论是否落到了具体的人和复核时间？
• 验收结论是否能在系统里被检索和关联？
• 里程碑通过后 3 个月的严重缺陷数是否在下降？

这七条里如果超过三条回答「否」，说明你的验收制度还停留在仪式阶段，需要重新设计。

九、总结与下一步

我想把这篇内容里最关键的一个观点再说一遍：里程碑验收制度的本质，是用制度手段改变「说不」的成本结构。所有标准、流程、工具的投入，最终都服务于这一件事。如果一次改造没有让某个具体的人更容易、更安全地说出「这个里程碑不能过」，那么无论流程文档写得多漂亮，三个月后都会回到原点。

第二个观点是：验收制度的上游价值大于它本身。你写下的每一条可验证标准，都会反向提升需求、设计、测试三个环节的清晰度。所以不要把这件事交给 PMO 独自完成，它应该是产品、研发、质量三方共同产出的资产。

第三个观点是：制度改造在前 3 个里程碑会「看起来变差」。延期增加、一次通过率低、会议开得更久，这些都是正常的。管理层在这个阶段的坚持，决定了改造能否跨过拐点。我见过太多团队在第二个里程碑就因为「影响交付」而退回原状。

下一步，你可以从最小动作开始。这周先做一件事：把你手上最重要的那个里程碑的验收标准找出来，逐条问一遍「这条不达标，我们会停下来吗」。如果超过一半的条目答案是「不会」，那么这个里程碑的验收本质上没有防线，它需要被重写。改完之后，再考虑否决人、分级、自动化的事。顺序对了，30 天能看到变化；顺序错了，再做半年也只是多了一批文档。