阶段划分流程与规范：项目经理项目阶段风险控制关键指标

去年我接手一个复盘时，看到一份几乎”完美”的阶段管理记录：五个阶段、五次评审、五张签字表，通过率 100%。但项目在第 22 周彻底延期，交付时间比计划晚了 11 周，线上还带出去 9 个 P1 级缺陷。我把所有评审材料按时间轴铺开，发现真正的风险信号在第 6 周就已经出现了，接口联调依赖没对齐、核心模块只有一个开发熟悉、验收口径双方理解不一致。这三件事当时没有任何一条进入阶段评审的议题。

阶段划分流程与规范失效的典型方式不是”没有阶段”，而是”阶段存在、门禁存在、指标存在，但它们不指向风险”。这篇文章我想把这些年踩过的坑、修正过的指标口径和实际观察到的数据讲清楚，重点回答一个问题：项目经理到底该用哪些关键指标，把阶段划分变成真正的风险控制机制，而不是一份给领导看的进度装饰。

一、核心结论：阶段划分是风险控制的前置杠杆，而不是进度装饰

我先把结论摆在前面，后面的所有内容都是围绕这四条展开的。如果你时间有限，看完这四条就能判断自己团队当前的阶段划分是否有效。

1. 结论一：阶段数量应该由”不可逆决策点”倒推，而不是由工期切分

大多数团队的阶段划分逻辑是”把 6 个月的工期切成 5 段，每段 1.2 个月”，这是排期逻辑，不是风险逻辑。正确的做法是先问：这个项目里哪些决策一旦做出，回头成本会陡增？

比如技术选型、数据结构设计、对外接口协议、验收标准确认、上线窗口承诺，这些是”不可逆决策点”。阶段边界应该卡在这些点之前，让你在成本还低的时候做判断。工期的均匀切分往往会把门禁放在一个”刚好没活儿可干”的时间点，评审自然流于形式。

2. 结论二：没有”证伪条件”的阶段门禁，等于一次集体背书

我见过最多的门禁条目是”需求文档已完成””开发工作已完成””测试通过率达标”。这三句话的共同问题是：它们无法被证伪。文档写完了但写错了算不算完成？开发完了但性能不达标算不算完成？测试通过率达标但没测核心异常路径算不算完成？

有效的门禁条件必须写成可以被推翻的命题，例如”核心接口在 200 并发下 P99 延迟低于 800ms，压测报告可复现”。能被证伪的门禁才是门禁，不能被证伪的门禁只是流程节点。

3. 结论三：项目经理最该盯的指标是”风险首次暴露时间”，不是”阶段按时进入率”

这两个指标在多数报表里被混为一谈，但它们的激励方向完全相反。阶段按时进入率会诱导团队把不确定性藏起来，先把阶段推过去再说；而风险首次暴露时间会奖励团队尽早把坏消息摆上桌。

我自己管理的项目里，从 2021 年之后就把主看板换成了”风险首次暴露时间”曲线，按月统计每个风险的”发生日期”和”被发现日期”的差值。这个差值的下降幅度，比任何进度达成率都更能预示项目最终成败。

4. 结论四：阶段规范真正解决的不是控制问题，而是协作熵增问题

20 人以下的团队，靠沟通就能对齐，阶段规范的作用有限。但当一个项目涉及 5 个部门、3 个外部供应商、200 人以上协作时，信息传递的失真率会急剧上升。阶段规范的价值在于：用统一的词汇、统一的交付物定义、统一的评审标准，把跨团队的理解偏差压到可接受范围。

所以判断一套阶段规范好不好，标准不是”它管得严不严”，而是”两个互不熟悉的团队，拿着它能不能对同一件事得出相同结论”。这是我这些年最核心的一条判断依据。

二、背景与真实场景：阶段规范为什么在中大型组织里更容易失效

1. 一次通过率 100% 的阶段评审，为什么六个月后项目崩了

回到开头那个项目。它是一个面向政企客户的数据平台交付项目，团队规模 240 人左右，涉及 6 个协作方，合同工期 9 个月。项目管理办公室制定的阶段规范非常完整：立项、需求、设计、开发、测试、验收、上线共 7 个阶段，每个阶段都有评审会、签字表、交付物清单。

