完成率怎么做？产品经理数据分析：进度管理从0到1

上个季度我陪一家 280 人的 SaaS 公司做迭代复盘，8 个研发小组里有 6 个的迭代完成率长期稳定在 90% 以上，但同一批迭代对应的功能，平均上线时间比计划晚了 11 天。这两个数字同时为真，只能说明一件事：他们的完成率测的不是进度，是团队的心理安全感。我把这 6 个组的原始工作项拉出来按需求条目重算，完成率立刻掉到 47%-63% 区间。

完成率是产品经理和研发管理者最常用的进度指标，也是被误用最严重的指标。它看起来只是一个除法，但分子是什么、分母什么时候冻结、谁来判定“完成”，这三个问题里任何一个没定义清楚，这个数字就会从“导航仪”变成“安慰剂”。

这篇文章我把过去几年在不同规模团队里做进度度量的完整过程写出来：从口径选择、状态机约束、DoD 校验，到迁移期的历史数据对齐，再到怎么给完成率配一条置信区间，让它真正能用于判断“要不要砍范围、要不要加人、要不要推迟发布”。

一、核心结论：完成率是“剩余不确定性”的度量，不是“已完成工作量”的度量

先把结论放在前面。完成率这个词本身有误导性，它让人以为在看“做了多少”，但一个对决策有用的完成率，回答的应该是“还剩多少不确定”。这两件事在数值上可能差 30 个百分点以上。

我做过一个简单测试：同一个迭代，同一批工作项，只换统计口径，完成率可以呈现出四种完全不同的结果。数据来自我跟踪过的一个 10 人 Scrum 组，迭代周期两周，迭代结束当天的快照如下。

同一批事实，82% 和 47% 的差距，全部来自口径选择。所以当我看到有人拿完成率做跨团队排名时，我第一反应是问：分子是什么？

1. 完成率的最大信息量区间在 40%-75%

完成率接近 0% 时，信息量趋近于零，它只说明迭代刚开始，任何团队都是这个值。完成率接近 100% 时，信息量同样趋近于零，它只说明迭代结束了，而“结束”这个事实你从日历上就能知道。

真正有决策价值的是中间区间。在这个区间里，完成率的斜率（每天推进多少）和曲率（斜率在变大还是变小）才能告诉你，按当前节奏迭代结束时大概会落在哪，以及现在做干预还来不来得及。

2. 分母冻结是完成率可比的唯一前提

我见过最常见的错误是：迭代中期加了一个需求，团队顺手把分母加上了，然后完成率从 65% 掉到 55%，所有人以为进度变慢了。实际上什么都没变慢，只是度量方式变了。

正确做法是：迭代基线一旦冻结，中途新增的工作项必须单列，不能并入原分母。它要么进入下一个迭代，要么以“范围变更”的形式单独披露。这样完成率才能回答“原计划完成得怎么样”，而不是回答“在不知道变了几次计划的条件下完成了多少”。

3. 完成率必须带“完成定义”才有意义

“完成”这个词在不同团队里可以指：代码提交完、功能自测通过、测试环境验证通过、产品验收通过、灰度上线、全量上线。这六个状态之间的距离可能有 5 到 15 天。

如果完成率的分子是“代码提交完”，而团队以为它是“产品验收通过”，那么这个指标不是在骗别人，是在骗自己。我在第四章会把这个问题拆成四层结构来讲。

4. 判断一个完成率能不能用，问三个问题

1. 分子包含哪些状态？这些状态是否都通过了统一的质量校验？
2. 分母在第几天冻结？冻结之后有没有发生过加项？加项怎么披露？
3. 这个数字能不能算出一条斜率和一条置信区间？如果只能给一个点值，它就不具备预测能力。

三个问题里任何一个答不上来，这个完成率就只能用于“让周报好看一点”，不能用于任何资源决策。

5. 完成率的“真实形态”是阶梯，不是斜线

还有一个被普遍忽略的物理事实：完成率在时间轴上不是均匀上升的直线，而是阶梯。工作项是离散的，一个任务要么完成要么没完成，中间没有 0.4 个任务。所以你会看到完成率在几天里纹丝不动，然后突然跳一大格。

