节点验收最佳实践：项目经理里程碑制度设计，常见问题

去年我参与复盘一个137人的跨部门项目群，看到一组让我沉默的数字：整体延期41天，12个里程碑里有11个标着“已完成”，但上线后三个月内产生的缺陷与返工工时，占整个项目总工时的23%。那些绿色的里程碑几乎没有拦截任何风险，它们只是把进度表涂绿了。更麻烦的是，复盘时没人能说清第7个里程碑“通过”的依据是什么，验收材料是一份27页的PPT，评审会开了40分钟，没人提反对意见，主持人问了一句“大家还有问题吗”，然后就散会了。

这件事让我重新审视“节点验收”这四个字。大多数团队的问题不是没有里程碑，而是里程碑没有决策权。里程碑被当成了进度汇报的仪式，而不是一个真实存在的“继续/停止/调整”的岔路口。当所有里程碑的通过率都是100%时，这个制度就已经死了。

下面我把这几年在十几个项目群、从几十人到上千人规模的组织里观察到的做法、踩过的坑、以及可复制的制度设计逻辑完整写出来。如果你正在被“里程碑全是绿灯、项目却不断延期”困扰，这篇内容里的每一节都能直接拿去对照你的现状。

一、核心结论：里程碑验收的本质是风险定价，不是进度打卡

我先给出三个结论。它们是我在复盘了几十个失败里程碑之后，认为最不该被绕过的判断。

1. 里程碑唯一的合法用途，是在信息最便宜的时点做出继续或停止的决策

项目越往后，纠错成本越高。需求阶段发现一个理解偏差，可能只需要改三行文档；上线后发现同样的问题，可能是两周的返工加一次客户信任损失。里程碑存在的意义，是强制把决策点前移到信息还便宜的时候。

如果一个里程碑开完会之后，团队的行为、计划、资源、优先级没有任何变化，那这个会就不该开。它不产生决策，只产生了会议纪要。

2. 验收标准必须能被第三方在30分钟内判定通过与否

我见过太多“完成开发”“功能可用”“基本满足需求”这样的验收标准。这些词的共同特点是：它们无法被证伪，因此无法被拒绝。无法被拒绝的标准等于没有标准。

一个可用的经验法则是：把验收标准交给一个没参与这个项目的同事，他应该能在30分钟内给出“通过”或“不通过”的明确判断，并且不需要追问任何澄清问题。如果需要追问，说明标准还停留在口号层面。

3. 里程碑制度的核心是预设拒绝条件，而不是预设检查项

这是最反直觉的一条。大部分团队的验收清单写的是“应该有什么”，而高成熟度团队写的是“出现什么就必须拒绝”。前者考核的是产出物齐不齐，后者考核的是风险有没有被暴露。

两者的差别在实际执行中非常明显：写检查项的团队，验收会变成材料清点会；写拒绝条件的团队，验收会变成风险讨论会。

4. 里程碑、阶段门、交付点、迭代回顾不是一回事

这四个概念经常被混用，混用之后制度就会失效。我整理了一张对照表，你可以拿去核对你们组织里说的“里程碑”到底属于哪一类。

5. 什么情况下不该设里程碑

不是所有项目都值得上重制度。如果项目周期短于6周、团队少于8人、需求变化极快且试错成本可控，强行设里程碑只会制造形式主义。这类项目更适合用短周期迭代加持续演示来控制风险。

另一个不该设的场景是探索型预研。预研的目标是降低不确定性，而不是交付确定的产出。这时候用“必须交付什么”来验收，会把团队逼向编故事。预研更适合用“学到了什么、下一个假设是什么”来做阶段性判断。

二、背景与真实场景：里程碑制度是怎么一步步失效的

制度失效从来不是一天发生的。它是一连串小的妥协累积出来的，而且每一步看起来都很合理。

1. 一个137人项目群的完整失效路径

这个项目群包含四条产品线、三个外部供应商、一个集团级合规团队。项目启动时定了12个里程碑，看起来很规范。第一次评审，项目组准备了200多页材料，会议开了三个小时，识别出11个风险。第二次评审，材料降到80页，会议开了一个半小时，识别出3个风险。到第五次评审，材料变成一份汇报PPT，会议40分钟，零风险。

不是风险消失了，是暴露风险的通道被逐渐关闭了。因为每次在会上提出严重问题，项目组就要加班补救，而补救的成本没人愿意承担。于是所有人的最优策略变成：把问题留在自己手里，等到藏不住的时候再说。

