阶段负责人落地方案：项目负责人开展项目阶段的数据分析案例解析

2023 年我参与一家 320 人规模研发组织的效能治理，第一个被推翻的东西不是流程，而是那份做得很漂亮的阶段周报。周报里六个阶段的进度条全是绿色，缺陷趋势线一路向下，可项目在集成验证阶段已经实际延期了 41 天。项目负责人当时说了一句话：”数据没骗人，是我们问错了问题。”这句话成了我后来做所有阶段数据分析的起点。

阶段负责人落地方案真正的难点，从来不是”怎么把数据画出来”，而是”这个阶段的负责人看到这个数，明天能做哪一件具体的事”。如果读完一份阶段数据分析报告，负责人只能说出”情况还行”或者”压力有点大”，那这份报告的成本就是纯浪费，它消耗了三个人的两天工时，换来了一句无法执行的感受。

下面这套方法基于我 2023，2024 年参与的 3 家企业、11 个产品线的治理记录，数据经过脱敏与归一化处理，属于样本推演与经验观察，不是公开统计。我会把它拆成核心结论、真实场景、常见误区、判断逻辑、落地案例、行动建议和取舍七层，每一层都尽量落到能直接抄走用的程度。

一、核心结论：阶段数据分析要解决的是”决策时点”，不是”数据可视”

先把结论放在前面。如果你的团队现在正准备给阶段负责人做一套数据看板，下面五条判断可以帮你省掉至少两轮返工。

1. 阶段负责人真正要管的是”可逆成本”，不是进度百分比

进度百分比是一个滞后到几乎无用的数字。当完成度从 70% 掉到 60%，损害已经发生了。阶段负责人能改变的是”这个阶段的产出有多少会在下个阶段被推翻”。我在案例里把这个叫可逆成本：需求返工、方案推翻、测试用例重写、环境重建，这些成本在阶段内是可以被压住的，跨过阶段门之后就基本锁死了。

所以我给阶段负责人设计的第一指标通常不是完成度，而是阶段内返工流入率，本阶段内因为上游输入质量问题而触发返工的工作项占比。它比缺陷数更早、比进度更真。

2. 指标必须通过”可控性检验”才能放进负责人的看板

可控性检验只有一句话：如果这个指标变坏，阶段负责人有没有一个具体的动作能让它变好？答不上来的指标，放进去只会制造焦虑和甩锅空间。

典型的反例是”整体缺陷逃逸率”。这个数字受需求阶段质量、架构决策、测试覆盖、发布节奏共同影响，阶段负责人对它几乎没有控制力。把它挂在阶段负责人头上，结果通常是他开始优化报告口径，而不是优化质量。

3. 阶段门判据要用”三线制”，而不是单点阈值

单点阈值的问题是：它不是太严就是太松，而且一旦定了就很难改。我实际用的是三线制，目标线（希望达到的水平）、基线线（历史正常波动区间）、离群线（必须立刻介入的临界点）。三线之间留出的区间，就是允许团队正常波动的空间。

4. 指标数量控制在 5±2，并且必须配”触发-响应”规则

我在第二家企业接手时，他们给阶段负责人配了 17 个指标。三个月后我逐个问负责人：”这 17 个里，哪个指标变化会让你改变当天的工作安排？”答案是两个。剩下 15 个指标的唯一作用是让报告看起来专业。

每一个留下的指标，都要有一行明确的触发-响应规则：超过什么阈值、谁在多久内、做什么动作。没有这行规则，指标就只是装饰。

5. 数据采集方式决定了数据可信度的上限

这是最容易被忽略、却最致命的一条。如果阶段数据依赖人工填表，那它的失真率通常比你想象的高一个数量级。我在样本中做过统计：人工填表的阶段状态数据，与实际工作项流转变动的偏差率中位数在 20% 以上，而平台自动采集的偏差率能压到 5% 以内。

二、背景和真实场景：一个全程绿灯的延期项目

1. 我遇到的真实场景

回到开头那个项目。它是一条软硬件混合的产品线，节奏是六周一迭代、三个迭代一个发布，阶段划分为：需求确认、方案设计、开发实现、集成验证、发布准备、量产交付。每个阶段有一位负责人，多数是资深工程师兼任。

项目在集成验证阶段的第 9 天，我拉了一次阶段复盘。现场看到的原始数据是：需求完成度 94%、缺陷关闭率 88%、迭代燃尽图正常收敛。所有数字都指向”健康”。