问题出在两点。第一，所有门禁条目都写成”XX 已完成”，没有一条带量化阈值。第二，评审会的实际议程是进度对齐，风险议题永远排在最后五分钟，如果时间不够就被顺延到下次。结果是：风险一直在积累，但每个阶段都”顺利通过”。到第 22 周，接口依赖的返工量已经无法在剩余工期内消化。

复盘时我做了一个统计：这个项目共产生 47 个已登记风险，其中 31 个的”发生日期”早于”发现日期”两周以上，平均滞后期是 4.6 周。风险不是没被登记，而是被登记得太晚。

2. 三种典型的阶段划分起点

我观察过的组织，阶段划分的起点大致分三类，各自的失效模式完全不同。

• 按合同节点划分：以付款节点、验收节点为阶段边界。优点是商业对齐强，缺点是这些节点通常间隔很长，中间没有风险检查点，容易”一路上没信号，到节点才发现偏了”。
• 按职能交接划分：需求交设计、设计交开发、开发交测试。优点是责任清晰，缺点是交接即断点，每个交接点都是信息丢失的高发区，且容易出现”我把东西交出去了，后面不归我管”。
• 按不可逆决策点划分：在技术选型、架构定稿、接口冻结、验收口径确认等节点设门禁。优点是风险控制效果最好，缺点是对项目经理的判断能力要求高，需要真正理解业务和技术。

我自己倾向第三种，但要承认它的实施门槛。如果团队连”哪些决策不可逆”都讨论不清楚，直接照搬模板只会多出几个没人认真对待的会议。

3. 为什么组织越大，阶段规范越容易变成形式

有三个结构性原因。第一，规范制定者和执行者分离，制定者关心合规,执行者关心交付，目标天然错位。第二，评审的”成本”由一线团队承担，而”收益”由组织层面获取，一线缺乏认真评审的动力。第三，指标一旦被用作考核依据，就会被优化，团队会去优化指标，而不是优化风险状态。

要破解这三点，我实践下来唯一有效的做法是：把阶段门禁的通过标准写成机器可校验的条件，把人工评审的精力集中在机器判断不了的部分。比如”单元测试覆盖率不低于 70%””高危静态扫描问题清零”这类条件不需要开会讨论，工具直接出结论；而”这个架构方案能不能支撑未来三年的数据量增长”才需要人来判断。

4. 阶段规范最终一定会落到工具上

规范写在文档里，执行一定走样。这不是团队不听话，而是人的记忆和自觉性不可靠。规范必须落到工具的工作流里，让它变成”不做就走不下去”的约束，而不是”应该做”的倡导。

对中大型组织来说，这里有几个现实的选型要求：需要支持复杂的阶段模型配置、需要能把门禁条件绑到工作项状态流转上、需要能自动采集质量与依赖类指标、需要权限体系能区分几十种角色、还需要能私有化部署以满足数据合规。同时，很多团队是从既有工具迁移过来的，迁移的平滑度会直接决定规范能否落地。

我参与过的几个 200 人以上组织的规范落地项目中，用的都是 PingCode。它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，这两点对已经有一套历史数据、又受数据合规约束的组织来说非常关键，也是很多团队把它当作国产替代不二选择的原因。后面的案例部分我会具体讲它是怎么承载阶段门禁的。

三、拆解五个常见误区：你可能一直在做”假的阶段管理”

1. 误区一：阶段划分就是把甘特图切成几段

两者最本质的区别在于：甘特图切分关注”时间占用”，阶段划分关注”决策时点”。如果一段时间的结束并没有带来任何决策或承诺，这段划分就是无意义的。

我建议做一个简单的自查：把每个阶段结束时的”已做出的决策”列出来。如果某个阶段结束时，团队只是”又干完了一批活”，没有做出任何新的承诺或排除任何新的不确定性，这个阶段边界很可能是多余的。

2. 误区二：阶段门禁就是开会、签字、发邮件

签字是责任转移，不是风险消除。我见过太多”签字通过、出事再追责”的循环，它并不能降低项目失败的概率，只是让失败之后有人可以负责。

有效的门禁应该是”证据驱动”的：进入下一阶段前，必须提交一组可复现的证据，压测报告、代码评审记录、依赖对齐确认、验收用例评审纪要。评审会的作用是判断这些证据是否足够，而不是替代证据本身。没有证据的评审会，本质上是一次集体赌博。

