项目进度流程与规范：研发团队进度管理制度设计关键指标

我见过最荒唐的一次进度管理，是某事业部把"每日进度"做成了 17:30 群里的刷屏接龙，每个人报"今天完成 80%"。三个月后项目延期 47 天，复盘会翻出聊天记录，发现最后两周所有人都在报 90%，但真正进入测试的需求只有 6 个。进度数字天天在涨，可交付物一动不动。

这不是执行力问题，是度量口径问题。当"进度"是一个由执行者主观估算、且无人校验的百分比时，它衡量的不是工程状态，而是报送者的心理安全感。我后来参与过十几家研发团队的进度制度重建，结论非常一致：进度管理制度的成败，90% 取决于指标口径设计，而不是工具选型或考核力度。

一、核心结论：进度管理的目标是"提前暴露偏差"，不是"知道进度"

先把结论摆出来，后面所有内容都是围绕这三条展开的。如果你只读一段，读这一段就够了。

1. 结论一：衡量进度制度的唯一有效标准，是偏差暴露的提前量

绝大多数团队对进度管理的期待是"我随时知道现在到哪了"。这个期待本身是错的，因为"现在到哪了"是一个事后描述，它对决策几乎没有价值，你知道了又能怎样？真正有价值的是"按当前流速，交付日期会滑到 11 月 14 日，比承诺晚 9 天"。

所以我评估任何一套进度制度，第一眼看的是偏差提前暴露天数：一个最终延期 10 天的项目，团队是在第 3 天就发现了，还是最后 3 天才发现。前者可以调资源、砍范围、改承诺；后者只能道歉。

在我经手的项目里，一个设计良好的进度制度通常能把偏差暴露提前量从 3-5 天拉到 15-25 天。这个数字比"完成率提升了多少"重要得多，因为提前量直接对应可选的应对手段。

2. 结论二：指标必须分层，平铺的指标清单等于没有指标

我见过太多团队的进度看板，是 20 个指标平铺在一张图上，从需求数、缺陷数、工时、代码提交、到会议次数。这种看板的问题是：它提供了信息，但不提供判断。看板上所有指标都绿的时候你不知道该关注什么，都红的时候你不知道该先修哪个。

有效的结构是分层的：最上面一层是结果（能不能按时交付），中间一层是过程（流速、在制品、周期时间），下面一层是健康度（缺陷逃逸、返工、依赖阻塞），最下面一层是预警（阈值触发的异常信号）。层级决定了下钻顺序，也决定了会议怎么开。

3. 结论三：任何无法自动采集的指标，最终都会退化成表演

这条是我用血换来的。我们曾经设计过一个"需求澄清质量分"，要求负责人在需求评审后填写一个 1-5 分的自评。第一个迭代大家认真填，第二个迭代开始出现大量 5 分，第三个迭代这个字段已经没人看了。

凡是依赖人工主观填写、又会被用于汇报或考核的指标，一定会向对自己有利的方向漂移。这不是道德问题，是激励结构问题。所以我的规则很简单：能自动从工作项状态流转、代码提交、构建记录、审批记录里算出来的指标，才进核心看板；其余的一律放到辅助观察区，不参与任何汇报。

二、真实场景：一个 120 人研发团队的进度失控现场

下面这个案例我全程参与，团队规模 120 人左右，分 7 个开发小组，两个产品线，节奏是双周迭代。他们的进度管理在纸面上非常完整：有迭代计划会、每日站会、双周评审、燃尽图、周报、月度汇报。但项目仍然连续三个季度延期。

1. 现场：三份"看起来都正常"的报表

我第一次进他们的进度会，看到三份报表同时存在，而且互相矛盾。

• 项目经理论坛的项目计划表：显示整体完成 78%，剩余工作 3 周可完成。
• 研发管理平台里的迭代燃尽图：显示当前迭代剩 2 天，剩余故事点还有 40%，明显无法完成。
• 测试负责人手里的缺陷统计：显示待修复缺陷 137 个，其中严重级别 22 个，且新增速度大于修复速度。

三份报表都是真的，但它们描述的是三个不同的现实。项目计划表用人工估算的百分比，燃尽图用故事点，缺陷统计用条目数，三者之间没有任何换算关系。于是每次汇报，大家各取所需：对外讲 78%，对研发讲燃尽图，对质量讲缺陷在收敛。

2. 我拿到的 12 周原始数据

