阶段流程与规范：项目负责人项目阶段制度设计关键指标

2023 年我复盘过一个 180 人研发组织的 47 个项目，213 次阶段评审记录里有 61 次结论是“带条件通过”，而其中 38 次的条件项，直到下一个阶段结束都没有人回头验证。换算下来，接近 18% 的阶段门在事实上失效了：它们生产了会议纪要和签到表，却没有生产决策。

那次复盘之后我做了一件事，把这家公司原来的 61 项阶段检查项砍到 6 项关键指标，同时把阶段门从“评审会”改造成“证据契约”。六个月后，阶段回退率从 23% 降到 9%，门禁决策时延从 4.7 天压到 1.3 天，交付周期没有变长，反而缩短了 6 天。

这篇文章讲的就是这 6 个指标是怎么选出来的、阈值怎么定、不同规模的组织该怎么取舍。如果你正在重新设计项目阶段制度，我建议先看第一节的结论，再回到自己的项目里做对照。

一、核心结论：阶段制度的成败由 6 个指标决定，而不是 60 个

1. 我最先推翻的三个假设

在做阶段制度设计时，绝大多数团队默认了三个假设，而我在每一个上面都踩过坑。

假设一：阶段越多，控制越细。很多组织把项目切成 8～12 个阶段，每个阶段配一份模板、一套评审表。结果是项目负责人的时间被文档填满，真正的技术风险反而没人看。我把阶段压缩到 5 个（立项、方案、实现、验证、交付）之后，检查项绝对数量减少约 70%，但每一项的证据强度反而提高了。

假设二：通过率越高，制度越健康。这是最危险的假设。一个阶段门的通过率长期维持在 95% 以上，通常意味着门禁形同虚设，或者评审标准被悄悄放宽了。健康的阶段门应该稳定在 75%～88% 之间，有拦截，才有存在价值。

假设三：指标是用来考核的。阶段指标的第一用途是诊断，不是排名。一旦把它直接挂钩个人绩效，数据会在一到两个季度内“变好看”，而真实风险会转移到你看不见的地方，比如评估口径被重新解释。

2. 阶段制度的本质是三张表

抛开那些厚厚的模板，一个能跑起来的阶段制度其实只有三张表：准入表、交付物证据表、退出决策表。

准入表回答“进入这个阶段之前必须已经确定什么”，比如需求基线是否冻结、技术方案是否评审、关键依赖是否确认。它约束的是入口，不是过程。

证据表回答“每一个结论用什么可追溯的东西支撑”。是缺陷列表、压测报告、基线快照，还是接口契约？证据必须是可被第三方独立查验的对象，而不是某人的口头确认。

退出决策表回答“谁来判、按什么判、判完之后分几条路走”。这一张表最容易被省略，也最致命。我见过大量制度只有准入和交付物，退出环节全靠“大家碰一下”，最后变成谁声音大听谁的。

3. 6 个关键指标与“4+2”分层

经过几轮迭代，我固定下来的关键指标是 6 个，并分成两层：4 个诊断指标用来发现流程在哪里漏水，2 个约束指标用来守住底线。

• 诊断指标一：阶段准入完备率，进入阶段时，准入表条目已满足的比例。
• 诊断指标二：交付物证据覆盖率，退出决策所依赖的结论中，有可查验证据支撑的比例。
• 诊断指标三：门禁决策时延，从证据齐备到形成正式决策的平均耗时。
• 诊断指标四：阶段回退率，完成退出决策后，在下一阶段被迫退回上一阶段的比例。
• 约束指标一：变更渗透率，需求基线冻结后，仍进入开发队列的变更占比。
• 约束指标二：阶段人力占用比，阶段管理活动（评审、文档、协调）占项目总人天的比例。

注意这四个诊断指标的关系：准入完备率低，通常会在门禁时延上暴露；证据覆盖率低，会在回退率上暴露。它们是互相咬合的，单独看任何一个都会误判。

4. 为什么我把“阶段评审通过率”从考核里删掉

