进度管理完成率全流程：产品经理最佳实践与一文讲清

去年第三季度，我参与了一家 130 人 SaaS 公司的季度交付复盘。会议室里摆着一张很漂亮的进度看板：四条产品线，完成率分别是 94%、91%、88%、96%。但同一季度的实际结果是，三个承诺的版本里只上线了一个半，另外两个延期到第四季度，其中一个还砍掉了将近三分之一的功能范围。会后我问他们的研发负责人：“你们自己信这个 94% 吗？”他停了两秒说：“我们信的其实是延期，完成率是给上面看的。”

这句话基本概括了我想在这篇文章里讲清的事。进度管理完成率最大的问题不是算得准不准，而是它经常被当成一个“结果指标”来用，而它本质上只是一个“过程代理指标”。一旦代理指标被当成结果指标去考核、去汇报、去对齐资源，它就会在几周内被组织“优化”成一个好看但失去信息量的数字。这篇文章会从口径定义、失真机制、四层模型、真实改造案例，一直讲到不同规模团队该怎么配指标、该怎么取舍。

一、核心结论：完成率不是进度指标，而是承诺兑现率的代理

先给结论，后面所有内容都是围绕这几条展开的。

第一条结论：脱离口径谈完成率，等于没谈。同一个迭代，用“任务条数”算完成率是 93%，用“故事点”算可能是 81%，用“加权工作量”算可能是 74%，用“通过验收的需求数”算可能只有 62%。四个数字都是对的，但它们指向四种完全不同的管理动作。你在周会上报哪一个，决定了团队接下来一周会往哪个方向使劲。

第二条结论：完成率天然是滞后的、易被修饰的，必须配卫星指标。单纯看完成率，你无法区分“真的做完了”和“被标记为做完了”。我习惯给它配四个卫星指标：承诺兑现率、返工回流率、需求变更率、需求周期时间。这四个指标组合起来，才能把完成率从一个“表演性数字”还原成一个“诊断工具”。

第三条结论：完成率下降有时候是好事。这一点最反直觉。从“任务条数完成率”切换到“验收价值完成率”时，几乎所有团队的完成率都会掉 15 到 30 个百分点。那不是团队变差了，而是之前的水分被挤出来了。如果一次口径切换之后完成率没掉，我基本可以判断这次切换是走过场。

1. 用挣值管理的视角重新理解完成率

项目管理领域其实早就有成熟的答案，只是大部分互联网团队没有把它接过来用。挣值管理（Earned Value Management）里有个核心指标叫进度绩效指数，公式是 SPI = EV / PV。其中 PV 是计划价值，EV 是挣值，也就是“已经完成的那部分工作，按预算价值折算出来是多少钱”。

关键在这里：挣值的本质就是一个带权重的完成率，而且这个权重是“预算价值”，不是“任务条数”。大多数团队算的完成率，其实是一个“没有预算权重的挣值”，只有分子没有分母的价值口径。这也是为什么它这么容易被注水，任务条数是可以被拆出来的，而预算价值不行。

所以你不需要真的去搞一套完整挣值体系，但你需要借用它的核心思想：完成率的权重必须来自工作本身的价值或成本，而不是来自工作被切成了几块。

2. 我判断一个完成率指标是否可信的四个问题

我在做流程诊断时，会用四个问题去快速判断一个团队的完成率是否可信。

1. 分母是冻结的还是漂移的？如果迭代中途可以随意加需求而不重新承诺，完成率天然会走低，但这个走低不反映任何执行问题。
2. “完成”的定义是谁给的？是执行者自己点的，还是经过验收/测试确认的？这两种定义的可信度差一个数量级。
3. 返工算不算？一个任务做完又被打回来重做，它在完成率里是 1 次还是 0 次？如果不统计回流，完成率会系统性高估。
4. 这个数字用在哪里？如果它出现在个人绩效里，你得到的将是“任务拆分技巧”而不是“交付能力”。

这四个问题里，只要有两个以上回答得含糊，我基本可以判断这个团队的完成率在管理上是无效的，它既不能预警风险，也不能解释原因。

二、背景与真实场景：完成率是在哪一步开始失真的

要讲清楚完成率的问题，得先看它在真实团队里是怎么被生产出来的。我过去三年做过四十多次项目流程复盘，样本以 50 到 500 人规模的研发组织为主。这不是严谨的统计研究，但它们暴露出了一致的模式。