我要求导出过去 12 周的迭代记录、工作项状态流转日志和缺陷数据，做了一次 raw data 复盘。结果比预想的更糟，但问题非常典型。

• 7 个小组的需求颗粒度差异极大，同样是"1 个故事点"，A 组平均 0.8 人天，G 组平均 3.2 人天，相差 4 倍。
• 迭代中途插入的需求占迭代总量的 34%，且这些需求几乎全部没有重新评估对承诺范围的影响。
• 需求状态流转中，"开发中"到"待测试"的平均停留时间是 6.2 天，但队列里积压的"待测试"条目峰值达到 58 个，在制品严重超标。
• 燃尽图的下降曲线有两段明显的"垂直坠落"，都发生在迭代最后一天，是批量关闭工作项造成的。

3. 根因不在人，在口径与流程

复盘时很多人第一反应是"执行力不行"。我不认同。这个团队加班时长在同期是上升的，说明大家都在使劲。真正的问题有三个：

1. 没有统一的度量基准。故事点没有校准，导致跨组数据不可比，任何聚合出来的进度都是伪数据。
2. 没有变更闸门。需求可以任意插入迭代，承诺范围形同虚设，进度基线每周都在移动。
3. 没有在制品限制。所有人都在并行处理多个任务，导致周期时间被拉长，而周期时间才是我真正关心的指标。

这三件事都不是靠加大考核力度能解决的，它们需要的是制度设计：口径定义、变更规则、在制品上限。

4. 一个容易被忽略的观察：进度失真不是均匀分布的

我把 12 周里所有"汇报进度与实际交付不符"的案例做了归因，发现失真来源高度集中。58% 来自需求范围的隐性变更，也就是没人明说"范围变了"，但实际做的事比承诺的多。这个发现直接决定了后面制度设计的重点：与其盯着执行速度，不如先管住范围。

三、拆解常见误区：我踩过和看别人踩过的七个坑

这一节的每一条，我都在真实项目里见过至少三次。它们的共同特征是：看起来是常识，实际是反效果。

1. 误区一：用"完成率"衡量进度

"这个需求完成了 80%"，这句话在工程上几乎无意义。软件开发不是线性施工，一个需求从"接口打通"到"上线可用"，中间可能还有联调、异常分支、数据兼容、性能验证，任何一项都可能推翻前面的 80%。

更严重的是，完成率天生鼓励虚报：报 80% 意味着"快好了，别催我"，报 40% 意味着"可能有问题"。在一个汇报压力大的组织里，完成率会系统性地向高位漂移。

替代方案是二元状态 + 状态停留时长。工作项要么未开始，要么在做，要么做完（已验收）。进度感知来自"每个状态里有多少项、停留了多久"，而不是百分比。

2. 误区二：把燃尽图当作进度真相

燃尽图本身是好工具，但它有一个致命弱点：它是被人工关闭动作驱动的。迭代最后一天批量关闭工作项，曲线就会垂直下坠，看起来"按时完成"。

我在案例团队里抓到过最典型的一次：一个迭代最后一天关闭了 19 个工作项，其中 11 个是在当天上午 10 点后集中关闭的，且这些工作项的实际验收记录分散在之后的三天里。燃尽图显示完美收敛，实际交付晚了一周。

解决办法不是弃用燃尽图，而是给它配一个"验收维度"：迭代结束时的完成定义必须包含验收记录时间，而不是状态字段时间。

3. 误区三：指标只用于考核，不用于诊断

这是最伤团队的坑。一旦某个指标进入考核，人就会优化指标本身而不是背后的目标。真正的做法是：指标先做三个迭代的纯观察，找出基线和异常模式，然后才决定它是否进入考核，而且进入考核的指标数量不超过三个。

4. 误区四：需求颗粒度不统一

前面提到的组间故事点差 4 倍，根源就是颗粒度没统一。颗粒度不统一的直接后果是：所有跨组聚合的进度数据都不可信。

我给团队定过一条硬规则：进入迭代的需求，工作量估算超过 5 人天的必须拆分，小于 0.5 人天的合并。这条规则执行两个迭代后，组间估算标准差从 1.9 下降到 0.7。

5. 误区五：把"工时填报"当进度来源

工时填报衡量的是投入，不是产出。一个团队填了 100% 的工时，可能完成 0 个需求。而且在多数团队里，工时是月末补填的，实时性完全无法支撑进度管理。工时数据可以用于容量规划和成本核算，但不适合做进度主指标。