这个形态直接推出一个实操结论：不要在第 3 天用完成率外推交付日期。那时候的斜率几乎全是噪声。要等到完成率越过 30% 之后再开始外推，并用后几天的日增量分布而不是平均值来算。

二、背景与真实场景：我见过的四种完成率口径

把口径问题讲透，需要理解每种口径背后的激励结构。因为团队会朝着度量方式的方向优化，这不是道德问题，是系统问题。

1. 任务数口径：最常用，也最容易失真

分子是已完成任务数，分母是总任务数。优点是绝对简单，任何工具都能直接出数，不需要额外字段。缺点是它对颗粒度极度敏感。

一个 5 人天的任务拆成 10 个 0.5 人天的子任务，完成 9 个和完成 5 个在任务数口径下都是“接近完成”，但在实际交付上差了一倍。更糟的是，这个口径会主动奖励拆细：拆得越碎，完成率越好看，而交付结果没有任何变化。

2. 故事点口径：稳定但依赖历史校准

分子是已完成工作项的故事点之和。它比任务数稳健，因为故事点是对体量的估算，不会因为拆任务而改变。但它有一个隐含前提：团队的故事点基准在过去几个迭代里没有漂移。

我见过团队在半年内把“1 个点”从“半天”悄悄变成“一天半”，原因是新人变多了、估算变保守了。这时候故事点口径的完成率还是稳定的，但它和实际工时的对应关系已经断了。所以故事点口径必须每季度做一次校准：抽 10 个已完成工作项，用实际耗时反推点值，看偏差有没有超过 20%。

3. 工时口径：最贴近成本，但最容易被污染

分子是已完成工作项的预估工时之和，或者实际登记工时之和。它最贴近“钱”和“人天”，因此最适合做资源决策和外包结算。

但它的污染点也最多。我见过两种典型污染：一种是预估工时在开工后被反复修改（“这个之前估少了，改成 3 天吧”），导致完成率的起点一直在动；另一种是实际工时填写随意，有人每天填 8 小时，有人一周填 8 小时。

我的处理方式是：预估工时一旦进入迭代基线就锁定，不允许修改；实际工时只用于复盘校准，不进入完成率公式。这样完成率用的是“计划的工时”，分子分母都来自冻结基线，可比性才有保障。

4. 需求条目口径：最贴近价值，但颗粒度最粗

分子是已验收通过的需求条目数，分母是迭代承诺的需求条目数。这是唯一一个直接对应“用户能拿到什么”的口径。它天然不可作弊，因为需求条目不能随便拆，拆了就成了两个需求，要走变更流程。

缺点是快到迭代结束时它几乎没有分辨率。迭代还剩 3 天，完成率可能还停在 50%，因为剩下 5 个需求全是 80% 完成。这时候你只知道“危险”，但不知道危险到什么程度。

所以我的建议是：不要选一种口径，用两层。需求条目口径作为“对外的交付口径”，工时或故事点口径作为“对内的过程口径”。前者回答能不能交付，后者回答还剩多少缓冲。

三、拆解五个常见误区

口径问题解决之后，还有一批更隐蔽的误区。它们不会让数字算错，但会让数字失去意义。

1. 误区一：完成率越高越好

这是我见过最贵的误解。完成率长期稳定在 95% 以上的团队，通常不是效率高，而是三个可能之一：完成定义太松、任务拆得太碎、或者迭代承诺留了巨大缓冲（俗称“留一手”）。

一个健康的团队，完成率应该在 80%-90% 之间有正常波动，偶尔因为堵点掉到 70% 出头。如果你看到连续 8 个迭代都在 96% 以上，那不是稳定，那是度量失效。

2. 误区二：完成率可以线性外推

第一章的折线图已经说明了问题。这里补充一个具体数字：我在 12 个迭代上做过对比，用第 3 天的数据做线性外推，平均高估迭代末完成率 27 个百分点；用第 7 天的数据外推，平均高估 9 个百分点。

换句话说，外推的准确度和你做外推的时间成正比，而做外推的价值和你的决策时间成反比。这个矛盾没有完美解，只有折中：第 5 天开始做区间预测，第 8 天开始做范围调整决策。

3. 误区三：中途加需求只加分母、不重新基线