阶段评审通过率是我最早用、也最早删掉的指标。原因很简单：它同时具备“易被操纵”和“信息量低”两个特征。

当通过率进入绩效考核，评审人的最优策略是让会议结论更模糊，比如写“原则上通过，后续补齐”。这个结论在统计上计入通过，在事实上什么也没决定。三个月后你去看数据，通过率 96%，一片祥和，但项目还是在验证阶段爆炸。

替代它的是“带条件通过项闭环率”：所有带条件通过的条目，在下一阶段中期之前完成验证的比例。这个指标不好粉饰，因为它要求逐条关闭并留痕。

在这家 180 人组织里，我们第一次统计这个数字时，闭环率只有 37%。引入强制闭环机制后的第三个季度，它上升到 81%，同期阶段回退率同步下降 14 个百分点。这两条曲线的相关性，比通过率有说服力得多。

二、真实场景：一个 180 人组织的阶段失控是怎么发生的

1. 现场：项目负责人成了“文档搬运工”

我刚进这家公司时，项目负责人的日程表是这样的：周一阶段评审、周二需求澄清会、周三跨部门对齐会、周四文档归档检查、周五周报和风险同步。真正用于推进项目的连续时间，每天不足 2 小时。

他们有一套看起来很完整的阶段制度：9 个阶段、47 份模板、每阶段至少 3 个签字位。但当我随机抽取 10 个项目查看实际证据时，只有 3 个项目能拿出与决策对应的可查验材料，其余 7 个项目的“证据”是聊天记录截图和口头确认。

这就是典型的制度通胀：制度文本的增长速度远远超过组织实际执行能力，最后大家只保留了“开会”这个动作，丢掉了“决策”这个目的。

2. 三次事故的复盘

第一个事故来自一个已经“评审通过”的支付模块。技术方案评审的结论是“架构可行”，但没有人验证过它与既有账务系统的对账口径。问题在验证阶段才暴露，返工 34 人天。

第二个事故来自需求冻结后的变更。项目进入实现阶段第 3 周，业务方插入 11 条变更，其中 4 条改变了数据模型。因为没人统计变更渗透率，团队直到联调失败才发现范围已经膨胀了 28%。

第三个事故最典型：一个项目的阶段评审拖了 9 天才开，原因是两个部门负责人的日历排不到一起。这 9 天里，开发团队按原方案推进了 200 多个人天的工作量，其中有相当一部分后来被推翻。

3. 数据观察：延迟不发生在阶段内，而发生在门禁前

我们对 47 个项目做了周期分解，发现一个反直觉的结论：阶段超时的主要成因不是阶段内的工作变慢，而是门禁前的等待。

在超期的 21 个项目里，阶段内实际工作量超出估算的部分平均只占超时总量的 31%，而“等待评审排期”“等待证据补齐”“等待决策人确认”合计占了 54%。剩下 15% 来自返工。

这意味着，如果只盯着“开发效率”，你永远解决不了阶段超时。真正要优化的是门禁机制本身。

4. 改造前后：六个月的数据对比

改造动作只有四项：阶段从 9 个压到 5 个；每个阶段只保留 3～5 个准入条目；退出决策必须在证据齐备后 2 个工作日内完成；带条件通过项强制闭环跟踪。

六个月内，阶段准入完备率从 58% 升到 91%，交付物证据覆盖率从 44% 升到 86%，阶段回退率从 23% 降到 9%，门禁决策时延从 4.7 天降到 1.3 天，而阶段人力占用比从 24% 降到 12%。

最值得注意的一项：项目的平均交付周期缩短了 6 天。这说明更严格的门禁和更快的交付并不矛盾，前提是门禁本身不制造等待。

三、拆解五类常见误区

1. 误区一：把阶段门当成审批会

审批会的核心动作是“签字”，阶段门的核心动作是“判断”。这两者的区别在于：签字关注的是责任归属，判断关注的是风险状态。