但当我把工作项按状态流转时间重新排一遍，事情就变了。有 23 个需求在”开发实现”阶段被回退到”方案设计”，平均每个回退消耗 1.6 人天。这些回退动作在燃尽图里是看不见的，因为燃尽图只计算剩余工作量，不计算重复工作量。

换句话说，项目不是延期了 41 天，而是从方案设计阶段就开始持续返工，只是这些返工被”完成度”这个口径吃掉了。

2. 为什么”阶段负责人”这个角色在 100 人以上组织才真正成立

我观察到一个比较清晰的规律：50 人以下的团队，项目负责人可以直接看住每一个工作项，阶段负责人这个中间层是冗余的，加了反而多一层汇报。

但当组织到 100 人以上、同时跑 3 条以上产品线时，项目负责人的注意力会被撕成碎片。他既要在需求层面和业务方对齐，又要在实现层面判断技术风险，还要处理跨团队资源冲突。这时候必须有人替他”守门”，这个人就是阶段负责人。

这也是为什么在选型时，我倾向于把平台能力作为重要约束条件。中大型企业及 100 人以上组织的项目管理需求，和十几人小团队完全不是一回事：多产品线并行、跨部门资源池、阶段门审批、私有化部署、历史数据迁移，这些都是硬性门槛。我后来在几个项目里用的是 PingCode，主要原因是它定位就是服务中大型企业及 100 人以上组织，支持私有化部署，同时支持 Jira 平滑迁移，在国产替代场景里是比较稳妥的选择。

3. 我见过的三种”阶段制”，它们的取数方式完全不同

第一种是时间盒阶段制：阶段按周划分，比如每 6 周一个阶段。这种阶段的数据分析重点是节奏稳定性，核心指标是计划偏差率和阶段内完成率波动。

第二种是交付物阶段制：阶段按产出物划分，比如”架构评审通过”才算离开方案设计阶段。这种阶段的数据分析重点是准入准出，核心指标是阶段门评审一次通过率和退回率。

第三种是混合阶段制：时间盒到期时如果交付物不达标，阶段自动顺延。这是我在制造业和硬件团队里见得最多的，也是最难做数据分析的，因为它同时存在”时间”和”质量”两个维度的判据，很容易出现两边都不算数的灰色状态。

这里有个关键判断：三种阶段制的数据口径不能通用。用时间盒阶段制的”完成率”去衡量交付物阶段制的团队，会系统性低估他们的真实进度，因为交付物阶段制的完成曲线本来就是阶梯状的。

4. 数据从哪里来：状态机才是真正的源头

阶段数据分析的质量上限，取决于工作项状态机的定义质量。我见过太多团队，指标算不准不是因为公式错，而是因为”开发中”这个状态在不同团队里含义不同，有的团队一接到任务就置为开发中，有的团队写完第一行代码才置为开发中。

这两个团队放在同一张报表里比较”阶段停留时长”，结论必然是错的。所以做阶段数据分析的第一步，不是拉数据，而是把状态机定义访谈一遍，画出来，对齐它。

三、拆解常见误区：六个让你白干三个月的坑

1. 误区一：把阶段数据分析做成”周报可视化”

这是最普遍的一个。表现是：数据每周都出，格式很规范，但从来没有人因为看了它而改变计划。它的本质问题是把”汇报”当成了”决策”。

判断方法很简单：随便挑一期阶段报告，问负责人”这一期里哪个数字让你做了什么决定”。如果答案是”没有”，那这套报表就是零价值。

2. 误区二：用全周期指标考核阶段负责人

全周期指标包括缺陷逃逸率、整体交付周期、客户满意度、总返工率。这些指标对项目负责人有意义，对阶段负责人基本无意义，因为它们的因果链跨过了三到四个阶段。

我见过一个团队把”发布后 30 天缺陷数”算进阶段负责人的季度评价，结果是在集成验证阶段出现了大量”未复现”的缺陷标记。数据好看了，问题只是被推迟到了下一轮。

3. 误区三：只看均值，不看分布

阶段负责人最需要知道的信息，往往藏在长尾里。我统计过一个团队的阶段停留时长：均值 4.2 天，看起来很正常。但把分布画出来，会发现有 12% 的工作项停留超过 15 天，而这 12% 消耗了 47% 的等待时间。

均值掩盖的是阻塞点，而阻塞点才是阶段负责人真正要处理的东西。

4. 误区四：指标堆砌，用”全面”掩盖”没有重点”