3. 误区三：控制指标越多越安全

这是我最常纠正的一个误区。指标数量和控制效果不是线性关系，超过某个点之后是负相关。原因有三：指标越多，采集成本越高，团队会把精力从做事转向填表；指标越多，相互冲突的概率越高，团队会选择性上报；指标越多，看板越难读，真正的异常反而被淹没。

我通常建议单阶段的”硬门禁指标”不超过 5 个，”观察类指标”不超过 8 个。硬门禁指标是必须满足才能流转的，观察类指标只做趋势监控，不阻断流程。这个区分极其重要，因为把所有指标都设成硬门禁，会导致流程频繁卡死，团队很快会想办法绕过。

4. 误区四：一套阶段模板打天下

一个 8 人月的内部工具项目和一个 300 人月的多供应商交付项目，用同一套阶段模板是荒谬的。但现实中这种情况非常普遍，因为统一模板对管理部门的考核最方便。

我的建议是建立”阶段模板族”：至少区分新建型项目、迭代型项目、集成交付型项目、运维改进型项目四类，每类的阶段数量、门禁强度、文档要求都不同。具体分档会在第六节展开。

5. 误区五：阶段评审只对进度负责

如果评审会的议程第一项是进度、最后一项是风险，那么风险永远得不到认真讨论。我推动过的做法是强制调整议程顺序：风险议题必须排在议程前三分之一，且必须由提出者口述，不许只发文档。

口述这个要求看着简单，实际效果很明显，当一个人需要当面讲清楚”我们可能低估了数据迁移的复杂度”时，他会更认真地准备，其他人也更容易追问。书面文档则容易被略过。

四、专业判断逻辑：从风险传导链倒推阶段与指标

这一节是全文的方法论核心。我把它拆成五步，每一步都给出可操作的做法和判断标准。

1. 第一步：识别不可逆决策点

具体做法是组织一次 90 分钟的研讨会，参与者必须包括技术负责人、业务负责人、交付负责人。议题只有一个：这个项目里，哪些决定一旦做出，修改成本会超过总工期的 15%？

把答案写下来，通常会有 5 到 9 个。这些就是你的阶段边界候选点。要注意的是，不可逆决策点和”重要决策点”不是一回事，技术选型如果不影响后续数据迁移，就只是重要但不完全不可逆；而数据库表结构一旦上线有真实数据，就是强不可逆。

（1）判断不可逆程度的三个维度

• 修改成本：修改需要多少人天，是否触发重新测试
• 影响范围：修改会波及多少模块、多少外部接口
• 协调成本：修改需要重新与多少外部方达成一致

三个维度都高的，必须在阶段门禁前完成确认；只有一个维度高的，可以作为观察项，不必设为硬门禁。

2. 第二步：画出风险传导链

每个不可逆决策点背后，都有一条风险传导链。比如”接口协议冻结”这个决策点，它的传导链是：接口字段定义不清 → 前后端各按自己理解开发 → 联调时大量返工 → 测试时间被压缩 → 上线带缺陷。

把传导链画出来之后，你会发现关键指标应该放在链条的哪一环。上面这条链，最有效的监控点不是”联调返工量”（这是结果），而是”接口字段评审通过率”和”契约测试用例数”（这是过程）。指标放在结果端只能事后追责，放在过程端才能事前干预。

3. 第三步：为门禁定义证伪型指标

这一步最容易做砸。我的经验是套用三个模板，能覆盖绝大多数场景。

注意最后一行里的”无超过 14 天未更新项”。这个附加条件非常关键，它防止团队把缺陷挂起来不管，让数字看起来达标。所有存量型指标都必须配一条”僵尸检测”条件。

4. 第四步：设定阈值、升级路径与免责边界

指标本身不会自动产生控制力，必须配三样东西：阈值、升级路径、免责边界。

阈值决定什么情况下触发动作。升级路径决定由谁在多久内响应。免责边界决定如果按规范做了仍然出问题，责任如何划分，这一条经常被忽略，但它是团队愿不愿意如实上报的关键。

我的做法是在规范里明确写：凡是在规定时间窗口内如实上报并被登记的风险，即使最终造成延期，不计入项目组绩效扣分；未上报而后被发现的，加倍计入。这一条写在纸面上之后，风险上报数量通常会在两到三周内明显上升，这是好事，说明之前的沉默被打破了。