完成率失真的路径几乎是固定的：拆分粒度决定分母 → 状态定义决定分子 → 分母是否冻结决定可比性 → 数字被用在哪里决定失真速度。四步里任何一步出问题，最终数字都会偏离现实。

1. 场景一：任务拆分粒度决定了完成率的上限

我见过最夸张的一个例子，是一个 8 人小组把“对接第三方支付回调”拆成了 27 个任务，其中 19 个是“联调某个具体字段”。那个迭代他们的完成率是 96%，但实际上支付回调的主流程根本没跑通，因为最后两个关键任务卡在对方接口变更上。

这里的机制是：任务拆得越细，完成率越容易高，因为它把“接近完成”包装成了“大部分完成”。一个 5 人天的任务做到 80% 是一个红灯，但把它拆成 10 个 0.5 人天的任务、做完 8 个，完成率就是 80% 的绿灯。数字一样，管理含义完全相反。

更隐蔽的问题是，拆分粒度通常由执行者自己决定。当完成率被用于汇报或考核时，拆细任务就成了一种理性的自我保护行为。你很难说这是造假，因为它确实在干活，只是把风险藏在了任务的缝隙里。

2. 场景二：状态字段被人情污染

很多团队的状态流转是这样的：开发说“我这边写完了”，就把卡片拖到“已完成”，测试还没验，产品还没看。到了迭代评审，这些卡片就成了完成率的分母贡献者。等到测试发现问题，卡片被拖回“进行中”，但已经过了统计时间点。

我在一个团队里做过统计，他们迭代内被拖回“进行中”的任务占到了总任务数的 14%，其中约 6 个百分点是在迭代结束后的两三天内发生的。也就是说，如果只看迭代结束当天快照出的完成率，会系统性高估 6 到 14 个百分点。

这不是态度问题，是定义问题。当“完成”的定义没有被写清楚，谁有权把卡片移到已完成、移到已完成之前必须发生什么，状态字段就会退化成一种沟通话术，而不是数据。

3. 场景三：里程碑“完成”了，但价值没有交付

第三类失真发生在更高层级。我见过一个项目，所有里程碑都按时打了勾，完成率 100%。但上线三个月后，业务侧反馈核心场景的转化率没有任何提升。回头查才发现，几个“完成”的里程碑交付的是“功能可用”，而业务需要的是“功能被使用”，中间还差着用户引导、数据埋点、运营配置一大堆事情，这些都没被纳入里程碑定义。

里程碑的完成率失真，往往不是执行问题，而是定义问题，里程碑的描述停留在交付物层面，没有挂钩价值假设和验收条件。这是产品经理最容易背锅也最应该负责的一环。

4. 场景四：改需求不改分母

最后一种情况最普遍：迭代中途加了需求，分母没有重新承诺。团队的完成率因此掉下去，看起来像是执行力下滑，其实只是范围变了。反过来也一样，如果中途砍掉了需求却没有同步调整分母，完成率会虚高。

我在复盘里见过一个团队连续四个迭代完成率在 85% 到 90% 之间波动，看起来非常稳定。但实际上四个迭代的最终交付范围分别是最初承诺范围的 118%、92%、105%、80%。完成率稳定掩盖了范围剧烈漂移。只看这一个数字，你完全看不出来。

5. 一条被忽略的规律：粒度、填报成本与数据质量的三角关系

这里加一条我自己观察到的经验规律，它对后面的取舍部分很重要。工作项的拆分粒度、状态更新的填报成本、数据可信度，这三者构成一个不可能三角。

如果你想拆得很细（比如单个任务控制在 4 小时以内），那状态更新的频率就必须很高，执行者的填报负担会显著上升。一旦单个工作项从创建到关闭的平均人工投入超过 3 分钟，我观察到的规律是：大约 6 周内，状态更新会集体退化成“批量补录”，数据可信度随之坍塌。

这个 3 分钟和 6 周的数字来自我对六个团队填报行为的跟踪记录，不是普适定律，但方向性我觉得是稳的。它意味着：任何完成率体系的精度上限，不是由你想要多准决定的，而是由团队愿意承担的填报成本决定的。

三、拆解六个常见误区

下面这六个误区，我在不同团队里都见过至少三次以上。它们的共同点是：看起来都是在优化完成率，实际上是在摧毁完成率的信息价值。