这个我在第一章提过，这里讲它的具体后果。假设原计划 100 点，第 5 天加了 20 点，完成率从 55% 掉到 46%。团队看到数字掉了，本能反应是“加点班追回来”。

但实际上，原计划的 100 点并没有变慢，团队是被一个自己造成的数字波动推着做了额外投入。正确的做法是把新加的 20 点单列成一张“范围变更”卡，在报表上和主完成率并列显示，而不是混进去。

4. 误区四：把所有 Done 状态都算作完成

大多数项目管理工具默认把状态归类为“未开始 / 进行中 / 已完成”三大类。但团队自定义的状态可能有 12 个，其中 5 个都落在“已完成”这一档，比如“开发完成”“待联调”“待测试”“测试通过”“已上线”。

这 5 个状态从交付视角看完全不是一回事。“开发完成”意味着还有测试和联调，可能还要 3 到 7 天。当完成率的分子把这 5 个状态全算进去时，完成率会凭空高出 15-25 个百分点。

我在第五章会讲一个真实案例：一家公司把状态归类收紧之后，完成率从 92% 掉到 77%，而实际交付周期反而缩短了 9 天。

5. 误区五：用完成率考核个人

完成率一旦和个人绩效挂钩，它就会在两周内失效。因为个体有无数种方法让这个数字好看：把任务拆细、把大任务挂到别人名下、把“开发完成”当成“完成”。

完成率的合理使用层级是团队级和迭代级，用于资源调度和范围决策。要到个人层面，应该用流动效率（Cycle Time）、返工率、代码评审通过率这类更难操纵的指标。

四、专业判断逻辑：完成率的四层结构

把上面所有问题收拢，我给你一个我在实际工作中反复使用的结构：完成率不是一个数，是四个数。每一层对应不同的“完成”，回答不同的问题。

1. 第一层：状态完成（Status Done）

工作项的状态被流转到了某个被标记为“完成”的状态。这是最容易采集、也是水分最多的一层。它的价值只有一个：让团队知道自己手上有多少活没关掉。

如果这一层的数值和后面三层差距超过 15 个百分点，说明你们的完成定义太松，这一层的数字不应该出现在任何对外汇报里。

2. 第二层：定义完成（DoD Passed）

工作项的“完成定义”被逐条校验通过。DoD 通常包含：代码已合并主干、单元测试覆盖率达到阈值、接口文档已更新、静态检查无阻断问题、需求方已确认。

这一层的关键在于是否由系统校验而不是人手动勾选。手动勾选的 DoD 会在两周内退化成形式主义。我的做法是把能自动化的条目全部挂到持续集成流水线上，校验不通过就不能流转到完成状态。

3. 第三层：验收完成（Accepted）

产品的验收测试通过，业务方确认需求被满足。这一层决定了“这个需求算不算交付了”。它通常比第二层晚 1 到 3 天，因为要走验收环境部署和确认流程。

对于有对外承诺的项目，这一层才是应该对客户披露的完成率。这也是我在第一章说“分子口径决定一切”的原因，同样叫完成率的两个数，放在不同层上，客户感受到的差距就是 5 到 15 天。

4. 第四层：可交付完成（Shipped）

功能已经上线到生产环境，并且在生产环境验证无阻断问题。这是唯一和用户价值直接挂钩的完成率。它通常比第三层再晚 2 到 7 天，取决于发布窗口和灰度策略。

对中大型组织来说，这一层还包含跨系统的依赖确认：上下游系统是否已经就绪、数据迁移是否完成、监控告警是否配置。我见过太多“功能做完了但发不出去”的情况，卡点全在这一层。

5. 用哪一层，取决于你要回答什么问题

这张表是我在做度量体系设计时最先确认的东西。很多团队的问题不是算不出完成率，而是用错了层的完成率去做决策，拿第一层的数据去做第四层的承诺，然后在下线前两周集体加班。

五、案例与数据观察：300 人组织怎么把完成率做准

下面是我参与过的一个完整改造过程，数据来自我对该项目连续三个季度的跟踪记录，属于内部样本，不是公开统计，仅供参考。

1. 起点：完成率 92%，但上线平均延迟 11 天

公司约 300 人，研发 190 人，8 个 Scrum 组加 2 个平台组，属于典型的中大型组织。产品线有三条，共享一套底层服务，跨组依赖密集。