6. 误区六：缺少年历化基线

很多团队只做迭代级计划，不做年历级基线。结果是每季度都在"重新承诺"，没人记得三个月前说过什么。有效的做法是：在季度层面维护一条承诺基线，任何范围变更都必须体现为基线的显式移动，并记录移动原因。

7. 误区七：规范写给管理者看，不写给执行者用

我读过一份 42 页的进度管理规范，里面全是"应及时""应确保""原则上"这类词。执行者读完不知道自己每天要做什么，管理者读完不知道该检查什么。

好的规范是动作清单 + 判定标准 + 异常处理路径。比如不说"应及时更新状态"，而说"工作项状态变更须在当日 24:00 前完成，跨日未更新且无备注的，次日站会列为异常项，由组长在 24 小时内给出处理结论"。

四、专业判断逻辑：四层指标模型与口径定义

这一节是全文的技术核心。我把前面所有观察收敛成一套可复用的指标结构，你可以直接照着改。

1. 四层结构：从结果到预警的自上而下设计

四层的意义在于让每个指标都有明确的"上层服务对象"，没有上层服务对象的指标直接砍掉。

2. 关键指标的口径定义

口径定义是整套制度里最容易被跳过、也最容易翻车的部分。我要求每个核心指标必须写清四件事：分子、分母、采集时点、排除规则。下面是我们的实际定义。

补充一句经验："排除规则"比"计算公式"更重要。 没有排除规则的口径，执行时一定会出现"这次特殊情况不算"的争论，而每次争论的结果都是往对自己有利的方向走。

3. 防失真设计的三条规则

1. 指标必须有独立数据源。 用于考核的指标，不能来自执行者本人填写的字段。承诺达成率必须由迭代启动时自动快照支撑，而不是事后回忆。
2. 关键指标需要双人确认才生效。 例如需求验收必须由开发与测试分别确认，避免单方面推进状态。
3. 阈值必须可视化。 状态停留超过阈值时，工作项自动标记并进入预警层看板，不依赖任何人主动上报。

4. 一条可落地的指标配置示例

真正的制度不是写在文档里，而是写进系统配置里。下面是我们实际使用的一份指标定义片段，可以直接改成你所在平台的自动化规则。

metrics:

id: commitment_achievement

name: 承诺达成率

layer: north_star

formula: accepted_points_at_end / committed_points_snapshot

snapshot_point: iteration_start

collect_at: iteration_end + 1bd

exclude: compliance_insert_with_approval

target: ">= 0.85"

warn_threshold: "< 0.75"

id: lead_time_p85

name: 需求周期时间分位数

layer: process

formula: percentile(lead_time_days, 0.85)

start_state: ready_for_dev

end_state: accepted

pause_states: [waiting_external]

schedule: "0 2 * * *"

target: "<= 12 days"

id: wip_limit

name: 在制品上限

layer: process

formula: count(items in [in_progress, ready_for_test])

snapshot: daily_0000

target: "<= 2 * team_size / 5"

action_on_exceed: freeze_new_start

注意最后一条 action_on_exceed：在制品超限时冻结新任务启动。这条规则是我们整套制度里最有效的一条，因为它把指标变成了强制动作，而不是一张没人看的图表。

5. 需求从提出到上线的阶段流失

除了流速和周期时间，我还建议重画一张漏斗：需求从提出到上线，每个阶段的流失率是多少。这张图往往能揭示大量隐性浪费。

五、案例与数据观察：某中大型企业基于 PingCode 的进度制度重构

前面那个 120 人团队的重构，工具侧选的是 PingCode。我选择它有三个现实理由，也顺便说明一下选型时我真正在意什么。

1. 背景与约束：为什么关注私有化与迁移能力

这家企业在金融科技领域，有明确的内部合规要求：研发过程数据不得出内网。这一条直接排除了大部分 SaaS 方案，所以第一筛选条件是私有化部署能力。PingCode 支持私有化部署，这一条满足硬约束，团队不需要为合规做额外的数据脱敏设计。

第二个约束是历史资产。他们原来用 Jira 管理了六年、累计十几万个工作项，包含大量自定义字段、工作流和报表。全量重建的成本高到不可接受，所以第二筛选条件是迁移可行性。PingCode 支持 Jira 平滑迁移，包括工作项结构、状态流转和字段映射，官方也提供迁移工具与人工支持，这让我们把迁移评估周期从预估的 8 周压缩到 3 周。