2. 里程碑验收失效的四个早期信号

这四个信号我在至少七个项目里都见过，它们出现的时间通常比“项目出问题”早两到三个月。

• 信号一：里程碑会议时长持续缩短。从三小时到一小时到40分钟，这不是效率提升，是没人愿意在会上说话了。
• 信号二：验收材料从数据变成叙事。早期材料是缺陷趋势、覆盖率、接口联调成功率，后期变成“项目整体进展顺利”这类表述。
• 信号三：连续三个里程碑没有任何一个被拒绝。100%通过率在复杂项目里不是好消息，是警报。
• 信号四：里程碑日期被平移但原因不可追溯。日期改了，但没人记录改的原因、影响和补偿措施。

3. 为什么百人以上组织的问题结构不一样

30人以下团队，问题基本是沟通问题，面对面说一句就能解决。但组织规模一旦超过100人，会出现三个结构性变化。

第一是信息在层级间衰减。一个在团队层面明确的风险，传递到项目群层面通常只剩下60%的信息量，再传到管理层可能只剩下一个模糊的感受。

第二是责任在多角色间分散。跨部门项目里，接口交付、环境准备、数据授权往往不属于任何一个团队的全责范围，于是成为系统性盲区。

第三是外部依赖引入不可控变量。供应商、合规审查、第三方系统对接，这些节点的验收标准往往不由项目组单方面决定。

这三点决定了：百人以上组织的里程碑制度，不能只解决“我们做得怎么样”，还必须解决“我们依赖的东西准备好了没有”。这是一个组织级问题，不是团队级问题。也正因为如此，我在第五部分会专门用一家中大型企业的落地案例来说明工具和制度怎么配合。

三、常见误区拆解：我在评审现场最常看到的七种做法

下面七个误区按我遇到的频率排序。前三个几乎是通用病，后四个更多出现在有外部交付压力的项目里。

1. 把里程碑当进度打卡点

典型表现是：里程碑清单是项目经理一个人排出来的，排完之后发给团队，团队照着填状态。这种里程碑只反映计划，不反映风险。它的隐含假设是“按计划做完就等于做好了”，而实际项目里最危险的问题恰恰是“按计划做完但做错了方向”。

判断方法很简单：问团队成员“这个里程碑如果不通过，会发生什么”。如果答案是“不知道”或者“应该不会不通过”，那它就是打卡点。

2. 验收标准写成“完成开发”“功能可用”

这类标准的致命问题在于它没有量化边界。什么叫“可用”？主流程能跑通叫可用，还是并发2000不崩叫可用？两种理解可能相差两个月工期。

更隐蔽的是“完成开发”。开发完成不等于自测通过，不等于接口联通，不等于文档同步。我见过一个项目，开发说“功能都做完了”，结果集成时发现三个模块用了三套不同的日期格式。

3. 只在里程碑当天开一次会

验收不是会议，是一个过程。把全部判断压在一次会上，会导致两个后果：一是会上只能看结论看不了过程，二是发现问题时已经没有补救窗口。

成熟做法是在里程碑前7到10天启动预验收，把证据链提前摆在桌面上，让问题在正式决策前就暴露。正式会议只做三件事：确认证据、做出决策、记录调整。

4. 没有拒绝权的里程碑

如果评审组的实际行为是“无论什么情况最后都会通过”，那这个评审组就是橡皮图章。我在一个项目里做过统计：连续9个里程碑，评审结论全部是“有条件通过”，而条件从未被跟踪关闭。这等于全部无条件通过。

拒绝权必须配合两样东西才有效：明确的拒绝条件和明确的升级路径。没有升级路径的拒绝权，只会变成互相指责。

5. 里程碑颗粒度均匀化

很多项目把里程碑按时间均匀切分，每两周或每月一个。这是排期思维，不是风险思维。里程碑应该按风险密度分布，而不是按日历分布。

高风险阶段（架构定型、接口冻结、数据迁移、首次上线）应该密一些；低风险阶段可以疏一些。一个项目里里程碑间隔从2周到12周不等，是完全正常的。

6. 用工具的审批表单代替制度判断

我见过一些团队，流程走得很规范，工具里每个节点都有审批流、都有电子签、都有附件要求。但打开附件一看，全是截图和PPT。这就是典型的形式合规、实质空洞。