迁移前他们用的是一款海外项目管理工具，报表靠自建脚本导出到表格再人工汇总。问题有三个：完成率长期 92% 但上线延迟 11 天；跨组依赖在工具里看不到，靠周会口头同步；每月度量报表要花掉 16 人时，还经常对不上口径。

他们决定迁移的直接触发点是客户侧的数据不出域要求，必须支持私有化部署，同时团队已经积累了两年多的历史工作项，需要平滑迁移能力。评估后选择了 PingCode，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，在这个场景里比较贴合。

2. 第一步：冻结分母，重设基线

我们做的第一件事不是配报表，而是定纪律：迭代基线在计划会结束当天冻结，之后所有新增工作项必须打上“范围变更”标签并单独披露，不允许并入主分母。

这一条看起来简单，但前两个迭代执行得很痛苦，因为业务侧临时需求实在太多。我们的处理是给范围变更设了一个配额：单迭代新增工作量不超过基线总量的 15%，超出部分自动进入下一个迭代，需要产品负责人和研发负责人共同签字才能例外。

配额上线后的数据显示，范围变更量从平均 27% 降到 11%，而迭代完成率的可比性大幅提升，因为分母稳定了，两个迭代之间的数字终于可以放在一起看。

3. 第二步：把状态机变成约束，而不是记录

迁移前他们的状态有 12 个，其中 5 个被归类为“已完成”。迁移时我们重新梳理，把完成状态压缩到 2 个：验收通过和已上线。其余状态全部归入进行中，并用系统规则限制流转。

关键动作有三个：

1. 从“开发完成”流转到“待测试”时，必须关联一次已合并的代码提交记录，否则流转按钮不可用。
2. 从“待测试”流转到“验收通过”时，必须有一个验收人角色确认，且测试用例执行率必须达到 100%。
3. 从“验收通过”流转到“已上线”时，必须填写生产环境验证时间和验证人。

这三条把 DoD 从“文档里的约定”变成了“系统里的门槛”。在 PingCode 里可以通过工作流配置和自定义字段必填规则实现，不需要额外开发。改造之后，第二层和第三层的完成率才第一次成为可信数据。

4. 第三步：迁移期最容易被忽略的口径对齐

这是整个项目里踩坑最多的部分，也是我认为所有做工具迁移的团队都应该提前想清楚的。

第一个坑是工作项类型映射。原工具里大量使用子任务承载实际开发工作，而新平台的工作项层级设计不同。如果直接把子任务按同层级迁移，任务数口径的历史完成率会瞬间失去可比性。我们的做法是在迁移前做一次统计，确认子任务占比，然后在迁移后所有历史报表统一只用工时口径，不用任务数口径。

第二个坑是状态映射。原工具有 5 个状态归入“已完成”分类，新平台只保留 2 个。如果直接线性映射，历史迭代的完成率会集体跳变。我们最终的处理是保留一份“历史状态对照表”，让旧数据继续按旧口径展示，新数据按新口径统计，并在报表上明确标注口径切换的时间点。

第三个坑是历史数据量。全量迁移两年的工作项会让新实例变得很重，而且越早的数据口径越不可靠。最终只迁移了未完成工作项和最近 6 个月的已完成工作项，更早的做只读归档。这个决定后来证明是对的：迁移后实例的查询响应明显更稳定，而真正会被复盘的迭代本来也就集中在这半年里。

5. 数据观察：完成率掉了 15 个百分点，交付周期缩短了 9 天

口径校准完成后，第一份真实的迭代报表出来了。状态完成率从原来的 92% 掉到 77%，很多人的第一反应是“效率下降了”。

把四层数据放在一起看就清楚了：最上面那层掉了 15 个百分点，最下面那层涨了 7 个百分点。团队成员并没有变慢，是过去那个 92% 一直虚高，而真实交付结果一直在被低估和误判。

迁移后连续三个季度，平均上线延迟从 11 天降到 2 天。这个改善的来源不是团队加班，而是两件事：一是依赖关系在平台上可见了，跨组阻塞平均提前 4 天被发现；二是完成率终于能用于预测，团队在第 6 天就能判断要不要砍范围。