我见过一个项目的阶段门，参会的 11 个人里只有 2 个人真正读过技术方案，其余 9 个人在会议开始前 5 分钟才拿到材料。这样的会议即使全票通过，也不产生任何风险消解。

修正方式很直接：把“会”变成“决策记录”。材料必须提前 48 小时送达，评审问题必须在会前以书面形式提出，会议只处理未达成一致的分歧项。会议时长通常能从 90 分钟压到 35 分钟。

2. 误区二：用文档齐全度代替风险消解度

文档齐全度是最好统计的指标，所以它最容易被滥用。一份格式完美的《技术方案说明书》可能有 60 页，但对“这个模块在峰值流量下会不会雪崩”这个真问题只字未提。

我的判断标准是：每一条准入条目都必须能回答“如果它没做到，会在哪个阶段以什么形式爆炸”。回答不出来的条目，直接删掉。

按这个标准筛一遍，那家公司的 61 项检查项里有 34 项被删除。删掉之后，项目负责人反而更愿意执行剩下的 27 项，因为每一项都有明确的失败场景对应。

3. 误区三：所有阶段使用同一套权重

把同一组指标、同一套阈值套用到所有阶段，是最隐蔽的设计错误。立项阶段的核心风险是“方向错”，实现阶段的核心风险是“质量差”，验证阶段的核心风险是“未被发现的问题漏出”。

正确的做法是按阶段调整指标权重：立项阶段重点看准入完备率和变更渗透率；实现阶段重点看证据覆盖率和回退率；验证阶段重点看缺陷逃逸和回退率。权重要变，但指标体系不变，这样横向对比才成立。

4. 误区四：制度与工具两张皮

当阶段状态记录在表格里、任务进度记录在项目管理平台上、缺陷记录在另一个系统里时，任何一个阶段指标都需要人工汇总。人工汇总的指标有三个特点：滞后、失真、不可持续。

我的经验是：如果某个阶段指标无法从日常工作中自然产生，它最终一定会消失。指标不应该是一个额外的填报动作，而应该是工作流的副产品。

5. 误区五：把阶段指标直接当绩效考核

这一点我在第一节提过，但值得再强调：阶段指标一旦被用于排名，就会触发“指标优化”行为。项目负责人会倾向于把阶段划分得更粗、把证明标准解释得更宽、把回退记录改成“范围调整”。

更合理的用法是：指标用于发现异常项目，异常项目触发复盘，复盘结论用于改制度。考核对象是制度的有效性，不是个人的数字。

四、专业判断逻辑：六个关键指标怎么定义、怎么算阈值

1. 阶段准入完备率（Readiness）

定义：进入阶段时，准入表中已满足条目数 ÷ 准入表条目总数。

计算要点在于“已满足”的判定必须绑定证据 ID，而不是打勾。比如“需求基线冻结”这一条，满足的标志是存在一个冻结版本的基线快照 ID，且该基线之后的新增需求数不超过约定阈值。

阈值不建议用绝对值，而建议用滚动分位数。我通常用最近 20 个阶段的 P50 作为基线，当某个项目的准入完备率低于基线 10 个百分点以上时触发提醒。这样阈值会随组织成熟度自然上升，不需要每季度手工调整。

2. 交付物证据覆盖率（Evidence）

定义：退出决策所引用的结论中，有可独立查验证据支撑的比例。

“可独立查验”是关键限定词。聊天记录截图不算，因为它无法被第三方核验来源；口头确认不算；某人的邮件回复算，但需要能定位到具体邮件 ID。我一般要求证据必须落在三类对象上：版本化文档、系统内的结构化记录、可复现的测试或监控数据。

这个指标的健康区间是 80%～92%。低于 80%，退出决策会变成主观判断；高于 92% 且长期保持，要警惕团队在过度留痕，管理成本会反噬。

3. 门禁决策时延（Gate Latency）

定义：从证据齐备到形成正式决策的耗时，单位通常取工作日。