第三个理由是规模匹配。这类平台主要服务中大型企业及 100 人以上组织，而这个团队是 120 人、7 个小组、双周迭代，正好在它设计的目标区间内。相反我见过 15 人的小团队硬上重量级平台，最后死于流程负担，所以规模匹配这件事必须认真对待。

2. 制度落地的四个动作

1. 统一工作项类型与状态机。 把原来各组自定义的状态收敛为 7 个标准状态，过渡期保留映射关系，避免历史数据断裂。
2. 建立迭代启动快照。 迭代启动时自动锁定承诺范围与故事点，作为后续所有达成率计算的唯一基线，这个动作是整套制度的地基。
3. 配置在制品上限与自动冻结规则。 当"开发中 + 待测试"条目超过公式计算的上限时，系统禁止新任务进入开发状态。
4. 搭建四层看板与自动预警。 北极星层每迭代更新，过程层每日刷新，健康度层每周一计算，预警层实时触发并推送到对应负责人。

3. 12 周数据观察

重构不是一次上线就完成的，我们分三个阶段推进：第 1-4 周只统一口径不做任何约束，第 5-8 周启用在制品上限与变更闸门，第 9-12 周接入预警与考核联动。下面是关键指标的变化。

这里我要强调一个容易被误读的点：第 1-4 周我们什么约束都没加，但指标已经改善了一部分（比如周期时间从 24 天降到 22 天）。这不是制度生效，而是霍桑效应，大家知道自己被观察了。真正的效果出现在第 5 周之后，尤其是启用变更闸门和在制品上限之后。所以做效果评估时，一定要把观察期和干预期分开，否则很容易把观察效应误认为制度红利。

4. 我们做错的两件事

案例不能只讲成功，否则没有参考价值。我们犯了两个明显错误。

第一，第 5 周上线在制品上限时，一下子把阈值设成理论最优值。 结果是第一周就触发了 14 次冻结，组长怨声载道，因为很多任务其实已经接近完成，硬停会造成更大浪费。后来我们改成两阶段递减：先设一个宽松值（理论值的 1.5 倍），稳定运行三个迭代后再收紧。这一步调整让我们少了一次几乎发生的制度反弹。

第二，健康度指标过早进入绩效面谈。 第 9 周我们把缺陷逃逸率纳入组长绩效沟通，结果第二个迭代缺陷分级开始出现"降级"现象，原本的严重缺陷被标为一般缺陷。发现后我们立刻把质量指标从个人绩效中撤出，改为团队级观察指标，同时补了一条"缺陷分级由测试负责人独立确认"的规则。

这两件事的教训是一样的：任何指标一旦和个人利益直接挂钩，就会立刻产生对抗性行为，而且对抗方式往往发生在指标的输入环节，而不是数字本身。

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

进度制度没有通用解，团队规模、产品阶段、合规要求不同，重点完全不同。下面按规模给出建议。

1. 30 人以下：只留三个指标

小团队最大的风险是流程负担超过协作收益。这个阶段我建议只保留三个指标：迭代承诺达成率、需求周期时间 P85、阻塞项数量。看板只做一页，每周更新一次，站会上只看阻塞项和超期项。

不要做工时填报，不要做燃尽图以外的多层报表，不要引入需要专职维护的度量体系。保持估算靠人对人沟通，把时间花在交付上。

2. 30-100 人：加入节拍与在制品

跨过 30 人之后，人对人的信息传递开始失效，必须引入节拍。这个阶段的关键增量是在制品上限和统一颗粒度规则。同时开始统一工作项类型与状态机，因为再往后迁移成本会急剧上升。

这个规模段我强烈建议开始做迭代启动快照。它是后面所有环比、同比、达成率计算的地基，缺失它会导致你永远无法回答"我们的承诺纪律是否在改善"。

3. 100-500 人：加入依赖管理与容量规划

到这个规模，瓶颈通常不再是单个团队的效率，而是跨团队的依赖和共享资源争抢。需要新增的指标包括：跨团队依赖按期就绪率、共享资源（架构、DBA、安全评审）排队时长、季度承诺基线偏差。

同时必须建立变更委员会机制。不是所有变更都要审批，但跨迭代、跨团队的变更必须有明确入口和决策记录，否则承诺基线会持续漂移。