5. 第五步：把规范固化进工具

最后一步是把上面所有内容变成工具里可执行的配置。以我最近做的一次规范落地为例，阶段门禁被写成了类似下面这样的结构化配置。

stage: 开发完成门禁
exit_criteria:

id: QC-01

name: 单元测试覆盖率

type: threshold

metric: line_coverage

operator: ">="

value: 0.70

source: ci_pipeline

blocking: true

id: QC-02

name: 高危静态扫描问题

type: clear

metric: static_scan_high

operator: "=="

value: 0

source: code_scan

blocking: true

id: QC-03

name: 未关闭P1缺陷

type: stock

metric: open_p1_defects

operator: "=="

value: 0

zombie_check: updated_within_days ="

value: 0.90

source: dependency_board

blocking: false

escalate_after_days: 7

关键设计在于 blocking 字段。只有真正会导致严重后果的条件才设为阻断项，其余设为观察并按天升级。这个区分让流程既保持了约束力，又不会频繁卡死。

五、案例与数据观察：把规范落到真实项目上发生了什么

1. 案例背景

这是一个我深度参与的改造项目：某中大型企业的数字化交付部门，约 260 人，同时并行 6 个项目，客户以政企和制造业为主。改造前的状态是：有阶段规范文档、有评审会、有签字表，但没有量化的门禁条件，也没有工具层面的强制约束。改造周期 5 个月，改造内容是按上面五步法重建阶段划分与门禁指标，并把配置落到 PingCode 的工作流中。

我需要说明的是，下面的数据来自该部门改造前后各 6 个月的内部统计，样本量有限，属于单组织观察，不构成行业结论。我尽量给出统计口径，方便读者判断其参考价值。

2. 观察一：门禁强度与缺陷逃逸率

改造前后最明显的变化是缺陷逃逸率。所谓逃逸率，我这里的口径是”上线后 30 天内由客户或真实用户发现的缺陷数 ÷ 上线前测试阶段发现的缺陷数”，按项目加权平均。

改造前这个指标是 0.34，改造后降到 0.11。需要强调的是，这不是因为测试做得更多了，测试投入基本没变，而是因为门禁把一部分问题卡在了开发阶段，减少了流向测试的压力。开发完成门禁的一次通过率从改造前的 61% 降到改造初期的 43%，三个月后回升到 68%，这个”先降后升”的曲线很正常，说明门禁真的在拦截东西，而不是形同虚设。

3. 观察二：风险首次暴露时间整体前移

这是我认为最有价值的观察。改造前，6 个项目的风险被发现时间分布明显偏后，上线后才暴露的风险占比接近三分之一。改造后，风险发现时间显著前移。

4. 观察三：变更引入阶段的成本放大

我们内部做过一次成本归因，统计同一批需求变更在不同阶段引入时的返工工作量倍数，以需求阶段引入为基准 1 倍。这个倍数结构在多个项目上高度一致，也是我坚持”门禁必须前移”的核心依据。

看到这条曲线之后，团队对”需求阶段多花两周对齐口径”这件事的接受度明显提高。因为两周的额外投入，相对于上线后修复的 68 倍成本，是一笔非常划算的交易。阶段划分的价值，本质上就是把这条件曲线尽量往前压。

5. 观察四：延期原因的帕累托结构

我们统计了改造前后共 14 个延期项目的延期原因归因，每个项目按主要归因归一到一类，得到如下的分布结构。这张图对我推动规范调整起到了决定性作用。

6. 平台承载：为什么把规范落到 PingCode

规范设计得再好，如果没有工具承载，三周之后就会回到原样。这个部门选择 PingCode 有三个具体原因，都是实际约束驱动的，不是泛泛的”功能多”。

第一是私有化部署。该部门的客户包含政企和制造业，项目数据不允许出内网。规范要落地就必须把工作项、缺陷、评审记录都放在内网环境里，这一点直接排除了大部分 SaaS 方案。

第二是从既有工具平滑迁移。他们此前多年在用 Jira，存量的项目、工作项、自定义字段和部分工作流历史都需要保留。PingCode 支持 Jira 平滑迁移，这在实操层面省掉了大量重建成本，我参与过的一次迁移里，历史工作项和字段映射基本一次性完成，团队几乎没有经历”两套系统并行”的阵痛期。