这个指标是整个体系里投入产出比最高的一个。它不需要改变任何技术实践，只需要改变决策机制。那家 180 人组织把时延从 4.7 天压到 1.3 天，靠的是三件事：决策人从 5 人减到 2 人；材料提前 48 小时送达；分歧项超过 2 个才开会，否则走异步决策。

阈值建议设为 ≤2 个工作日。超过 2 天后，项目团队通常会“先干起来”，门禁的实际约束力归零。

4. 阶段回退率（Rollback）

定义：完成退出决策后，在下阶段被迫退回上阶段的项目阶段数 ÷ 总阶段数。

这是我认为最能反映阶段制度真实有效性的单一指标。回退的具体形式包括：设计返工、需求重新澄清、缺陷集中爆发导致暂停、架构方案推翻重做。

需要区分两类回退：一类是正常的探索性回退，比如验证阶段发现方案不可行；另一类是制度性回退，即上阶段本应发现但没发现的问题。只有后者应该计入指标。这个区分需要在回退记录里加一个“是否属于上阶段准入范围的疏漏”字段。

5. 变更渗透率（Change Seepage）

定义：需求基线冻结后仍进入开发队列的变更条目数 ÷ 冻结时的基线条目数。

这个指标容易被误解为“变更越少越好”，其实不是。合理范围是 8%～15%：太低说明需求探索不足，真正的需求没有浮现；太高说明基线冻结只是形式。

我通常会和团队约定三条阈值线：低于 15% 为正常，15%～25% 需要项目负责人说明，高于 25% 触发范围重新评审。触发时要问的不是“为什么变更这么多”，而是“冻结时我们漏掉了哪类信息”。

6. 阶段人力占用比（Effort Ratio）

定义：阶段管理活动（评审、材料准备、跨部门协调）所消耗人天 ÷ 项目总人天。

健康区间是 8%～15%。低于 8%，通常说明制度被架空，阶段门只是走个过场；高于 15%，说明管理开销已经开始侵蚀产能，需要检查是不是阶段切得太细、或者决策人太多。

我见过一个极端案例：某团队这个指标达到 27%，原因是每个阶段都要准备 4 份材料、开 3 次会、走 2 轮签字。把材料合并成 1 份、会议合并成 1 次之后，指标降到 11%，项目进度反而提前了两周。

7. 阈值算法与配置示例

下面是我在一个私有化环境里实际使用过的阶段门配置片段。它的设计原则是：所有阈值都来自历史数据的分位数，而不是拍脑袋的绝对值。

stage: S3-实现开发
gate_owner: 项目负责人

entry_criteria:

id: E1

name: 需求基线冻结

evidence_ref: baseline_snapshot_id

rule: 未关闭变更数 = 90%

id: E3

name: 外部依赖确认

evidence_ref: dependency_contract_id

rule: 未确认依赖数 == 0

exit_criteria:

id: X1

name: 单元测试覆盖率

metric: line_coverage

rule: ">= 70%"

id: X2

name: 阻断级缺陷清零

metric: blocker_and_critical_open

rule: "== 0"

id: X3

name: 接口契约一致性

metric: contract_mismatch_count

rule: " baseline * 1.5"

rollback_rate:

baseline: P75(history_20)

alert_when: "> baseline"

evidence_coverage:

target_range: [0.80, 0.92]

注意 gate_latency_days 用的是 P50 的 1.5 倍作为告警线，而不是一个固定天数。原因是不同阶段、不同项目类型的合理时延差异很大，固定阈值会制造大量误报，最后被团队无视。

8. 门禁严格度与交付效率的真实关系

“严格的门禁会不会拖慢交付”是每次讨论都会出现的质疑。我用同一组织内不同项目的门禁严格度做了分组对比，结论是：门禁严格度与交付周期不是线性负相关，而是呈倒 U 型。

在严格度过低时（准入完备率低于 60%），交付周期反而更长，因为返工和回退吃掉了时间。在严格度适中时（准入完备率 80%～92%），周期最短。当严格度进一步升高到 95% 以上时，周期重新变长，此时瓶颈变成了等待和留痕成本。