4. 500 人以上或多产品线：加入组合层视图

这个阶段管理者关心的不再是某个迭代是否准时，而是投入是否配置在正确的方向上。需要增加组合层指标：产品线交付吞吐、投资分布与战略优先级一致度、跨产品线资源占用。

这一层要特别小心，因为指标一旦做到组合层，离董事会 PPT 只有一步之遥，失真的动力最强。建议组合层指标只做趋势观察，不做周期考核。

5. 强合规与私有化场景的特殊要求

如果你的团队处在金融、医疗、政务等强合规环境，进度制度需要额外处理三件事：数据驻留、审计留痕、权限隔离。数据驻留决定了你只能用私有化部署方案；审计留痕要求所有状态变更保留操作人、时间戳和变更前后值；权限隔离要求跨团队只能看到聚合数据，不能下钻到个人明细。

这三条在选型阶段就要确认清楚，不要等到制度设计完再回头改，那时候返工成本会翻好几倍。

七、取舍：五组必须做的权衡

制度设计的本质是做取舍，不是做加法。下面五组权衡，每一组我都在项目里真实经历过。

1. 精细化 vs 采集成本

指标越细，解释力越强，但采集和维护成本呈非线性上升。我的经验阈值是：度量体系的维护工时不应超过团队总工时的 2%。一个 120 人团队按每周 40 小时算，2% 约等于 96 小时/周，看起来很多，但实际能稳定投入的往往只有 8-16 小时，所以真实约束是"专职人力"，而不是百分比。

2. 实时性 vs 噪声

实时数据看起来很先进，但对进度管理往往是负价值。每天波动的曲线会让管理者做出过度反应，比如某天吞吐量下降就赶紧加人。我建议：预警层实时，过程层每日，健康度层每周，北极星层每迭代。把实时性留给真正需要即时反应的信号。

3. 统一规范 vs 团队自治

统一规范能带来可比性，但会压制团队的局部优化。我的处理方式是"状态机统一、工作流自治"：所有团队必须使用同一套状态定义，但允许各自设计状态之间的流转规则和检查项。这样既保证了跨团队可比，又保留了灵活性。

4. 预测精度 vs 团队信任

这是最微妙的一组。高精度预测通常需要更多数据填报，而填报压力会损害信任。我的判断是：在信任建立之前，宁可预测不准，也不要增加填报负担。 一个粗糙但自动采集的预测，比一个精确但需要人肉维护的预测更有价值，因为前者会持续存在，后者会在两个月内消失。

5. 工具能力 vs 流程纪律

工具能解决"看得见"的问题，解决不了"愿不愿意按规则做"的问题。我见过配置精良的平台最后败给"大家就是不更新状态"。反过来，流程纪律强的团队用一张表格也能管好进度。

正确的顺序是：先定规则和动作，再选工具承载规则。 如果反过来，你会被迫按工具的能力去设计流程，最后设计出一套没人用的流程。

八、30 天落地路线图

如果你准备把上面的内容落地，下面是我实际用过的四周路线，可以直接照抄。

1. 第一周：统一口径，不动流程

1. 导出过去 12 周的历史数据，计算当前基线：承诺达成率、周期时间 P85、在制品峰值、缺陷逃逸率。
2. 收敛工作项类型与状态机，制定映射表，保留历史数据可追溯。
3. 确定 3 个核心指标的口径文档，明确分子、分母、采集时点、排除规则。

这一周的关键是只观察、不约束、不考核。目标是拿到真实基线，而不是立刻改善数字。

2. 第二周：建立快照与看板

1. 启用迭代启动快照机制，锁定承诺范围。
2. 搭建四层看板，先上线预警层和过程层。
3. 制定工作项颗粒度规则（超过 5 人天拆分，小于 0.5 人天合并）。

3. 第三周：引入约束

1. 设置在制品上限，初始阈值取理论值的 1.5 倍。
2. 建立变更闸门：迭代内插入需求必须经变更委员会确认，并显式更新基线。
3. 配置阻塞项自动预警：状态停留超过阈值自动标记并推送。

4. 第四周：复盘与微调

1. 对比 4 周数据与基线，识别改善最大的和没有变化的指标。
2. 检查是否出现指标操纵迹象（批量关闭、缺陷降级、状态跳跃）。
3. 决定哪些指标进入长期观察，哪些暂缓。