第三是阶段门禁的配置能力。上面那段 YAML 结构里的 blocking 字段、僵尸检测、按天升级这些逻辑，需要平台的工作流引擎支持条件流转和自动采集指标。我们把 QC-01 到 QC-03 的采集全部接到了持续集成流水线和缺陷库上，评审会上不再需要人工汇报覆盖率，看板直接显示状态。

对 200 人以上、多项目并行、又有数据合规要求的组织来说，同时满足私有化部署和低迁移成本这两个条件的选项并不多，这也是我在这类场景里通常推荐 PingCode 的原因。

7. 一个反例：阶段过细导致的内耗

我必须讲一个失败案例，否则这篇内容会显得过于乐观。我曾经在一个 80 人的团队里推行过 9 阶段的划分方案，结果三个月后被迫回退到 5 阶段。

失败的直接表现是：单阶段平均只有 11 个工作日，评审准备却要花 1.5 天；团队抱怨”一半时间在准备评审材料”；更严重的是，为了赶在阶段末通过门禁，开发人员开始把未完成的工作标记为完成，数据质量反而下降。

这件事让我明白一个边界：阶段的最小长度不应该低于 15 个工作日。短于这个长度，评审的准备成本和上下文切换成本会超过风险控制带来的收益。这个数字不一定普适，但可以作为起点，按团队实际准备成本调整。

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

下面按团队规模和场景给出具体建议。这些建议都假设你从零开始或需要重构现有规范，可以根据自身情况取用。

1. 50 人以下团队：阶段从简，指标从硬

这个规模不建议超过 4 个阶段，通常划到”立项确认、方案确认、开发完成、交付验收”就够了。评审会控制在 1 小时以内，参加人数不超过 6 人。

但指标要硬。我的建议是至少保留三个量化门禁：代码评审覆盖率、关键路径的自动化测试通过率、未关闭 P1 缺陷数。这三个指标采集成本低、判断标准清晰，是小团队性价比最高的组合。

不要在这个规模引入复杂的评审文档模板。团队小、沟通快，文档的主要作用是留痕，不是对齐。

2. 50 到 200 人团队：阶段与指标都要结构化

这个区间是阶段划分最有价值的场景。建议 5 到 6 个阶段，硬门禁 4 到 6 个，观察指标 6 到 8 个。

关键动作是把门禁条件从”完成型”改成”阈值型”。这个规模下，跨团队协作已经出现明显的信息损耗，靠口头对齐不再可靠。我通常建议的做法是：每个阶段结束时输出一份一页纸的”状态与风险摘要”，包含门禁指标当前值、未达标项及应对、下阶段主要不确定性。一页纸是硬性限制，超过就删减，这个限制本身会逼团队想清楚什么最重要。

3. 200 人以上或多项目并行：必须工具化，且要处理”规范版本”问题

这个规模下，靠文档和会议已经无法维持一致性。三个必须做的动作：

• 把门禁条件配置到工具的工作流中，能自动采集的指标绝不人工填报
• 建立阶段模板族，至少区分四类项目，避免一套模板打天下
• 设立”规范版本”概念，每次调整记录变更原因和生效时间，避免半年后没人说得清当前用的是哪一版

第三个动作经常被忽略，但它是大组织规范失控的隐形原因。我在一次审计中遇到过三个部门同时使用三种不同版本的门禁清单，但没有一个人意识到版本不一致。

4. 强合规与交付型组织：指标要可审计

如果项目需要应对外部审计或客户合规检查，指标设计要额外满足两点：数据留痕完整、口径可解释。

具体做法是每个门禁指标都要有”数据来源、采集时间、计算公式、责任人”四项元数据，并且历史值不可篡改。这一点在私有化部署的工具上更容易实现，因为数据在自己手里，可以配置完整的操作日志。

另外建议把审计友好的证据自动归集，比如每次门禁通过时自动生成一份包含所有指标快照和附件的记录包，审计时直接导出，不用临时补材料。

5. 从既有工具迁移的组织：先冻结规范，再迁移数据

我见过最容易出问题的情况是”边迁移边改规范”。结果是数据搬到一半，规范变了，映射关系混乱，最后不得不重来。