这个倒 U 型是我建议把证据覆盖率上限设在 92% 的直接依据。超过这个点，你付出的边际管理成本开始大于它消解的风险。

9. 证据在阶段间的衰减漏斗

还有一个容易被忽略的观察：证据在阶段间传递时会衰减。立项阶段提出的假设，到实现阶段可能只剩 60% 被真正验证过；到交付阶段，能被追溯到原始假设的证据链往往不足一半。

我建议每隔两个阶段做一次“证据链回溯”：随机抽取 5 条已通过决策，沿证据 ID 往回追，看能否达到最初的假设。达不到的，说明中间的某个门禁放行了不完整的结论。

五、案例与数据观察：以 PingCode 承载阶段制度

1. 为什么 100 人以上的组织需要平台化承载

30 人以下团队用表格加会议就能把阶段管住，因为信息量小、沟通成本低。但到了 100 人以上、多项目并行时，人工汇总的边际成本会急剧上升。

我测算过：一个 180 人组织如果靠人工汇总 6 个阶段指标，每周需要约 12 个人时；随着项目数从 15 个增加到 47 个，这个数字会升到 30 个人时以上，而且数据滞后一周。滞后的指标没有决策价值。

PingCode 主要服务中大型企业及 100 人以上组织，这类客户恰好处在“人工汇总已经扛不住、但流程又不能放松”的阶段。这也是我在这个案例里选择用它来说明的原因，它面对的就是这个问题域。

2. 阶段对象建模：从“看板列”到“阶段实体”

很多团队用看板列来表示阶段，比如“开发中”“测试中”“已上线”。这种建模方式的致命问题是：看板列只有位置，没有准入、没有证据、没有决策记录，因此无法产生任何指标。

正确做法是把阶段建成独立实体，拥有自己的准入条目、证据关联和退出决策。项目在不同阶段之间迁移时，系统自动校验准入条目是否满足，并记录决策人和决策时间。

这样一来，前面说的六个指标全部变成了“副产品”：准入完备率来自准入条目的校验结果，门禁时延来自证据齐备时间与决策时间的差值，回退率来自阶段迁移的方向记录。不需要任何人额外填报。

3. Jira 平滑迁移中的阶段字段映射

我参与过几次从 Jira 迁到 PingCode 的过程，阶段字段映射是最容易出问题的环节。经验上有三类字段必须提前梳理清楚。

第一类是把 Jira 的状态字段映射到阶段实体。Jira 里的状态通常很细（十几个甚至几十个），直接映射会导致阶段数量爆炸。我的做法是先归并：把十几个状态按“入口条件”聚成 5 个阶段，再逐一确认每个原始状态归属哪个阶段。

第二类是自定义字段。Jira 里大量用于承载阶段信息的自定义字段，需要逐一判断是保留为业务字段、还是转化为阶段准入条目。判断标准是：这个字段是否会影响某次决策的结论。会，就转成准入条目；不会，就作为普通属性保留。

第三类是历史记录。迁移时最容易丢的是阶段变迁历史和历史决策记录。这部分如果丢失，回退率和门禁时延的历史基线就没有了，新制度的阈值只能重新积累。PingCode 支持 Jira 平滑迁移，我在实操中会把历史状态的变迁时间点一并带过去，作为初期阈值计算的基线数据。

4. 私有化部署对阶段数据自持的意义

阶段制度产生的数据，本质上是一份组织的研发过程档案：每个阶段谁做了什么判断、基于什么证据、花了多长时间。这类数据对很多中大型企业来说是敏感资产。

PingCode 支持私有化部署，这一点在金融、制造、政企类客户里经常成为硬性要求。从阶段制度设计的角度看，私有化带来的直接好处是：阶段指标的计算逻辑可以完全自定义，不必受限于 SaaS 版本的字段和报表能力；同时历史数据的保留策略由自己决定，做三年期趋势分析时不会因为留存期限制而断档。