17 个指标和 0 个指标的效果是一样的，因为人脑在同时追踪超过 7 个变量时会自动放弃区分优先级。更糟的是，指标堆砌会让阶段负责人形成”挑好看的指标说”的习惯，这是一种组织性的数据失真。

我的建议是把指标分成三层：常看 3 个、触发时看 3 个、复盘时看 5 个。日常看板只放常看的三个，其余按需展开。

5. 误区五：忽略采集成本，用人工填表换数据

人工填表看起来省了工具改造的功夫，实际成本极高。我在一家企业做过对比测试：同一个阶段的同一批工作项，让团队用 Excel 每日填报，同时从项目管理平台自动取数。三个月后对比，人工填报的状态与实际流转不一致的比例中位数达到了 23%。

更关键的是，人工填表还在消耗工程师的时间。我算过一笔账：一个 40 人的研发团队，如果每人每天花 4 分钟填报状态，一年就是 40 × 4 × 250 ÷ 60 ≈ 667 小时，接近 83 个人天。这笔钱足够把平台侧的自动采集做两遍。

6. 误区六：把数据当成问责工具，而不是决策工具

这一条不是技术问题，是组织问题，但它对数据质量的影响比其他五条加起来都大。一旦阶段负责人意识到”这个数据是要拿来考核我的”，他的第一反应一定是优化数据而不是优化现状。

我在做治理时会明确宣布一条规则：阶段数据只用于触发动作，不用于个人评价，至少在前两个季度是这样。等数据质量稳定、信任建立起来之后，再考虑纳入评价体系，而且要选择那些难以被人为操纵的指标。

四、专业判断逻辑：可控性 × 及时性 × 抗噪性

1. 第一步：画出阶段负责人的控制域

我会让阶段负责人自己做一件事：列出他在这个阶段能直接决定的十件事。通常包括：任务优先级调整、评审排期、技术方案取舍、阻塞升级、人员分工微调、返工判定、阶段门是否放行。

然后把候选指标逐个对照这份清单。一个指标如果对应的动作不在清单上，它就不属于这个阶段负责人的看板，最多放进项目级报表。

2. 第二步：区分领先指标与滞后指标

阶段负责人最容易看到的都是滞后指标：缺陷数、延期天数、完成度。这些数字出现异常时，问题已经发生了。真正有用的是领先指标。

我常用的三个领先指标是：需求变更到达率（本阶段内新增或修改需求的数量占比）、评审一次通过率（首次评审即通过的工作项比例）、阻塞升级及时率（阻塞发生后 24 小时内完成升级的比例）。这三个数字的变化，通常领先于进度和质量的恶化两到三周。

3. 第三步：建立反事实基线

没有基线，”这个阶段返工率 12%” 这句话是没有任何意义的。你既不知道它是好是坏，也不知道该不该介入。

基线通常有两种来源。一种是历史基线，取过去 3，5 个同类阶段的指标中位数和四分位区间。另一种是同期基线，取当前并行进行的其他产品线的同一阶段指标做横向对比。

我的建议是优先用历史基线，用同期基线做交叉验证。因为不同产品线的复杂度差异很大，直接横向比较容易得出错误结论，但如果你发现所有产品线的同一指标同时恶化，那基本可以断定是流程或资源层面的系统性问题。

4. 第四步：设置三线制与触发-响应表

三线制的具体做法：以返工流入率为例，历史中位数是 9%，四分位区间是 6%，13%，那么目标线可以设为 7%，基线区间是 6%，13%，离群线设为 18%。

然后为每条线配置动作。下面是我在项目里实际使用的一份触发-响应配置，从平台的规则引擎或者自建定时任务里都能实现。

阶段门指标配置（示例）
阶段: 集成验证

指标: 阶段内返工流入率

三线定义:

目标线: 7%

基线区间: [6%, 13%]

离群线: 18%

触发-响应规则:

触发条件: 连续 2 个统计周期 > 13%

响应动作: 阶段负责人在 24 小时内组织一次 30 分钟返工来源复盘

责任人: 阶段负责人

关闭条件: 下一周期回落至 13% 以下

触发条件: 单周期 > 18%

响应动作: 升级至项目负责人，冻结本阶段新增需求接收，直到存量返工清零

责任人: 项目负责人

关闭条件: 返工工作量下降 50% 以上

触发条件: 连续 3 个周期
响应动作: 检查口径是否失效或统计范围是否被缩小

责任人: 效能分析师

关闭条件: 口径校准确认书