1. 误区一：把完成率直接当成绩效考核项

这是所有误区的源头。一旦完成率进入个人绩效，团队的理性选择变成三件事：把大任务拆小、把状态尽早推到完成、把难任务往后拖。这三件事单独看都不算错，合起来的结果是完成率上升而交付下降。

我的判断很明确：完成率可以用于团队级的趋势观察，不能用于个人级的绩效打分。如果一定要考核，考核“承诺兑现率”比考核“完成率”健康得多，因为它把分母锁定在承诺上，拆小任务没有用。

2. 误区二：用任务条数做加权

用条数加权的问题前面已经讲过机制。这里补充一个更实际的判断：如果一个团队的任务估算里存在“人天”“故事点”这类字段，却仍然用条数算完成率，说明这个估算字段大概率是形式主义。我去过好几个团队，故事点字段填得整整齐齐，但从来不进入任何统计。

3. 误区三：分母冻结，拒绝承认范围变更

和上面正好相反。有的团队为了“保持完成率可比”，坚决不允许中途调整分母，结果完成率一路下滑，团队开始觉得自己不行。实际上问题出在范围管理上，不是执行上。

正确的做法不是冻结分母，而是把“变更后再承诺”作为一个显式动作记录下来。分母可以变，但每一次变都要有人签字、有原因、有时间点。这样才能区分“执行不力”和“范围失控”。

4. 误区四：只统计当期，不看跨期

迭代结束时没做完的任务怎么办？很多团队的做法是直接顺延到下一个迭代，从上个迭代的统计里消失。结果是每个迭代看起来完成率都不错，但总有那么几件事在两个迭代之间来回滚动，永远做不完。

我建议加一个“滚动债务”指标：连续两个迭代以上未完成的工作项数量。这个数字比完成率更能暴露真实的阻塞。

5. 误区五：不统计返工

返工是完成率最大的水分来源之一，也是最容易被忽视的。因为返工发生在“完成”之后，统计时点已经过去了。我在一个 60 人团队里推动加了“回流率”统计，每周被从已完成状态拖回进行中或待验证的工作项占比，第一周就测出 14%。

这个数字带来的最大价值不是批评谁，而是让团队第一次意识到：他们的“完成”里有七分之一是假的。之后他们重新定义了完成的入口条件，三个月后回流率降到 5%。

6. 误区六：追求 100% 完成率

最后一个误区看起来很正向。但如果一个团队的迭代完成率长期稳定在 98% 以上，我几乎可以断定他们承诺得太保守了。完成率是一个关于“承诺质量”的指标，健康区间不是越高越好，而是 80% 到 90% 之间，足够高说明承诺可靠，足够低说明团队在挑战有不确定性的目标。

长期 100% 意味着团队在做确定性工作，也意味着他们没有被允许失败。这对需要探索新方向的产品团队来说是危险的信号。

四、专业判断逻辑：四层完成率模型

讲完问题，讲方法。我这些年沉淀下来的做法是把完成率拆成四层，每层解决不同的问题，每层用不同的口径。不要试图用一个数字回答所有问题，那是完成率体系崩坏的起点。

1. 第一层：任务完成率，用于日常站会和阻塞识别

这一层最细，粒度到任务。它的作用是让团队每天知道谁卡住了，不承担汇报职责。口径建议用条数就够了，不需要加权，因为这一层的使用场景是当天对话，不是趋势分析。

关键约束：这一层的数字不要向上汇报。它一旦被上级看到，就会立刻失去真实性。

2. 第二层：需求完成率，用于迭代评审和承诺兑现评估

这一层以“需求/用户故事”为单位，口径有两种：按故事点加权，或者按需求数量。我更推荐按需求数量，因为故事点会随熟练度漂移，跨迭代不可比。

这一层最重要的设计不是分子怎么算，而是“完成”必须由验收动作触发。具体来说，需求从“待验收”进入“已完成”，必须由产品经理或测试人员操作，而不是开发自己。

3. 第三层：里程碑完成率，用于跨团队对齐和对外沟通

里程碑层的完成率，权重应该来自里程碑下的需求集合，而不是里程碑本身的数量。三个里程碑里完成一个，完成率不是 33%，而要看这个里程碑承载了多少需求。

这一层最容易被做假，因为里程碑的描述通常比较抽象。我的建议是每个里程碑在启动时必须写清三件事：交付物清单、验收条件、不包含什么。第三条特别重要，它是防止范围蔓延的主要手段。