当然，私有化也有代价：升级节奏要自己规划，需要有人承担环境维护。这个取舍我在第七节会展开。

5. 迁移与落地数据观察

下面这组数据来自一个 240 人研发组织的迁移前后对比，属于我的项目观察记录，可以视为情景样本而非行业统计。迁移的核心目标不是换工具，而是让阶段指标可自动产出。

迁移前，阶段数据完整度（有准入记录、有证据关联、有决策记录三项齐全的比例）约为 46%，阶段状态同步平均滞后 3.8 天。迁移并重构阶段模型后，数据完整度升至 93%，同步滞后降到 0.4 天。

更重要的是指标产出方式的改变：迁移前 6 个阶段指标全部依赖人工汇总，每周约 12 个人时；迁移后其中 5 个由系统自动产出，人工只保留“回退性质判定”这一项主观判断，每周约 1.5 个人时。

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

1. 30 人以下团队：只做两张表

这个规模不要上系统，也不要设计复杂指标。只需要两张表：一张准入清单（每个阶段 3 条以内），一张回退记录。

准入清单用共享文档维护即可，回退记录用来观察哪类问题反复出现。如果连续三个月回退次数少于 2 次，说明当前制度够用；超过 5 次，再考虑增加指标。

这个阶段最常见的问题是过度设计。我见过 12 个人的团队搞出 6 个阶段、28 项检查，结果三个月后全部废弃。

2. 30～100 人团队：引入三项指标

这个规模开始出现多项目并行，沟通成本上升。建议引入阶段准入完备率、阶段回退率、变更渗透率三项指标，用轻量工具或平台自带报表维护。

重点是把“带条件通过”这个口子管住。这个规模下，评审人往往是兼职的资深工程师，他们最容易妥协。建议规定：带条件通过项必须在下一阶段中期前闭环，未闭环的项目在阶段看板上标红。

3. 100～500 人、多项目并行：六项指标全上，且必须自动化

到了这个规模，人工汇总已经不可行。建议把六个指标全部纳入体系，并确保至少四项由系统自动产出。

优先级排序是：门禁决策时延最先做，因为它最容易改、见效最快；然后是准入完备率和证据覆盖率，这两项决定了回退率；最后是人力占用比，用来监控管理成本是否失控。

这个阶段还建议做一件事：按项目类型分层。预研型项目和交付型项目的阶段阈值不应相同，前者允许更高的变更渗透率，后者要求更严的证据覆盖率。

4. 500 人以上、强合规行业：增加审计维度

在金融、医疗、汽车电子等强合规场景，阶段制度不只是管理工具，还是合规证据链的一部分。除了六个指标，还需要增加两项：决策可追溯完整率（每次阶段决策能否追溯到决策人、时间、依据）和证据留存合规率。

这个规模下，私有化部署和数据自持通常会成为必要条件。同时要注意阶段模型的版本管理：制度演进过程中，旧项目的阶段定义不能被动改变，否则历史趋势分析会失真。

七、不同情况下的取舍

1. 严格门禁 vs 交付速度

这两个目标并非天然对立，但对立的临界点确实存在。前面那张倒 U 型图给出了一条可操作的分界线：准入完备率 80%～92% 是可以同时兼顾两者的区间。

低于 80% 时，你省下的评审时间会以返工的形式加倍还回来。高于 92% 时，你多花的每一分钟都不会再带来回退率的下降，只会拉长周期。

我的建议是：初期允许自己落在 70%～80%，通过三个季度的数据积累逐步向 85% 靠拢。一步到位定到 95% 的组织，通常在两个月内就会因为执行成本过高而放弃。

2. 统一制度 vs 项目类型差异

统一制度的好处是可比性强、管理成本低；差异化的好处是贴合实际、执行阻力小。折中方案是“指标体系统一、阈值分层”。