工具能解决的是“有没有做”，解决不了“做得对不对”。制度层面必须先定义清楚什么算证据，工具才可能承载它。

7. 只验收功能，不验收非功能与运维准备

这是我见过代价最高的一类误区。功能全部实现，接口全部联调通过，但监控没接、告警没配、回滚方案没写、值班人没安排。上线后第一次故障，团队花了6个小时定位，因为没有日志。

非功能验收项应该包含：性能基线、可观测性、回滚与降级方案、容量与扩容预案、权限与安全审计、运维交接文档。这些项在里程碑验收清单里应该占据不低于30%的权重。

四、专业判断逻辑：里程碑制度的五层设计

前面讲的是不该做什么。这一节讲该怎么做。我把它拆成五层，从上到下依次是分类、标准、证据、权力、挂钩。缺少任何一层，制度都会在某次压力下崩掉。

1. 第一层：里程碑分类分层

不是所有里程碑都值得同样的评审规格。我的做法是把里程碑分成四类，每类的评审级别、参与人、材料深度都不同。

分类的好处是资源分配清晰。合规门必须提前四周准备，价值门可能只需要一份用户行为数据和一个访谈记录。如果所有里程碑都按同一规格做，团队很快会疲劳。

2. 第二层：验收标准可测量化

我把验收标准拆成三部分：进入条件、通过条件、拒绝条件。三者缺一不可，其中拒绝条件最容易被忽略，也最重要。

milestone: M3-核心接口联调完成
owner: 后端负责人 + 集成测试负责人

entry_criteria:

接口文档已冻结并发布不少于 5 个工作日

测试环境可用率连续 3 日不低于 99%

双方联调账号与数据准备完成

acceptance_criteria:

核心链路 12 个接口全部联调通过，成功率 100%

平均响应时间 P95 不超过 300ms

异常场景覆盖不少于 18 个用例

接口契约测试在流水线中自动执行并通过

evidence:

自动化测试报告（可追溯到流水线构建号）

联调日志与问题清单（含关闭状态与责任人）

压测报告（含并发梯度与瓶颈说明）

reject_conditions:

存在未关闭的 P0 或 P1 缺陷

关键接口成功率低于 99.5%

缺少压测报告或压测场景未覆盖峰值业务量

接口文档与实际实现不一致且未同步更新

decision: 通过 / 带条件通过 / 不通过

escalation: 不通过时 3 个工作日内提交整改计划，超过 5 个工作日升级至项目发起人

这份模板的关键不在格式，而在于每一个通过条件都对应一个可以自动或半自动获取的证据。如果一个条件找不到证据来源，说明它就不该写进清单。

3. 第三层：证据链设计

证据链的原则是：能自动生成的不要人工整理，能追溯到源头的不要截图。

我要求团队在里程碑验收时至少提供四类证据：一是系统里可追溯的执行记录（构建、测试、部署、变更记录）；二是量化指标趋势（缺陷收敛曲线、覆盖率、响应时间）；三是决策与变更记录（谁在什么时候因为什么做了调整）；四是遗留问题的清单与处置计划。

反面例子我也见过很多：一份精美的PPT，配了六七张截图，没有任何可追溯链接。这种材料在项目顺利时看起来效率很高，在出问题时完全无法定位。

4. 第四层：决策权与升级路径

这一层要回答两个问题：谁有权说不，说不之后走什么流程。

我的经验是：决策权必须落在有资源调配能力的人手里。如果一个人有权拒绝但没有权调人、调预算、调排期，那他的拒绝只会制造僵局。

升级路径要明确到时效：不通过后多长时间内提交整改计划，多长时间内完成整改，超期后升级到谁。没有时效的升级路径等于没有升级路径。

5. 第五层：与合同、回款、资源、发布挂钩

这一层决定了制度是否有牙齿。如果里程碑通过与否对任何实际利益没有影响，它迟早会退化成形式。

可挂钩的杠杆包括：对外回款节点与验收单绑定；对内资源追加与新阶段启动绑定；对发布节奏与合规门绑定；对团队考核与里程碑质量（而不是里程碑数量）绑定。

需要谨慎的是考核设计。如果按“按期通过率”考核，团队就会想办法让它通过。更合理的指标是“里程碑后30天内因验收遗漏产生的问题数”。

6. 第六层：制度落地的90天节奏

制度一次性铺开会引发强烈反弹。我推荐的节奏是分三步走。