4. 第四层：价值完成率，用于季度复盘和资源决策

第四层不按“做完”算，按“产生预期结果”算。比如某个功能上线后 30 天内，目标指标达到设定阈值才算完成。这一层的周期通常跨季度，采集成本高，但它决定了资源该往哪里投。

大部分团队不需要对每个需求都做价值完成率，我建议只对占比 20% 的关键需求做，因为它们通常贡献 80% 的业务影响。

5. 四层模型的权重分配与达标线

四层不是并列的，它们在同一份汇报里出现时应该有明确的权重。我在实践中用的一套参考配置是这样：

关于达标线，我给一组经验参考值，来自我观察过的团队中位水平：任务层完成率健康区间 75% 到 90%；需求层完成率健康区间 80% 到 92%；里程碑层完成率健康区间 85% 到 95%；价值完成率因为周期长，建议按季度设定绝对目标而不是百分比。

再给一个计算示例，方便你直接套用。需求层加权完成率的计算逻辑可以写成这样：

// 需求层完成率（按需求数量，验收后计入）
需求完成率 = 通过验收的需求数 / （迭代承诺需求数 + 中途新增并重新承诺的需求数）

// 任务层完成率（仅用于站会，不向上汇报）

任务完成率 = 处于已完成状态的任务数 / 迭代内全部任务数

// 回流率（质量修正系数，建议每周统计）

回流率 = 本周从已完成回退到进行中/待验证的工作项数 / 本周新增完成的工作项数

// 承诺兑现率（最能反映承诺质量）

承诺兑现率 = 迭代结束当天已验收需求数 / 迭代启动时承诺需求数

注意最后两个公式：回流率和承诺兑现率，是我认为比完成率本身更有管理价值的两个数字。如果只能保留两个指标，我会选它们，而不是完成率。

五、真实案例与数据观察：一家 120 人团队把完成率从“好看”变成“可信”

下面这个案例是我在 2023 年到 2024 年间接手的一个改造项目，团队规模 120 人左右，四条产品线，研发、测试、产品合计约 95 人，其余是设计和运营。他们当时已经用了一段时间的项目管理工具，数据积累很全，但完成率一直不可信。

1. 改造前的基线数据

改造前他们用的是“任务条数完成率”，迭代周期两周，每个迭代平均创建 300 到 340 个任务。表面数据是：完成率常年稳定在 88% 到 95%，看起来非常健康。

但同期真实的交付情况是：版本按期交付率只有 38%，需求平均周期时间 21 天，迭代内需求变更率 34%。这三个数字和 90% 的完成率放在一起，是明显矛盾的。矛盾本身就是最好的诊断入口。

2. 三步改造过程

我们没有一上来就换工具，而是先做了三件事。

第一步是重新定义“完成”。我们花了两个下午，把四条产品线的状态流统一成六态：待排期、进行中、待验证、验证中、待上线、已完成。关键规则是：从“验证中”到“待上线”必须由测试或产品操作，开发无权直接推到已完成。

第二步是启用需求层口径。任务层继续用于站会，但迭代评审和向上汇报只认需求层完成率，权重按需求数量算，不按故事点。同时把中途新增需求做成显式动作，必须由产品经理在系统里操作并记录原因。

第三步是加回流率统计。每个工作项的状态流转历史都被保留下来，可以按周统计从已完成回退的数量。这一步是后面数据质量能稳住的关键。

3. 工具层面的选择与迁移

他们原来用的是海外工具，2023 年下半年开始评估替换方案，主要考虑三点：数据能不能私有化留存、状态流转历史能不能被完整导出做统计、迁移成本可不可控。最终他们选了 PingCode。我参与了这个评估过程，可以讲几个具体判断。

第一是私有化部署能力。他们有部分客户数据涉及合规要求，需要在内网环境跑项目管理数据，这一条直接过滤掉了相当一批 SaaS 产品。PingCode 支持私有化部署，这是他们能进入终选的主要原因。对于 100 人以上、有数据合规诉求的中大型组织来说，这个能力不是加分项，而是准入门槛。