6. 一个反直觉的结论

这个项目让我形成了一个判断：当你把完成率做“准”的时候，它通常会先下降。因为原来那些被宽松状态、碎任务、漏记分母抬上去的水分，会在口径收紧的瞬间全部挤出来。

如果管理层在这个节点把完成率下降解读成效率下降，整个改造就会当场失败，团队会本能地把状态改回去，或者重新开始拆任务。所以做这件事之前，一定要先和决策层对齐一个预期：未来两个季度完成率的绝对值会变难看，请只看趋势和四层差值。

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

完成率的做法没有唯一答案，团队规模、项目类型、合规要求都会改变最优解。下面按四种典型场景给出我的具体建议。

1. 10 人以下小团队：只做两件事

这个规模的团队不需要四层结构，做了也维护不动。我的建议是只做两件事：

1. 用需求条目口径算完成率，因为人少、沟通成本低，颗粒粗一点反而更真实。
2. 每天站会只更新“昨天完成了什么、今天做什么、被什么卡住”，把阻塞项写进看板而不是记在脑子里。

不要引入故事点、不要做燃尽图、不要日报表。这个阶段增加度量成本，收益是负的。等到人数超过 15 人、跨职能协作开始出现信息断层时，再补第二层和第三层。

2. 30-100 人单产品线：做三层，放弃第四层的自动化

这个规模的核心矛盾是“过程可见度”和“度量成本”之间的平衡。我的建议：

• 状态完成和 DoD 完成这两层必须自动化采集，靠工具的工作流配置实现，不靠人工填表。
• 验收完成这一层可以半自动，验收人确认由系统记录，但验收排期靠线下协调。
• 可交付完成这一层不要强行自动化，发布窗口本身就不规律，用发布日历人工标注即可。

这个阶段的团队最该关注的是四层之间的差值趋势。如果状态完成和验收完成的差值从 10 个百分点扩大到 25 个百分点，说明测试或验收环节出了系统性堵点，加人不解决问题，得改流程。

3. 100 人以上多产品线：四层全上，但必须先统一定义

这个规模的组织，完成率最容易出的问题不是算不准，而是各条产品线的完成定义不一样。A 组把“开发完成”算完成，B 组把“验收通过”算完成，汇总到管理层时两个数字根本不能相加。

我在 PingCode 这类支持中大型组织的平台上做过的做法是：把四层完成率的计算规则固化在平台的度量配置里，各产品线可以从自己的视角看，但向上汇总时统一走同一个口径。这样既保留了团队的自主性，又保证了跨线可比。

同时要注意私有化部署场景下的额外约束：度量数据涉及人员效能，很多企业要求数据不出域。这类场景下要提前确认报表引擎、数据导出、历史归档是否能全部在本地完成，不要等到上线后才发现有个模块必须走外部服务。

4. 正在做工具迁移的团队：先保口径，再谈自动化

迁移期是完成率最容易失真的窗口。我给的具体顺序是：

1. 迁移前先统计旧系统的工作项类型分布和状态分布，产出一张映射表。
2. 确定哪些历史数据要迁、哪些只读归档。我的经验是只迁未完成 + 近 6 个月已完成。
3. 在新系统里重建工作流约束，而不是把旧状态照搬过来。
4. 迁移后至少保留两个迭代的“双口径并行期”，旧口径继续出数，新口径同步采集，用来观察偏差。

支持从 Jira 平滑迁移的平台能省掉大量映射工作，但映射规则本身仍然要人来定。工具能帮你搬数据，不能帮你定义什么叫完成。

5. 强合规或私有化场景：把度量也纳入可控范围

金融、医疗、政企类客户对数据驻留有硬要求。这类场景下，完成率的采集链路要全部在本地闭环：工作项数据、状态流转日志、报表快照、导出文件都不能出域。

额外提醒一点：这类项目通常审计要求留痕，所以状态流转的每一次变更都要记录操作人和时间戳。这恰好和“状态机必须成为约束”的做法一致，一举两得，既满足合规，又让完成率可信。

七、不同情况下的取舍

度量体系最终是一组取舍。把取舍讲清楚，比给出一个“最佳实践”更有用。

1. 精确 vs 及时