1. 第1到30天：只在一个项目上试点，选一个中等复杂度、团队配合度高的项目，把验收标准和拒绝条件写清楚，跑两个完整里程碑。
2. 第31到60天：把试点中真正产生价值的3到5个检查项沉淀成模板，同时确认工具能自动采集哪些证据，不能自动采集的项要么改标准，要么接受人工成本。
3. 第61到90天：扩展到三到五个项目，同时建立里程碑健康度的月度回顾机制，用数据判断制度是在起作用还是变成了负担。

五、案例与数据观察：一家中大型企业的里程碑治理落地

这一节我把一个真实落地过程拆开讲。案例主体是一家装备制造企业，研发与交付混合模式，研发体系约600人，分布在四个事业部，同时遵守集团的安全与合规要求。下面的数据来自项目组在落地前后各6个月的统计对比。

1. 落地前的状态

落地前，这家企业的里程碑管理呈现出非常典型的“多工具、多口径”特征。事业部各自维护进度，用邮件和表格传递验收材料，集团层面看到的是汇总后的百分比。有一次集团询问某个里程碑的真实状态，得到的回答是“已完成”，但打开交付物发现接口文档还是三个月前的版本。

更具体的问题是：无法回答“这个里程碑的证据在哪里”。验收材料散落在邮件、共享盘、会议纪要里，没有统一入口，也没有版本追溯。

2. 落地的六个动作

项目组没有一上来就上重度流程，而是按下面的顺序推进。

1. 统一里程碑定义与分类。把原有40多个散点节点收敛成18个正式里程碑，按决策门、交付门、合规门、价值门分类，明确每类的决策人。
2. 重写验收标准。每个里程碑补齐进入条件、通过条件、拒绝条件，其中拒绝条件必须至少3条，且必须可量化。
3. 建立证据链规范。规定验收材料必须包含可追溯的系统记录链接，不接受纯截图材料。自动化测试报告直接关联构建记录。
4. 设置预验收窗口。正式评审前7天启动预验收，问题在预验收阶段暴露的，不计入里程碑不通过统计，鼓励提前暴露。
5. 明确拒绝权与升级路径。合规门由安全负责人一票否决，决策门由事业部总经理决策，不通过后3个工作日内提交整改计划。
6. 用统一平台承载流程与证据。这里他们选择了 PingCode 作为研发管理与项目协同平台，把里程碑模板、验收清单、证据附件、决策记录、整改跟踪全部沉淀在同一个系统里，并按项目管理工具的使用规范做了权限与流程配置。

3. 为什么选择统一平台而不是继续用表格加邮件

项目组做过一次成本测算：在原有模式下，一个里程碑的验收材料整理平均耗时14人时，跨部门对齐平均耗时3天。18个里程碑一轮下来，仅材料整理就要250多人时，而这些工时大部分花在“找材料”和“确认版本”上。

统一平台解决的不是流程有没有的问题，而是证据能不能被自动生成和自动追溯。当构建记录、测试报告、缺陷状态、变更日志都在同一系统里时，验收材料的准备就从一个“整理工作”变成一个“引用工作”。

这个案例里还有两个附加诉求值得单独说。第一是私有化部署，因为该企业在数据合规上有明确要求，研发数据不能出内网；PingCode 支持私有化部署，满足了这个约束。第二是历史系统迁移，他们原本使用 Jira 承载研发流程，需要把项目、工作项、状态映射、历史数据平滑迁移过来，PingCode 提供了对 Jira 的平滑迁移能力，使得迁移过程中没有出现研发流程中断。对于正在做国产替代选型的中大型组织，这两点是绕不过去的评估项。

4. 落地前后6个月的数据观察

下面是项目组统计的关键指标对比。需要说明的是，这些数据来自项目组的内部统计，统计口径在每个指标后都做了说明，我把它完整列出以便你判断是否适用于自己的组织。

注意第一行的变化方向。一次验收通过率从96%降到71%，这不是退步，而是制度开始工作的标志。以前96%的通过率是用虚假的绿色换来的，问题被推迟到上线后才爆发。

5. 里程碑数量与一次通过率的关系

项目组在落地过程中做过一次内部对比，把18个里程碑按团队划分为两组：一组里程碑密度较高（平均每3周一个），一组密度较低（平均每7周一个）。观察6个月后的结果，出现了一个有意思的现象。