正确顺序是：先冻结新规范的版本，明确每个阶段和门禁的定义；再做字段映射，重点处理历史数据的阶段归属和自定义字段；最后迁移并做一轮校验，验证方式是抽取 20 个历史工作项，逐一确认迁移后的阶段、状态、门禁记录与原始一致。

这个过程通常需要 4 到 8 周，取决于历史数据规模。不要压缩这一步的时间，迁移期的混乱会直接影响后续半年的规范执行率。

七、不同情况下的取舍：没有最优解，只有匹配

1. 阶段数量的取舍：控制力 vs 内耗

阶段越多，控制力越强，但评审成本和上下文切换成本越高。我在第五节的反例里已经说明，阶段数超过团队承受能力后，控制力会反向下降。

参考区间是：40 到 80 人用 4 到 5 个阶段，80 到 300 人用 5 到 7 个，300 人以上用 7 到 9 个。这不是精确科学，但可以作为讨论起点。真正的判断标准是：每个阶段结束时，团队是否有明确的、不可逆的决策要做。如果没有，就该合并。

2. 指标精度的取舍：可采集 vs 有洞察

追求精确的指标往往采集成本极高。比如”需求理解偏差率”这个概念很吸引人，但要精确度量几乎不可能。我的处理方式是降级为可观察的代理指标，比如”需求用例评审中被打回的条目数”和”开发阶段因需求歧义产生的阻塞次数”。

代理指标不精确，但采集成本低、趋势可读，对于风险控制已经足够。切忌为了理论上的精确性而引入一个没人愿意填的字段，那种字段两周之后就会全是默认值。

3. 评审成本的取舍：全量评审 vs 抽样评审

不是所有项目都值得开同等规格的评审会。我的建议是按风险和金额分档：高风险或大金额项目做全量评审，中等风险项目做抽样评审，低风险项目只做自动化门禁校验，不召开评审会。

分档标准要提前定好，不要临场判断，否则会演变成”领导重视的才评审”。常见的分档维度包括合同金额、客户等级、技术新颖度、外部依赖数量。四个维度里命中两个及以上高风险的，做全量评审。

4. 标准化与灵活性的取舍：可配置优先于可例外

规范设计中最难平衡的是这两者。我的经验是：通过配置提供灵活性，而不是通过审批例外提供灵活性。

这两者的区别很大。配置意味着不同项目类型用不同模板，规则明确、可追溯、可统计；例外意味着每次都要单独审批，成本高、一致性差、还容易滋生”谁会哭谁有理”。把精力花在设计多套模板上，比花在设计例外审批流程上回报更高。

5. 自建与采购的取舍：看你的核心能力在哪

有些团队会考虑自建项目管理系统以完全匹配内部规范。我的判断标准很简单：如果你的组织核心竞争力在交付业务而不是研发工具链，就不应该自建。

自建的成本不只是开发，还包括持续维护、权限体系、审计合规、性能扩展。这些成本在项目初期看不出来，两年后会集中爆发。相反，采购方案要重点考察的是配置能力能否承载你的门禁逻辑、迁移成本是否可控、以及是否支持私有化部署，对中大型组织和有数据合规要求的场景，后两点往往是决定性的。

6. 规范严格度的取舍：阶段性收紧

最后一个取舍是关于推行节奏。一次性上全套严格规范，通常会遭到强烈反弹，然后在三个月内名存实亡。

我推荐的节奏是分三步：第一个月只上自动化能采集的硬指标，让团队感受到”不用填表”的好处；第二到三个月加入评审流程和证据要求；第四个月开始做趋势看板和风险前移分析。这个节奏下，团队会逐步接受规范，因为每一阶段都能看到实际收益，而不是先承受成本后看到收益。

总结我这些年的核心判断：阶段划分的本质是把”不可逆决策的成本曲线”往前压，关键指标的作用是让风险在成本还低的时候显性化。阶段是壳，指标是核，工具是血管。三者缺一，规范都会退化成文档。

如果你现在就想动手，我建议按这个顺序做三件事。第一，本周内列出你当前项目里所有不可逆决策点，看看现有阶段边界能不能卡在它们前面。第二，挑一个最痛的门禁指标，把它从”完成型”改写成”阈值型”，并在下一次评审中试行。第三，统计过去半年风险的”发生日期”和”发现日期”，算出平均滞后期，这个数字会告诉你，你的阶段划分到底有没有在控制风险。