第二是迁移可行性。他们原来的工具里积累了三年数据，约 1.8 万条工作项、40 多个迭代、若干自定义字段。迁移最怕的不是数据搬不过去，而是字段映射错了导致历史统计口径断裂。PingCode 支持从 Jira 平滑迁移，字段映射和迭代数据基本能对齐，这次迁移我们实际用了大约三周完成全量切换，其中两周在验证映射后的历史数据是否与旧系统一致。

第三是状态流转的可统计性。这一点在选型时最容易被忽略，但它直接决定了你能不能算回流率。如果一个工具只保存当前状态，不保存流转历史，那你永远算不出返工。迁移完成后，他们把状态流转历史接了一个简单的统计脚本，每周一出回流率报表。

4. 十二周后的数据变化

改造从第一周开始，第十二周做第一次完整复盘。最反直觉的结果是：他们的完成率从 91% 降到了 73%。如果只看这一个数字，这像是一次失败。但同期其他指标的变化说明了完全不同的事情。

这张表里我最看重的是两个数字的组合：需求层完成率下降 9 个百分点，同时承诺兑现率上升 23 个百分点。这说明团队做的事情没有变少，变的是他们不再承诺自己交付不了的范围。完成率下降是水分被挤出的结果，承诺兑现率上升才是真实能力提升的证据。

5. 这个案例里的三个可复用结论

第一，改造的顺序必须是先定义、后工具、最后才是统计。他们先花两个下午对齐状态定义，再评估工具，最后才接统计脚本。如果顺序反过来，先买了工具再去想口径，大概率会变成一个功能齐全但没人用的系统。

第二，回流率是性价比最高的一个新增指标。它的采集成本几乎为零（前提是工具保留流转历史），但信息量极大。如果只能加一个指标，我会加它。

第三，迁移项目的风险主要在历史数据一致性，不在功能映射。这次他们花了两周做映射验证，看起来慢，但避免了后面统计口径断裂。这一点对所有考虑从海外工具迁移到国产平台的团队都适用，PingCode 支持从 Jira 平滑迁移，但平滑指的是工具能力，验证工作仍然得自己做。

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

下面的建议按团队规模和业务形态分组。我刻意没有给一套通用方案，因为完成率体系的设计和实施成本高度依赖组织规模，照搬大厂做法往往是灾难。

1. 20 人以下团队：不要做加权，做对话

这个规模的团队，完成率的统计成本远高于它的管理价值。我的建议是：只用人天或简单的需求数量，一周做一次 30 分钟的对齐，完成率只在看板上展示，不进任何报表。

真正需要盯的是阻塞项和依赖项。这个阶段引入复杂的四层模型，只会增加沟通负担，不会提升交付。

2. 20 到 100 人团队：做需求层口径，加一个回流率

这个区间是收益最明显的。建议动作是：统一状态流并明确“完成”的操作权限；把汇报口径从任务层切到需求层；加一个回流率周报。不需要做价值完成率，周期太长，采集成本不划算。

这个阶段的迭代周期建议保持两周，不要为了追求精度做一周迭代，一周迭代会让状态更新频率翻倍，填报成本很容易突破我前面说的 3 分钟阈值。

3. 100 人以上中大型组织：四层模型 + 项目集视图

这个规模必须要工具支撑，原因有三个：跨团队的状态流转靠人工同步会失真；历史数据的保留必须由系统保证；权限分级需要平台能力。这也是 PingCode 这类主要服务中大型企业及 100 人以上组织的平台的价值区间。

具体建议：建立组织级的状态字典，所有团队在其中选择子集，不允许自定义同义状态；里程碑层完成率进入月度经营会；价值完成率只覆盖关键需求的 20%；把数据保留策略和私有化部署方案在选型阶段就谈清楚，不要等到合规审查时再补。

4. 多项目并行团队：算资源供给，不算任务完成

多项目并行时，完成率的解释力会大幅下降，因为瓶颈往往在人力供给而不是任务执行。这时候应该算的是：每个资源池的人天供给量 vs 各项目承诺占用量。完成率只用于解释单个项目内部的偏差。

我的经验是，多项目场景下最该看的是资源冲突热力，某个角色同时被三个项目占用超过 100%，那这三个项目的完成率都不可信。

5. 交付型/外包型团队：完成率必须挂钩验收单据

这类团队和产品团队的差别在于，完成不等于上线，而是等于客户签字。所以完成率的分子必须严格限定为“已获得验收确认”的工作项，任何内部状态都不算。这种情况下，完成率本质是一个合同履约指标，注水带来的风险是商业性的。