高密度组的一次通过率更低，但里程碑后返工工时也更低。低密度组的一次通过率更高，但问题集中在少数几次评审中爆发，整改周期更长。这两个结果都不是“错”的，它们只是把风险放在了不同的位置。

6. 这套做法的适用边界

我需要诚实地说清楚它的边界。这套做法在满足以下条件时效果最好：组织规模在100人以上、存在跨部门或跨组织依赖、有合规或审计要求、里程碑周期在3周以上。

如果团队只有十几个人、每周都在交付、需求变化以天为单位，这套重制度的收益会明显低于其管理成本。这种场景下更适合用短周期迭代加持续演示，把验收动作嵌入日常节奏。

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

这一节按组织规模和场景给出具体动作。你可以直接对照自己的情况挑一条执行。

1. 100人以上中大型组织

优先做三件事：统一里程碑分类与决策人、建立可追溯的证据链、明确拒绝权与升级路径。这三件事都不依赖工具，先用手工方式跑两个里程碑，验证标准是否可执行。

跑通之后再考虑平台承载。此时你的诉求通常包括私有化部署、与现有研发流程的兼容、以及历史项目数据的迁移，评估时要重点验证这三点。

2. 30到100人组织

这个规模最容易被形式主义伤害。建议只保留决策门与交付门两类里程碑，数量控制在每季度2到4个。验收标准重点写拒绝条件，其余可以简化。

不需要复杂的评审组，决策人明确到一个人即可。规模在这个区间，速度比完备性重要。

3. 30人以下团队

不建议设正式里程碑。用每周或每两周的演示会代替，演示会上只回答三个问题：这周做完了什么可以被看到的东西、遇到了什么阻塞、下周要验证什么假设。

如果一定要设，只在关键风险点上设一个，比如首次对外发布前的合规检查。

4. 乙方交付型项目

验收标准必须写进合同附件，并且拒绝条件要双方确认。这里的核心风险不是技术问题，而是验收标准解释权。我的建议是每个里程碑的通过条件都配一个可复现的演示脚本或测试用例清单，避免后期扯皮。

同时要注意验收单与回款节点的绑定关系，把验收单签署的时效也写进合同。

5. 强合规行业

合规门必须独立出来，且必须由非项目组人员担任决策人。合规门不接受“带条件通过”，只有通过与不通过两种结果。因为合规问题的整改成本远高于一次延期的成本。

同时建议把合规检查提前到设计阶段，而不是等到发布前。合规门准备期通常占总投入的70%以上，越晚介入成本越高。

6. 敏捷与传统混合场景

这是最常见的现实情况。我的做法是在迭代层保留敏捷节奏，在发布层设置里程碑。迭代只管交付可工作的增量，里程碑只管判断“这批增量能不能进入下一阶段”。

两者之间通过一个明确的映射关系连接：哪几个迭代产出对应哪一个里程碑的验收范围，在里程碑计划里写清楚，避免验收时范围说不清。

七、不同情况下的取舍

制度设计到最后都是取舍。没有哪一套方案在所有维度上都更优，你要做的是明确自己愿意付出什么代价。

1. 验收严格度与交付速度的取舍

严格度提高，短期交付速度一定下降。这不是执行力问题，是客观规律。但严格度提高会降低返工总量，中期速度反而可能提升。

关键在于你要判断这个项目处于什么阶段。如果处于探索期、方向未定，过度验收会把团队锁死在错误方向上；如果处于交付期、方向已定，验收不足会把风险推到最后。

2. 里程碑数量多与少的取舍

多则灵敏，少则省力。我的一般建议是看依赖密度：跨团队依赖越多，里程碑应该越密；独立团队内部工作，可以稀疏。

另一种判断方式是看信息衰减速度。如果一个风险从团队传到项目群要三天，那你的评审间隔不该超过一周。

3. 工具承载与制度先行之间的取舍

先有制度再上工具，还是先上工具再补制度，两种顺序都有人成功。但我的经验是：先跑两个手工里程碑再选工具，失败的代价会小很多。因为手工阶段你会清楚知道自己真正需要什么字段、什么证据、什么权限。

反过来的风险是：工具先上，流程按工具的默认逻辑走，最后制度被工具塑形，产生了大量没人看的字段和审批。

4. 自动化采集与人工判断的取舍