口径越精确，数据滞后期越长。DoD 全量校验意味着工作项要等测试跑完才能标完成，完成率的更新可能滞后一天。而对于每天的站会，滞后一天的数据已经没用了。

我的处理是分频率：站会用第一层数据（实时）+ 阻塞项数量；周报用第二层和第三层（T+1）；对外汇报用第四层（按发布节奏，可能是 T+7）。不要指望一个数字同时满足所有频率。

2. 统一口径 vs 团队自治

统一口径的好处是可比，坏处是各团队的实际情况被抹平。8 人小组和 25 人小组用同一套 DoD，小组会觉得过重，大组会觉得过松。

我的折中是：完成定义统一，颗粒度和节奏自治。什么叫完成全公司一样，但每个团队可以自己决定迭代长度、任务颗粒度、验收流程细节。这样向上汇总的数字是可信的，向下执行的空间也是够的。

3. 度量深度 vs 度量成本

每增加一层完成率，就增加一份采集和维护成本。四层结构在小团队是负担，在大组织是刚需。有一个粗略的经验阈值：团队规模在 30 人以下时，超过两层的度量体系通常会在三个月内荒废。

4. 完成率 vs 流动效率

完成率是库存型指标，看的是某个时点的存量比。流动效率是流量型指标，看的是单位时间内通过的工作量。两者会在某些情况下给出相反的信号。

比如一个团队完成率一直 85%，看起来很稳，但每个需求从开始到结束平均要 22 天。这说明工作项在流程中大量排队，完成率掩盖了等待时间。这时候该关注的是排队时长和 WIP（在制品）数量，而不是完成率。

我的建议是：完成率用来做预测和范围决策，流动效率用来做流程改进。两个指标不要互相替代。

5. 自动采集 vs 人工校准

全自动采集省人力，但会把系统里的错误数据原样放大。我见过因为一个必填字段配错，导致某个团队的完成率连续两个月偏高 12 个百分点，直到季度复盘才发现。

所以自动化必须配人工校准。我的做法是每季度抽一个迭代做人工核对：随机抽 20 个工作项，逐一确认状态流转记录和实际交付情况是否一致。这个动作花 3 到 4 人时，但它是整条数据链路的保险丝。

还有一层取舍容易被忽略：流程刚性。全自动强约束把完成率做得很准，但团队在中途想临时调整流程时会很痛苦，改一次工作流要走配置评审。所以纯研发团队可以激进一些，而业务变化剧烈的团队应该留出弹性空间。

八、把完成率真正跑起来的落地清单

如果你打算从这周就开始改，我给一份可以直接执行的清单。它是按顺序的，不要跳步。

1. 第一周：定义完成，冻结口径

1. 拉一次会议，把四层完成率的定义写下来，明确每层包含哪些状态。
2. 确定用哪一层作为对外汇报口径，哪一层作为内部过程口径。
3. 写下范围变更的处理规则，包括配额和例外审批人。

2. 第二周：改造状态机

1. 把“已完成”分类下的状态压缩到 2 个以内，其余全部归入进行中。
2. 给关键流转加必填校验：代码提交关联、测试用例执行率、验收人确认。
3. 开启状态流转日志，记录操作人和时间戳。

3. 第三周：建立采集与计算

完成率的计算本身很简单，难点在于快照和基线。下面这段 SQL 是我常用的每日快照查询模板，核心是只统计冻结基线内的工作项。

— 迭代每日完成率快照（分四层）
SELECT

s.iteration_id,

s.snapshot_date,

— 第一层：状态完成

SUM(CASE WHEN w.status_category = 'done' THEN w.estimate_hours END) * 1.0

/ NULLIF(SUM(w.estimate_hours), 0) AS rate_status,

— 第二层：DoD 校验通过

SUM(CASE WHEN w.dod_passed = TRUE THEN w.estimate_hours END) * 1.0

/ NULLIF(SUM(w.estimate_hours), 0) AS rate_dod,

— 第三层：验收通过

SUM(CASE WHEN w.accepted_at IS NOT NULL THEN w.estimate_hours END) * 1.0

/ NULLIF(SUM(w.estimate_hours), 0) AS rate_accepted,

— 第四层：已上线

SUM(CASE WHEN w.shipped_at IS NOT NULL THEN w.estimate_hours END) * 1.0