七、不同情况下的取舍

方法讲完，最后讲取舍。因为所有关于完成率的讨论，最终都会落到四组现实矛盾上。这四组矛盾没有标准答案，只有你愿意付什么代价。

1. 取舍一：统计精度 vs 采集成本

这条我前面提过阈值：单个工作项平均填报时间超过 3 分钟，数据会在 6 周左右崩塌。所以精度的上限由团队的时间预算决定，不由管理者的期待决定。

我的建议是把精度资源集中在 20% 的关键需求上，其余需求用粗口径。这比全面精细化更可持续，也更容易坚持一年以上。

2. 取舍二：数据透明 vs 心理安全

完成率公开到个人层级，短期会提升状态更新频率，中期会诱发拆小任务，长期会压制风险提前暴露。反过来，如果完全不透明，管理层会失去对进度的基本判断。

我的折中方案是：完成率透明到团队层级，回流率透明到工作项层级，但两者都不进入个人评价。工作项层级的透明用来定位流程问题，不是为了找人。

3. 取舍三：组织统一口径 vs 团队自治

强统一的好处是横向可比，坏处是有些团队的业务节奏确实不适合统一口径，硬套会失真。弱统一的好处是适配性高，坏处是管理层无法做组合判断。

我的做法是分层处理：状态字典统一，指标定义统一，达标线由团队自定。也就是说，“已完成”必须由验收触发这一条全组织一致，但一个团队把需求层完成率的达标线定在 85% 还是 90%，由他们自己和业务方谈。

4. 取舍四：工具投入 vs 流程改造

最后一个取舍最现实。工具能自动化采集、保留历史数据、提供项目集视图，但它定义不了“什么算完成”。流程改造能解决定义问题，但如果没有工具支撑，定义会在一两个月内被遗忘。

顺序上我坚持先流程后工具。本案例里，如果他们先换了工具再想口径，很可能得到一个功能齐全但统计不出有效数据的平台。工具的价值是把已经想清楚的口径固化下来，而不是替你想清楚口径。

5. 一个判断清单：什么时候该推翻现有完成率体系

最后给你一个我常用的判断清单。如果以下四条里有三条命中，我建议你不要继续微调，而是推翻重做。

• 完成率长期稳定在 90% 以上，但版本按期交付率低于 60%；
• 迭代内需求变更率超过 25%，且分母从不调整；
• 团队里有人说不出“完成”这个状态是谁有权设置的；
• 回流率从没被统计过，或者根本查不到状态流转历史。

这四条命中的组合，说明问题不在指标本身，而在指标背后的定义机制和数据基础。

八、总结与下一步行动

回到开头那个 94% 完成率的会议室。真正的问题不是数字高，而是所有人都知道它不代表现实，却仍然用它开会。当一个指标失去了共识，它就不再是管理工具，而是一种组织仪式。

我想强调的独特观点有三个。第一，完成率是承诺兑现率的代理指标，代理指标一旦被当作结果指标使用，就会在几周内被优化到失去信息量。要判断它是否可信，看的不是算法复杂度，而是权重是否来自价值、完成是否有验收门槛、返工是否被计入。

第二，完成率下降可能是健康的信号。从任务层切到需求层、从内部状态切到验收状态，完成率下降 15 到 30 个百分点是正常现象。真正该同步上升的是承诺兑现率和按期交付率。如果一次改造之后完成率没有下降，那大概率是走过场。

第三，四层模型的价值不在“更全面”，而在“分层使用”。任务层用于对话，需求层用于评审，里程碑层用于对齐，价值层用于决策。用错层级比不用层级更危险，因为错误的数字会带来错误的信心。

如果你准备动手，我建议按七天来安排下一步。第一天到第二天，把状态字典和“完成”的权限定义清楚，写成一页文档。第三天，拉出最近两个迭代的数据，用需求层口径重算一遍完成率，看看和现有数字差多少，这个差值就是你过去一直在承担的水分。第四天，确认你现在的工具能不能导出状态流转历史，能不能算回流率；如果不能，把它列进工具评估的硬性条件。第五天到第六天，和业务方重新谈一次承诺范围，把“不包含什么”写进里程碑。

第七天，把新的完成率、承诺兑现率、回流率三个数字放上你的看板，从下一个迭代开始跑。

四周之后你再回头看，大概率会发现完成率变低了，但你终于可以信赖它了。