能自动化的都该自动化，但要知道自动化擅长的是“有没有”，不擅长“够不够好”。缺陷关闭状态可以自动采集，但“这个方案在业务上是否可行”必须人工判断。

我的分配原则是：可枚举、可量化、可重复的检查项交给系统；涉及权衡、场景、优先级的判断留给人。把人的时间从数格子中释放出来，用在真正的判断上。

5. 甲方验收与内部验收的取舍

不要把甲方验收当作内部验收。内部验收的标准应该比甲方更严，因为甲方验收一旦不通过，代价是商务层面的。

我的做法是内部验收比对外交付提前至少10个工作日，留出整改窗口。这10天不是浪费，是保险。

八、常见问题

1. 里程碑总是被“带条件通过”，怎么破

先统计“条件”的关闭率。如果连续两个季度的条件关闭率低于60%，说明带条件通过已经成为事实上的无条件通过。

处理方式是把带条件通过纳入考核口径：带条件通过计入“未通过”统计，只有当条件在约定期限内全部关闭后，才转为通过。这个改动会立刻改变团队的行为。

2. 项目经理没有权力拒绝，怎么办

这种情况通常不是权限问题，而是制度没有给项目经理拒绝的“接口”。你可以把拒绝转化为一个结构化请求：提交一份风险说明，包含问题描述、影响范围、可选方案、各方案的代价。这份说明交给有权决策的人。

拒绝权本质上不是“说不”的权力，而是“把问题升级到正确层级”的义务。把这句话写进项目管理制度，很多僵局会打开。

3. 里程碑定得太密，团队疲于准备材料怎么办

两个方向：一是减少数量，二是降低材料成本。多数情况下问题出在第二点。如果每个里程碑都要重新整理一套材料，说明证据链没有沉淀。

解法是把可复用的证据自动化。构建记录、测试报告、缺陷趋势这类数据应该随取随用，而不是每次人工汇总。人工只准备那些真正需要判断的部分。

4. 需求频繁变更，里程碑还有意义吗

有意义，而且更有意义。需求变更频繁时，里程碑的作用从“检查完成度”转变为“检查变更影响是否被评估”。

这时候的验收标准应该包含：本次变更影响的功能范围、受影响的接口、需要回归的测试集、对交付日期的影响、以及是否触发重新估算。

5. 跨部门依赖的里程碑怎么验收

跨部门里程碑失败通常不是因为技术，而是因为责任边界不清。建议在里程碑定义阶段就明确三件事：谁提供输入、谁负责产出、谁确认接收。

验收时不看“大家配合得怎么样”，只看三样东西：输入是否按约定时间提供、产出是否符合接口约定、接收方是否确认可用。任何一项不满足就是未通过，不进入人情讨论。

6. 怎么判断里程碑制度是在起作用还是变成了负担

用四个指标判断：验收材料准备耗时是否下降、里程碑后返工工时是否下降、缺陷逃逸率是否下降、跨部门对齐周期是否缩短。

如果这四项中有三项在三个季度内没有改善，说明制度没有产生价值，需要重新审视设计。制度的成功标准是它减少了多少实际损失，而不是它被多严格地执行。

九、总结与下一步

我想留下三个和主流说法不太一样的观点。

第一，里程碑验收做得好的标志，是通过率下降，而不是上升。如果你推行节点验收之后，一次通过率还在95%以上，基本可以判定这套制度没有生效。数字变难看，是它开始真实反映现实的第一步。

第二，验收标准的关键不是写清楚“要什么”，而是写清楚“什么情况必须拒绝”。没有拒绝条件的验收清单，无论写多少条检查项，都无法阻挡任何风险。

第三，节点验收不是项目管理动作，是组织决策机制。它要求有人有权说不、有人有能力调配资源、有流程在拒绝之后继续运转。只把它当成一个检查清单，无论用什么工具都会退化成形式。

如果你只打算做一件事，我的建议是做这个：挑一个下周就要评审的里程碑，把它现有验收清单里的每一条拿出来，逐条问“谁能证明它？证据在哪？如果它不满足，我们会不会拒绝？”。把这三问答不出来的条目删掉，只留下能答出来的。然后按这份精简后的清单开一次会。

这次会议的结果很可能不好看，但它是真实的第一步。等你连续跑完三个里程碑，把每次的拒绝条件和实际整改成本记下来，你会拿到一份属于你自己组织的数据，那时候再决定要不要上平台、上多重的流程、选什么工具，判断会稳得多。