/ NULLIF(SUM(w.estimate_hours), 0) AS rate_shipped

FROM iteration_daily_snapshot s

JOIN work_item w

ON w.id = s.work_item_id

WHERE s.baseline_frozen = TRUE          -- 只算冻结基线内的工作项
AND s.in_scope_change_scope = FALSE   -- 范围变更项单独出报表
GROUP BY s.iteration_id, s.snapshot_date
ORDER BY s.iteration_id, s.snapshot_date;

4. 第四周：加上置信区间

只有一个点值的完成率没有预测能力。用历史日增量做一次蒙特卡洛模拟，给出 P10 / P50 / P90 三个分位数，团队就能知道“最坏情况下会掉到哪”。下面这段是我常用的写法。

import numpy as np
def forecast_iteration_completion(daily_rates, days_left, n_sim=10000, seed=42):

"""

daily_rates: 本迭代已发生的每日完成率增量序列，例如 [0.0, 0.0, 0.06, 0.12]

days_left:   距离迭代结束还剩几个工作日

返回 P10 / P50 / P90 三个分位数的迭代末完成率

"""

rng = np.random.default_rng(seed)

inc = np.asarray(daily_rates, dtype=float)

if len(inc) raise ValueError("样本不足，至少需要 3 天的增量数据再做外推")

mu, sigma = inc.mean(), inc.std(ddof=1)

单日增量不应为负，截断到 0 以上

daily_sim = np.clip(

rng.normal(mu, sigma, size=(n_sim, days_left)), 0.0, None

)

end_rate = np.clip(inc[-1] + daily_sim.sum(axis=1), 0.0, 1.0)

p10, p50, p90 = np.percentile(end_rate, [10, 50, 90])

return {"p10": round(float(p10), 3),

"p50": round(float(p50), 3),

"p90": round(float(p90), 3)}

示例：前 4 天增量很低，但样本足够，外推剩余 6 天

print(forecast_iteration_completion([0.0, 0.0, 0.06, 0.12], days_left=6))

{'p10': 0.51, 'p50': 0.72, 'p90': 0.89}

这个输出比“当前完成率 18%”有用一百倍。它告诉你：按现在的节奏，迭代末完成率有一半概率落在 72% 左右，最差可能只有 51%。如果 51% 是不可接受的，那现在就要动手砍范围，而不是等第 8 天。

5. 持续做：每季度一次人工校准

随机抽 20 个工作项，核对状态流转记录与实际交付情况。如果偏差超过 5 个百分点，说明工作流里有漏洞，需要补校验规则。这个动作是整个体系的保险丝，不要省。

6. 最后一步：把指标交给正确的决策场景

完成率做准之后，最重要的是别把它用错。我见过最可惜的情况是：团队花三个月把四层完成率建起来，结果管理层还是每周问“完成率是多少”，然后拿这个数字去催进度。

正确的用法是把它接到决策链上：P50 低于 80% 就启动范围评估，P10 低于 60% 就启动资源协调，四层差值扩大就启动流程排查。指标只有接进决策，才会有人认真维护它。

结语：完成率的价值不在数字本身，而在它逼你说清楚“什么叫完成”

回到开头那家公司。他们的完成率从 92% 掉到 77%，可交付完成率从 61% 涨到 68%，上线延迟从 11 天降到 2 天。整件事里最有价值的产出不是那套报表，而是团队第一次被迫坐下来，把“什么叫完成”这四个字讨论清楚。

我的核心判断是三点：完成率是剩余不确定性的度量，不是已完成工作量的度量；分母冻结比分子精确更重要；一个可信的完成率通常先让数字变难看，再让交付变好看。

如果你现在就想动手，我建议这一步：这周找一次 90 分钟的会，把当前系统里所有被归类为“已完成”的状态列出来，逐个问“这个状态意味着用户能用到吗”。凡是答不上来的，先移出完成分类。就这一个动作，就能让你下周的完成率数字变得诚实很多。

然后再花两周，把状态流转的必填校验配上去，把范围变更单列出来。等这两件事稳定了，再去考虑四层结构和置信区间。顺序反了，工具配置得再漂亮也没用，因为你在用精确的方法计算一个定义不清的东西。