所有项目用同一组六个指标，这样横向对比和历史趋势都成立；但阈值按项目类型分三档：交付型、迭代型、预研型。交付型要求证据覆盖率不低于 88%；迭代型不低于 80%；预研型可以不考核证据覆盖率，但要求变更渗透率不超过 30%。

这个设计的关键是：指标不变，只是标准不同。一旦指标体系本身开始分化，你就在制造数据孤岛。

3. 自建 vs 采购

自建阶段管理系统的诱惑在于“完全贴合我们的流程”。但从我的观察看，自建项目最大的隐性成本不在开发，而在三年后的维护和迁移。

流程会变，组织会变，工具链会变。自建系统在第一次大改流程时通常还能应付，第二次就开始出现“改不动，只能绕过去”的情况。绕过三次之后，系统就变成了摆设。

我的判断基准是：如果组织规模在 100 人以下、流程独特性极高（比如涉及特殊行业的合规要求），可以考虑轻量自建；如果规模在 100 人以上，优先选择支持阶段实体建模、私有化部署、并且能从既有平台平滑迁移的方案。

4. 诊断 vs 考核

最后一个取舍，也是最重要的一个。六个指标到底用来干什么？

我的立场很明确：指标的第一用途是发现异常，不是评价个人。合理的用法是：某个项目的回退率超过阈值，触发一次 60 分钟的复盘；复盘发现是准入表设计问题，就去改准入表；连续三个项目出现同类问题，才升级为流程改进项。

如果一定要和考核挂钩，我建议只挂钩一件事：带条件通过项的闭环率。因为这一项直接反映责任人是否对自己承诺的事情负责，而且很难粉饰。

八、下一步：30 天落地路线

1. 第 1 周：只做一件事，算清现状

不要急着改制度。用一周时间，把最近 6 个月的阶段决策记录翻出来，人工统计四个数字：阶段准入完备率、证据覆盖率、门禁决策时延、阶段回退率。

样本量不需要很大，20～30 次决策就够。这一周的目标不是得到精确数字，而是让团队亲眼看到差距在哪里。我做过很多次，绝大多数人第一次看到自己的门禁决策时延是 4 天以上时，都会愣一下。

2. 第 2～3 周：重写准入表，砍掉一半条目

把现有检查项逐条对照“如果它没做到，会在哪个阶段以什么形式爆炸”这个问题。回答不出来的，直接删除。目标是把条目数减少 50% 以上。

剩下的每一条，都要绑定一个证据类型。如果某条无法绑定具体证据，说明它本身就不该作为准入条件，而应该作为建议实践。

同时确定退出决策的规则：谁判、多久内判完、判定后有几条路径（通过、带条件通过、回退）。规则必须写死，不能留“视情况而定”。

3. 第 4 周：建立指标看板，跑通一个样本项目

选一个正在进行中的中等规模项目作为试点，把新的准入表应用上去，观察四个指标的变化。这一周最重要的是验证指标能否自动产出。

如果需要人工填报表单才能得到数据，说明阶段建模还没有到位。我建议这一周同步检查工具侧：阶段是否建成了独立实体、准入条目是否能自动校验、证据是否能通过 ID 关联、阶段迁移是否留痕。

4. 长期：把阈值交给数据，把判断留给人

30 天只能让制度跑起来，让它跑好需要更长时间。我通常建议在第三个月做第一次阈值校准：用积累的 20 个阶段数据重新计算 P50 和 P75，替换掉初始的拍脑袋数值。

之后每季度校准一次。半年之后你会发现，阈值会自动向上收紧，而这种收紧是团队自己用行为数据推动的，不需要任何人下发命令。

回到最开始那个问题：阶段制度设计的关键指标到底该怎么选？我的答案是，不要选那些容易统计的指标，要选那些能让项目负责人做出更好判断的指标。准入完备率让他知道入口是否安全，证据覆盖率让他知道结论是否可靠，门禁时延让他知道决策是否及时，回退率让他知道出口是否牢靠。这四个指标之外的所有数字，都只是锦上添花。