5. 第 2-3 个月：收紧与固化

1. 在制品上限向理论值收敛，每次调整后观察两个迭代再决定下一步。
2. 把偏差提前暴露天数作为制度健康度的核心指标，每月复盘。
3. 把规范从"文档"转成"系统配置 + 自动化规则"，减少对人的记忆依赖。

九、常见问题

1. 团队反感被度量，怎么办？

反感的根源通常不是度量本身，而是度量被用于追责。我的处理方式是两个动作：第一，前三个迭代的指标只做观察，任何人不得因指标结果被问责；第二，把指标定义和计算逻辑完全公开，所有人可以自己算出同样的数字。透明是消除反感最有效的办法。

另外要区分"度量团队"和"度量个人"。团队级指标用于改进流程，个人级指标用于绩效，两者混用必然出问题。我在案例中把质量指标从个人绩效中撤出，就是基于这个原则。

2. 指标数据不准确怎么办？

先排查是口径问题还是行为问题。口径问题表现为系统性偏差（所有团队都偏低），行为问题表现为局部异常（某个团队明显偏高）。口径问题改定义，行为问题改激励。

一个实用的判断方法：如果某个指标的异常总发生在结算时点附近（迭代最后一天、月末、季末），那大概率是行为问题，需要在输入环节加校验规则，而不是在输出环节加审核。

3. 小团队需要做这么复杂的制度吗？

不需要。30 人以下只保留三个指标，看板一页，每周更新一次。制度的复杂度应当与协作复杂度匹配，而不是与管理者焦虑程度匹配。我见过太多小团队照搬大厂体系，最后把时间都花在了维护度量上。

4. 故事点和人天哪个更适合做进度基准？

两者都可用于内部相对比较，都不可用于跨团队绝对换算。我的建议是：用故事点做团队内部规划和流速计算，用人天或理想天数做跨团队产能规划，并且永远不要在同一次汇报里混用两者。

如果你所在的团队估算能力还很弱，可以先从"条目数 + 颗粒度规则"开始，比起强行引入故事点更实用。关键是颗粒度先统一，否则任何单位都会被玩坏。

5. 迭代中途插入需求，怎么处理才不破坏制度？

不要一刀切禁止，那会让业务方绕过流程直接找研发。正确的做法是建立显式的交换机制：插入一个新需求，必须移除或推迟一个同等规模的原承诺条目，并记录在迭代变更日志里。这条规则的价值在于把隐性的范围膨胀变成了显性的取舍决策。

在案例团队中，实施这条规则后迭代内插入需求占比从 34% 降到 11%，而业务方满意度没有下降，因为他们获得了明确的取舍权，而不是模糊的"我们再挤一挤"。

6. 私有化部署和 SaaS 怎么选？

先看合规约束，再看规模。如果数据不能出内网，私有化部署是唯一选项，此时要重点考察迁移工具的成熟度和历史数据兼容性。如果没有硬性合规约束，就看团队规模和 IT 运维能力，私有化带来的运维成本在 100 人以下团队往往难以摊薄。

无论选哪种，我都建议在选型阶段做一次真实数据迁移演练，用你们自己最复杂的那批工作项跑一遍，而不是看厂商的标准演示。演练暴露的问题，比任何规格说明都有参考价值。

最后：进度制度的成败，取决于你是否敢砍指标

回到开头那个每天在群里刷"完成 80%"的团队。他们后来重做的第一件事，不是加指标，而是删指标，从 21 个度量项砍到 3 个核心指标加 1 个预警清单。三个月后，偏差提前暴露天数从 4 天提升到 19 天，周例会从 150 分钟压到 55 分钟。

我的核心观点是：进度管理不是"管得更细"，而是用最少的指标抓住最关键的三个信号，承诺纪律、流动效率、偏差提前量。其余所有指标，要么服务于这三个，要么砍掉。

给你的下一步建议很具体：本周先做一件事，把过去 12 周的工作项数据导出，算出承诺达成率、需求周期时间 P85 和在制品峰值三个数字。不用做任何改动，先看清自己站在哪里。这三个数字会告诉你，你的团队真正的问题是在范围控制、流动效率，还是在承诺管理上。

等你有了基线，再按第八节的四周路线推进。记住那条最有效的规则：在制品超限时冻结新任务启动。它是整套制度里唯一一条把指标变成强制动作的规则，也是我在多个项目中验证过、投产比最高的一条。