统计口径:

统计周期: 周

分子: 本周期内被判定为返工的工作项预估工时

分母: 本周期内所有处于进行中状态的工作项预估工时总和

排除项: 需求方主动撤回（非质量原因）

这份配置里有一个容易被忽略的设计：我特意加了”连续 3 个周期低于 6%”的触发规则。因为指标长期表现过好，往往不是团队变强了，而是口径失效了或者统计范围被悄悄缩小了。这一条规则救过我两次。

5. 第五步：小样本下的指标替换规则

这是我认为最被低估的一个专业判断。阶段负责人面对的数据样本通常很小：一个 6 周的阶段，可能只有 15，30 个需求、40，80 个缺陷。在这种样本量下，比率类指标的波动会大到没有解释力。

我做过一个模拟：真实返工率 12%，样本量 20 时，单周期观测值的 90% 置信区间大约是 3%，30%。也就是说，一个正常的阶段，观测到的返工率有可能在 3% 到 30% 之间随意跳动，而负责人对着这个数字开会讨论，讨论的主要是噪声。

所以在小样本阶段，我的做法是用绝对量和分布替代比率。不说”返工率 18%”，而说”本周有 9 个工作项被判定返工，其中 6 个来自方案设计阶段的接口定义”。后者信息量更大，也更容易直接对应到行动。

五、案例解析：一个六阶段软硬件项目的指标体系落地过程

1. 项目背景与阶段划分

这家企业约 320 人，3 条产品线并行，研发人员占比约 65%。产品形态是软硬件一体，硬件部分有长交期物料和样机环节，软件部分有云侧服务、边缘固件和移动端。

项目按六个阶段推进：需求确认、方案设计、开发实现、集成验证、发布准备、量产交付。每个阶段设一位阶段负责人，由该领域最资深的工程师或技术骨干兼任，占用其约 20% 的工作时间。

2. 第一版指标体系为什么失败

第一版指标体系是自上而下推的，项目负责人带着管理层关心的指标下来，一共 14 个：整体进度偏差、需求完成率、缺陷密度、缺陷逃逸率、测试用例执行率、代码评审覆盖率、CI 通过率、阶段停留时长、资源利用率等。

运行三个月后，我做了两件事：一是统计这 14 个指标有多少次触发了实际动作，二是访谈六位阶段负责人他们实际看了哪几个。结果是有 3 个指标触发过动作，负责人平均实际关注 2.4 个。

失败原因有三条：指标不可控（缺陷逃逸率、资源利用率）、指标滞后（进度偏差、需求完成率）、没有触发规则（14 个指标全部只有定义没有响应动作）。

3. 第二版：阶段门数据契约

第二版我把结构改了，从”列指标”改成”签契约”。每个阶段一份契约，包含四部分：入口条件、过程指标、出口判据、触发响应。契约由阶段负责人、上游阶段负责人、项目负责人三方签字确认。

这张表看起来简单，但它解决了原来最大的问题：每个指标都挂在具体的阶段动作上，而且出口判据是阶段门的放行条件，不放行就必须显式说明理由。这一点让阶段负责人从”汇报者”变成了”守门人”。

4. 平台侧怎么落地：以 PingCode 为例

指标设计完之后，下一个问题是数据从哪里自动来。这个项目里我最终选的是 PingCode，理由有三个层面，我按当时真实的评估顺序说。

第一个层面是组织匹配度。PingCode 主要服务中大型企业及 100 人以上组织，这个项目的规模和多产品线并行的结构正好落在它的设计范围内。我评估过的一些轻量工具在这个规模下会出现权限模型不够细、跨产品线视图混乱的问题。

第二个层面是部署与合规。这家企业有硬件业务，部分研发数据不能出内网，所以私有化部署是硬性要求。PingCode 支持私有化部署，这一点直接决定了它进入候选池。

第三个层面是迁移成本。他们原本用的是一套海外项目管理工具，积累了三年的工作项历史数据，这些数据是建立历史基线的前提，不能丢。PingCode 支持 Jira 平滑迁移，字段映射和工作项类型映射有现成的路径，实际迁移时我们用了两周完成主体数据搬迁，第三周做校准。这也是我把它作为国产替代方案首选的原因之一。

具体到阶段数据分析的落地，我做了四件事：

1. 把阶段建模成工作项类型。让每个阶段本身是一个可追踪的对象，而不是靠人工在 Excel 里维护阶段表。这样阶段停留时长、阶段进出时间点都是自动产生的。
2. 统一状态机。把六阶段的 32 个状态收敛成 14 个，并写清每个状态的进入条件和退出条件，作为团队规范文档固化下来。
3. 加三个自定义字段。分别是”返工判定”（枚举：非返工/上游输入返工/技术方案返工/环境返工）、”阻塞级别”、”阻塞升级时间”。这三个字段是计算领先指标的基础。
4. 配置阶段门报表。用平台自带的度量报表能力，按阶段维度输出出口判据的达成情况，并在未达成时用醒目状态标记。

当然也有需要妥协的地方。这套平台的报表在标准场景下开箱即用，但如果你的阶段门判据里有很特殊的复合逻辑（比如”P0 缺陷清零且回归通过率 ≥ 98% 且回滚演练通过”三条件与逻辑），还是需要走 API 取数自己算。我的做法是用平台负责数据采集和基础指标，用外部脚本负责复合判据，两边通过 API 对接。

阶段门复合判据计算（伪代码示例）
输入: 平台 API 返回的阶段指标快照

def stage_gate_check(stage, metrics):

rules = {

"集成验证": [

("缺陷重开率", "("P0P1缺陷数", "==", 0),

("环境可用率", ">=", 0.95),

],

"发布准备": [

("回归通过率", ">=", 0.98),

("回滚演练", "==", "passed"),

],

}

results = []

for name, op, threshold in rules.get(stage, []):

actual = metrics.get(name)

passed = compare(actual, op, threshold)

results.append({

"指标": name,

"实际值": actual,

"判据": f"{op} {threshold}",

"是否通过": passed,

})

return {

"阶段": stage,

"可放行": all(r["是否通过"] for r in results),

"明细": results,

}

5. 六个月后的数据变化

我们按六个月为观察窗口，对比治理前六个月和治理后六个月的关键指标。需要说明的是，这期间团队规模和产品线数量基本稳定，所以变化可以较大程度归因到指标体系与流程改造。

这里我想强调一点：这些数字里，我认为最可信、也最有价值的是”阶段延期识别提前量”。它从 2.1 天提升到 9.4 天，意味着阶段负责人平均提前将近一周半就知道这个阶段要出问题。对于一个 6 周的阶段来说，一周半的可行动窗口，足以做出实质性的调整，而不是只能在复盘会上解释。

6. 一个具体的阶段门判定实例

第 4 个月的第 3 周，集成验证阶段的返工流入率触发了离群线。当期数值是 21%，超过 18% 的离群线，也超过了 13% 的基线上限。系统的触发规则自动通知了阶段负责人。

负责人按响应规则在 24 小时内组织了复盘，结果发现 21% 的返工里有 3.4 个百分点来自同一个源头：边缘固件与云侧服务的接口协议在方案设计阶段定义了两次，两次定义不一致，导致集成阶段有 7 个联调任务需要重做。

更有意思的是后续处理。按出口判据，这个阶段不允许放行。项目负责人没有选择强行放行，而是做了一次资源调配：从另一条产品线借调两名熟悉该协议栈的工程师，用两周时间把接口定义重新对齐并补齐契约测试。最终这个阶段延期了 6 天，但避免了在发布准备阶段或者量产交付阶段暴露问题。

按这家企业的历史数据，同类接口问题如果在量产交付阶段才暴露，平均修复成本是集成验证阶段的 5，8 倍。所以这次”延期 6 天”实际上是一次成本节省。

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

1. 情况一：50 人以下、单产品线

这个阶段不要急着搭阶段负责人体系。我见过太多小团队照搬大厂做法，结果是把本来靠沟通就能解决的事变成了流程。

建议只做两件事：一是把工作项状态机统一（哪怕只有 5 个状态），二是每周看一次返工来源清单，用绝对量而非比率。阶段负责人这个角色可以由项目负责人兼任，不必单独设。

2. 情况二：100，500 人、多产品线并行

这是阶段负责人体系收益最大的区间。建议完整落地阶段门数据契约，指标控制在每阶段 3 个过程指标 + 3 项出口判据，并且必须配触发-响应规则。

平台侧要确保能自动采集状态流转数据，人工填表在这个规模下会成为瓶颈。同时建议做一次跨产品线的基线校准，把不同产品线的同一指标拉到可比口径。

3. 情况三：500 人以上、有强合规或数据不出内网要求

这个规模的第一个约束是部署形态。私有化部署几乎是必选项，同时要评估平台的权限模型是否能做到字段级和产品线级隔离。

第二个约束是历史数据迁移。历史基线是做阶段分析的前提，如果迁移过程中字段映射丢失，等于基线要重新积累一到两个季度。所以在选型阶段就要把迁移能力作为核心评估项，而不是实施阶段才考虑。这也是我在几个项目里选择 PingCode 的实际原因之一，它支持私有化部署，支持 Jira 平滑迁移，在国产替代路径上切换成本相对可控。

4. 情况四：刚完成工具迁移

迁移后的前三个月不要急于做指标分析，先做三件事：对齐状态机、补齐历史字段映射、跑通一次完整的阶段数据链路。这三个月的数据建议标注为”校准期”，不纳入考核。

我的经验是，迁移后第一季度的指标波动中，有相当一部分来自数据本身的变化而非真实绩效变化。如果不标注校准期，很可能得出错误结论。

5. 情况五：数据基础差、状态机混乱

这种情况下不要从指标体系入手，要从状态机治理入手。具体做法是：选一条产品线做试点，用一个阶段的时间把状态定义梳理清楚并强制执行，然后回看这段时间的数据，验证口径是否可信。

如果试点数据可信度能到 80% 以上，再推广到其他产品线。跳过这一步直接做指标，只会得到一堆看起来专业但没人信的报表。

七、不同情况下的取舍

阶段数据分析落地过程中，几乎每一个选择都是取舍，没有两全方案。下面这张表是我在项目里实际做过的五个关键取舍，以及我的判断依据。

这里我想单独展开讲第一个取舍，因为它最容易被算错。很多团队在评估”要不要做自动采集”时，只算了工具成本，没算人工成本和数据失真的隐性成本。

把三笔账放在一起：40 人团队人工填报年化约 83 人天；人工数据失真导致的一次误判，在这个项目里造成的返工成本约 48 人天（就是那批接口定义不一致的联调任务）；自动采集的一次性治理成本约 25 人天。这样算下来，方向其实很清楚。

第二个取舍我也有个具体判断：状态机统一程度和团队规模呈倒 U 型关系。太小的时候不需要统一，因为沟通成本低；太大的时候统一收益也下降，因为跨域差异过大，强行统一会让状态定义变得极其抽象而无人使用。真正需要严格统一的是 100，500 人这个区间。

八、总结与下一步

回过头看这 11 个产品线的治理记录，我对阶段负责人数据分析最大的一个认知变化是：它不是数据工程问题，是权责设计问题。

一个阶段负责人能不能靠数据改善结果，取决于三件事有没有同时成立：他能不能改变结果（控制域）、数据能不能提前告诉他（领先指标）、看到数据之后有没有约定好的动作（触发-响应）。三件事缺一件，这套体系就会退化成又一份没人看的周报。

另一个反常识的结论是：阶段数据分析的收益主要体现在”返工成本”和”识别提前量”上，而不是在”进度更准”上。进度准确度提升只是一个副产品。如果一套体系只能让你的进度报告更准，不能减少返工，那它的价值是有限的。

如果你准备在自己的团队里落地，我建议按下面的顺序走，每一步都留出验证时间：

1. 第 1，2 周：梳理状态机。选一条产品线，把工作项状态、进入条件、退出条件写清楚，形成一份不超过三页的文档，并在项目管理平台里配置好。
2. 第 3，4 周：识别控制域。和每位阶段负责人做一次 45 分钟的访谈，让他列出本阶段能直接决定的动作清单，据此筛选候选指标。
3. 第 5，6 周：建立基线。用历史数据算出候选指标的中位数和四分位区间，样本量不足 50 的指标暂时改用绝对量口径。
4. 第 7，8 周：写触发-响应表。每个指标配置至少一条触发规则和一个明确动作，明确责任人和关闭条件。注意加上”指标异常偏优”的检查规则。
5. 第 3 个月：试运行并校准。这个月的数据不用于评价任何人，只用于验证口径和规则是否合理，每周做一次规则微调。
6. 第 4，6 个月：扩展与固化。试点有效后推广到其他产品线，同时把规则配置固化到平台侧，减少人工维护。

最后给一个可以立刻执行的判断标准。当你做完这套体系之后，去找一位阶段负责人，问他：”如果下周一这个指标变成红色，你会做什么？”如果他能在十秒内说出一个具体动作、一个时间点和一个人名，那这套阶段负责人落地方案就是成立的。如果他说”我再看看”，那说明指标还没选对，回去重新做可控性检验。