进度管理完成率全流程：产品经理实操方法与一文讲清

去年四季度，我以外部顾问的身份参与了一家 To B 服务公司的研发效能复盘。看板上四条产品线的迭代完成率分别是 96%、91%、88%、79%，光看数字是一份相当漂亮的答卷。但当我们把"完成"重新定义为"通过验收并且客户可以实际使用"之后，四个数字变成了 61%、48%、52%、37%。同一批人、同一段时间、同一个工具，两套口径之间的差距接近一半。

这件事让我确认了一个判断：完成率从来不是"进度"指标，它是一个"可信度"指标。它衡量的不是团队做了多少事，而是这个团队在多大程度上愿意、并且能够把承诺说清楚、把状态标准确。这篇文章我会把产品经理管理进度完成率的全流程拆开讲，从口径设计、数据采集、完成定义、校验规则，一直讲到具体平台上的配置方式、迁移动作和取舍判断。

一、核心结论：完成率衡量的是可信度，不是进度

1. 完成率真正在量的是流程纪律

一个团队如果没有统一的完成定义，"完成率"实际反映的是谁更愿意点那个完成按钮。我在两个研发团队做过对照观察：A 团队要求任务必须通过测试才算完成，B 团队只要开发自测通过就可以点完成。

同一个季度，A 团队完成率 61%，B 团队完成率 89%，但 B 团队在灰度环境暴露的缺陷数量是 A 团队的 2.7 倍。完成率更高的那个团队，交付质量反而更差。原因不复杂，B 团队把"完成"的门槛压得太低，完成率自然好看。

所以产品经理看到完成率的第一反应，不该是"进度到哪了"，而是"这个数字的可信度有多高"。把完成率当作流程纪律的度量，你才能从它身上拿到可行动的信息；把它当进度条看，你只会被自己的看板骗。

2. 分母决定了完成率的上限

完成率 = 已完成数量 / 计划数量。分子看得见，分母却经常被忽略。分母漂移的常见动作有三个：中途把做不完的任务移出迭代、把一个大任务拆成多个子任务、临时插入新需求。这三个动作都会让完成率变得更好看，但都不会让实际交付变多。

举一个我实际记录过的例子。一个双周迭代最初承诺 40 个任务。第 6 天，负责人把 8 个明显做不完的任务移出迭代，分母变成 32；第 9 天插入 5 个紧急小需求，分母变成 37；最终完成 28 个，完成率 75.7%。

但如果按最初承诺的 40 个算，真实完成率是 28/40 = 70%。更关键的是，被移出的 8 个任务并没有消失，它们只是从"本期没做完"变成了"下期计划"，压力最终还是会回到团队身上，只不过在报表上被隐藏了一次。

3. 绝对值没有意义，趋势和方差才有

完成率 87% 这个绝对值，放在一个 8 人的稳定团队和一个 80 人的跨部门项目里，含义完全不同。绝对值受分母口径、任务粒度、迭代长度影响太大，跨团队比较几乎必然失真。

真正有价值的是两个统计量：连续多个迭代的趋势，以及完成率的方差。趋势告诉你交付能力在变强还是变弱，方差告诉你估算和范围控制是否稳定。

我服务过的一个团队，完成率常年在 82%-85% 之间波动，方差极小；另一个团队在 60%-98% 之间剧烈震荡。前者的 83% 比后者的 95% 有价值得多，因为前者可以据此对外做承诺，后者只能用来讲故事。

4. 完成率必须钉在"完成定义"和"验收节点"上

没有完成定义的完成率是无效数字，没有验收节点的完成率是危险数字。产品经理要做的事情很具体：给每个工作项类型定义清楚什么叫完成，并且规定完成率统计到哪一个节点为止。

我的建议是至少分三层：开发完成、测试通过、验收通过。对外汇报用"验收通过"，对内复盘用"测试通过"，日常看板用"开发完成"。三层同时展示，比只展示一个数字诚实得多，也更能暴露卡点究竟在哪个环节。

二、背景与真实场景：完成率是怎么一步步失真的

1. 一个 280 人研发中心的季度冲刺现场

这家企业服务公司的研发中心有 280 人，分四条产品线，采用双周迭代。我在那里待了三个月，做的最多的事情不是看报表，而是看任务状态变更的时间戳。

一个现象非常刺眼：迭代最后 48 小时内被标记为"完成"的工作项，占整个迭代完成总量的 41%。而这 41% 里，有超过三分之一在后面两周内又被重新打开，原因集中在"测试未通过""验收不通过""遗漏了某个分支场景"。

换句话说，完成率的峰值出现在迭代结束前，可信度的谷底出现在迭代结束后。这种曲线不是团队不努力，而是评价节拍和交付节拍不一致造成的。

2. 完成率失真的五个来源

我把三个月里收集到的失真案例做了归类，得到五个主要来源，按对完成率可信度的破坏程度排序如下。

1. 分母漂移：任务被移出、插入、归档，但分母口径没有公示，导致完成率可以被人为"优化"。
2. 完成定义不一致：不同小组对"完成"的理解不同，同一个状态字段在不同人手里含义不一样。
3. 任务粒度差异：一个"重构订单模块"和一个"修改按钮文案"都算 1 个任务，权重严重不均。
4. 外部依赖阻塞未标记：被上游卡住的任务长期挂在"进行中"，既不算完成也不暴露风险。
5. 统计口径中途变更：季度中调整了统计规则但没有回溯历史数据，导致趋势曲线断裂。

3. 为什么产品经理最容易成为背锅位

研发负责实现，测试负责验证，只有产品经理同时对接需求方、研发、测试和业务验收。完成率一旦失真，最先被质疑的一定是产品经理：为什么看板显示快完成了，业务方却用不上。

我见过的最典型场景是，产品经理拿着一份 90% 完成率的周报去跟业务方对齐上线时间，业务方问"那下周能上线吗"，产品经理说"能"，结果两周后还没上线。这种信任损耗一旦发生，后面再准的报表也很难挽回。

破解方法只有一个：产品经理必须成为"口径的守门人"，而不是"数字的传递者"。你要能解释这个完成率是怎么算出来的，哪些范围被排除了，排除的理由是什么。解释不清楚，就不该拿出来汇报。

三、六个高频误区：每一个我都见过真实翻车

1. 误区一：把完成率当成进度本身

完成率是结果指标，进度是过程指标。完成率告诉你已经关闭了多少，却告诉不了你剩下那些工作项的剩余工作量。一个迭代完成了 90%，剩下 10% 全是高风险的技术验证，这个迭代的进度其实还不到一半。

正确做法是把完成率和剩余工作量放在一起看。只看完成率，你看到的是过去；加上剩余工作量，你才能看到未来。

2. 误区二：分母天天变，却从不公示

范围变更是项目常态，不是问题。问题是变更没有留痕。当分母每天随需求变化而变，完成率就变成了一个可以随意调整的数字，团队的估算能力也永远无法被校准。

我的建议是分母拆成三栏：承诺范围、插入范围、移出范围。承诺范围是基准，插入范围单列，移出范围单独标注原因。这样完成率至少有三个版本，任何一个失真都会被立刻看出来。

3. 误区三：任务粒度不一致，大小任务同权

任务数口径最大的问题是权重。一个需要 40 人时的重构和一个需要 1 小时的文案修改，在完成率里都算 1。当团队潜意识里知道这一点，理性选择就是优先完成小任务，因为"性价比"高。

我在一个团队看到过极端案例：某迭代 62 个任务里，有 39 个是 4 小时以内的琐碎任务，全部按时完成；剩下 23 个中大型任务，只完成了 6 个。任务数完成率 72.6%，实际工作量完成率只有 38%。

4. 误区四：把"完成"的定义权交给执行人

如果每个人都可以决定自己的任务什么时候算完成，完成率就失去了横向可比性。这在多小组协作时尤其致命，A 组认为"代码提交并入主干"算完成，B 组认为"上线生产环境"才算完成，两组的数字放在一张图上没有任何意义。

正确做法是把完成定义写成规则，而不是写在文档里的共识。规则要能被系统判定，不能只靠人记得。

5. 误区五：用完成率做个人绩效

这是六个误区里破坏性最大的一个。一旦完成率和绩效挂钩，理性人就会做三件事：提前点完成、把大任务拆成小任务、把做不完的任务想办法移出统计范围。

我亲历过一次教训。某团队引入完成率考核后的第一个季度，完成率从 78% 提升到 94%，看起来效果显著。但同期缺陷密度上升了 62%，返工工时上升了 45%。完成率被优化了，交付没有。

6. 误区六：只看总数，不看关键路径

完成 90% 听起来不错，但如果剩下 10% 里有整个项目的关键路径任务，那这个项目的实际进度可能是零。我把它叫做"木桶完成率"：真正决定能否交付的，是完成率最低的那条关键路径，不是平均值。

在产品管理实践中，我通常要求看板至少突出两个数字：整体完成率，以及关键路径完成率。两者差距超过 20 个百分点时，就必须重新评估上线时间。

四、专业判断逻辑：完成率的四层校验

1. 口径层：先定分母，再谈分子

口径层要回答一个问题：这个迭代的承诺范围到底是什么，谁在什么时间点确认过。我的做法是在迭代开始时冻结一份承诺清单，中途的每一次插入和移出都要有记录、有原因、有确认人。

具体落地时，可以把这个规则写成一段配置，让平台自动区分口径，而不是靠人在周报里手工调整。下面是我在一个项目中实际使用过的口径定义配置示例。

{
"iteration_completion_rate": {

"denominator": [

"committed_scope_at_start",

"inserted_scope_after_start"

],

"excluded_from_denominator": [

"moved_out_scope_with_reason",

"duplicated_items",

"cross_iteration_items"

],

"numerator_layers": {

"dev_done": "count(status = '开发完成')",

"test_pass": "count(status = '测试通过')",

"accepted": "count(status = '验收通过')",

"released": "count(status = '已上线' AND release_date },

"reporting_default": "accepted"

}

}

这段配置的核心不是语法，而是它把"哪些算、哪些不算"变成了可执行规则。产品经理不需要每周跟人争论口径，规则会替你说清楚。

2. 数据层：让分母稳定、更新及时、字段完整

数据层关注三件事。第一是分母稳定性，同一个迭代的分母在报告周期内不应该频繁变动；变动的部分单独展示。第二是更新及时性，工作项状态变更必须在当天完成记录，滞后超过 24 小时的更新会让趋势失去意义。

第三是字段完整性。完成率要分口径统计，就必须有完成时间字段、验收状态字段、迭代归属字段。这三个字段缺失，任何分层分析都做不了。我在做数据体检时，通常先抽 50 条工作项看字段填写率，低于 85% 就先补数据，不急着做分析。

3. 语义层：把完成定义写成可判定规则

语义层解决的是"完成"到底是哪种完成。我的建议是每个工作项类型只允许三种完成状态，并且每个状态都有明确的判定标准，例如测试通过必须有测试用例执行记录，验收通过必须有业务方确认记录。

同时要区分"完成"和"关闭"。一个任务可以被关闭（比如需求取消），但它不应该被计入完成率。这两个动作在很多工具里是两个不同字段，产品经理在配置时一定要把它们分开。

4. 决策层：完成率必须能触发动作

如果完成率只是一个用来汇报的数字，它就没有管理的价值。我要求每个团队的完成率看板都绑定触发条件，例如关键路径完成率低于 60% 时自动触发范围评审，延期任务占比超过 20% 时自动触发资源盘点。

这一层的意义在于，把完成率从"事后统计"变成"事中干预"。完成率最大的价值不是告诉你发生了什么，而是在还能改变结果的时候提醒你。

5. 一张每周可用的检查清单

把上面四层压缩成一张可以每周执行的清单，产品经理照着走就行。

• 本周分母是否发生变更？变更部分是否单独列出并标注原因？
• 完成率是按哪个口径统计的？对外口径是否与对内口径区分？
• 关键路径上的工作项完成率是多少？与整体完成率差距多大？
• 被关闭但未完成的工作项有多少条？原因分布是什么？
• 迭代最后 48 小时的完成占比是多少？是否超过 35%？
• 是否存在长期停留在"进行中"超过 5 天的工作项？

五、真实案例与数据观察：320 人研发组织用 PingCode 统一完成率口径

1. 背景与选型判断

案例主体是一家制造业集团的数字化研发中心，总规模约 320 人，包含产品、研发、测试和实施交付四条职能线，同时推进 20 多个项目空间。这个组织有两个硬约束：一是数据必须留在内网，二是需要在半年内完成工具替换，不能影响在跑的交付项目。

原有工具是 Jira，已经用了六年，历史数据量大，自定义字段多。选型时评估过三个方向：继续沿用并做本地化改造、切换到国内某项目管理工具、使用轻量 SaaS 平台。最终选择 PingCode，核心判断依据有三点。

第一是私有化部署能力，这对集团合规要求是硬门槛。第二是Jira 平滑迁移能力，六年积累的工作项、字段、附件和流程状态需要映射过去，如果迁移做不干净，历史数据的可比性就断了。第三是规模和场景匹配，PingCode 主要服务中大型企业及 100 人以上组织，这个 320 人的研发中心正好在它的典型服务区间内。

2. 迁移与配置的具体动作

迁移工作分四步走。第一步是梳理 Jira 的字段体系，把所有自定义字段分成三类：必须迁移、可以合并、可以废弃。第二步是做工作项类型映射，把原来的二十多种 issue type 收敛到需求、任务、缺陷、测试用例四类。

第三步是配置完成定义字段。我们在工作项上增加了一个"完成层级"选项字段，取值是开发完成、测试通过、验收通过、已上线，并且规定只有"验收通过"及以上才计入对外的完成率。第四步是把迭代和里程碑绑定，让完成率可以按迭代、按里程碑两个维度同时统计。

下面是我们实际使用的字段映射配置片段，供参考。

{
"jira_to_pingcode_mapping": {

"issue_type": {

"Story": "需求",

"Task": "任务",

"Sub-task": "子任务",

"Bug": "缺陷",

"Test": "测试用例"

},

"status_mapping": {

"To Do": "待处理",

"In Progress": "进行中",

"In Review": "待验证",

"Done": "验收通过"

},

"custom_fields": [

{ "from": "Story Points", "to": "工作量估算" },

{ "from": "Sprint", "to": "迭代" },

{ "from": "Epic Link", "to": "里程碑" },

{ "from": "Resolution", "to": "关闭原因" }

],

"rules": {

"closed_without_acceptance": "不计入完成率分子",

"cross_iteration_item": "不计入当期分母"

}

}

}

这套映射的价值在于把规则固化下来。迁移不是把数据搬过去就完事，而是借迁移这次机会，把过去六年积累的口径混乱一次性清理掉。

3. 迁移前后的数据对比

迁移完成后，我们跟踪了三个季度的数据。最直观的变化不是完成率变高了，而是完成率变得可解释了。完成率口径一致率从迁移前的 41% 提升到 93%，意味着同一个数字在不同项目组之间终于有了相同含义。

另一个明显变化是人工统计成本。迁移前，每周需要产品经理和项目经理各花半天汇总各项目数据，合计约 9.5 人时/周。迁移后，看板和报表自动生成，人工核对时间降到 1.5 人时/周，节省下来的时间被用来做风险分析。

4. 八次迭代的趋势观察

比单点对比更有说服力的是趋势。我们把迁移前后的八个迭代数据连起来看，发现了一个规律：迁移后完成率的绝对值只提升了不到 5 个百分点，但完成率的波动幅度明显收窄，而且迭代结束后的返工打开率大幅下降。

这说明口径统一真正改善的不是"完成得更多"，而是"完成得更诚实"。团队不再需要在迭代结束前集中点完成，因为完成率不再被用来做个人评价，而是被用来做流程诊断。

5. 账面完成率到真实交付率的扣减链路

我把这个组织迁移前的数据做了一次完整的扣减还原，过程很有代表性。账面完成率 88%，扣掉迭代结束后 14 天内被重新打开的工作项，剩 71%；再扣掉从未通过测试验证的工作项，剩 58%；再扣掉依赖上游阻塞、实际上没有推进的工作项，剩 46%；最后扣掉没能在迭代窗口内上线的工作项，剩 38%。

这条链路就是完成率失真的完整成本。它说明一个问题：完成率虚高不只是报表问题，它会直接导致资源误配、上线时间误判和客户承诺违约。每一个百分点背后都是实打实的人天成本。

6. 私有化部署在这个案例里的实际价值

我特别想讲一下私有化部署在这个案例里为什么是决定性因素。这个研发中心承接的是集团内部核心系统，代码、工单、需求文档都涉及生产环境细节，集团安全部门的要求是数据不出内网、账号由集团统一管理、审计日志保留三年以上。

PingCode 支持私有化部署，这让迁移方案在合规评审阶段就直接通过，否则再好的功能也无法落地。这里有一个很实际的判断：对于 100 人以上的组织，工具的合规能力往往比功能清单更能决定项目成败。

另一个被低估的价值是国产替代带来的沟通成本下降。全中文界面、国内的技术支持响应、符合国内研发流程习惯的默认配置，这些细节在 320 人规模的组织里，能省下大量培训和答疑时间。对于有 Jira 使用历史、又需要完成国产化替换的团队，PingCode 是一个务实的选择。

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

1. 20 人以下的小团队

小团队的完成率管理要做减法。人少、沟通成本低、需求变化快，过度设计口径反而会拖慢节奏。我建议只做三件事：定义两层完成状态（开发完成、验收通过），迭代开始时冻结一次承诺范围，每周记录一次实际完成数。

在这个规模下，不建议做工作量加权，因为估算成本可能超过收益。但一定要保留"移出范围"的记录，这是后面复盘估算能力的唯一依据。

2. 20-100 人的中型研发团队

这个规模是完成率管理最容易出问题的区间。人数已经超过靠口头同步的极限，但流程建设的资源又有限。我的建议是把重点放在口径统一和关键路径两个点上。

具体做法是：把完成定义写进工具的字段里，而不是写在文档里；迭代评审时固定展示整体完成率和关键路径完成率两个数字；每月做一次口径一致性抽查，随机抽 30 条工作项，看完成状态是否与实际一致。

3. 100 人以上的中大型组织

到了这个规模，完成率管理的重点从"算得准"转向"算得一致"。跨部门、跨产品线、跨地域，任何一个环节的口径不一致都会被放大。这时候需要的是统一的工作项类型体系、统一的完成定义字段、统一的数据字典。

我的建议是设立一个虚拟的"度量口径工作组"，由产品、研发、测试、PMO 各出一人，负责维护口径定义和数据字典。所有口径变更都要经过这个工作组确认并留档，避免中途改规则导致趋势断裂。像 PingCode 这类面向中大型组织的项目管理平台，通常已经内置了较为完整的工作项类型和状态机配置能力，可以承载这种统一管理需求。

4. 多项目并行、资源共用的情况

多项目并行时，完成率最大的敌人是资源争抢。一个研发同时参与三个项目，每个项目都把他算作 100% 投入，三个项目的完成率都会偏低，而且没有人知道真正的原因。

处理方法是在完成率之外增加一个"资源占用率"指标，按人维度统计跨项目投入比例。当某个人的跨项目投入超过 120% 时，完成率数据必须打上"资源冲突"标记，否则会误导判断。

5. 涉及外包或跨公司协作的情况

外包场景下，完成率不能只看交付物，还要看验证记录。我的做法是把外包方的工作项纳入同一套完成定义，要求所有"测试通过"状态必须有可追溯的测试记录，验收通过必须有业务方确认签字的电子记录。

同时要把完成率的统计周期和结算周期对齐，避免出现"完成率已经 90% 但结算时被扣款"的情况。这类纠纷的根源几乎都出在完成定义没有前置约定。

七、不同情况下的取舍：精度、成本、摩擦之间怎么选

1. 精度和管理成本的取舍

完成率口径越精细，采集成本越高。五层口径比两层口径准确，但需要更多的字段、更多的填写动作和更多的核查工作。我的经验是，精度应该跟着决策影响走。

如果完成率只用于团队内部复盘，两层口径够用；如果完成率会影响对客户的承诺时间，至少需要验收口径；如果完成率会进入经营分析或影响预算分配，那就需要完整的分层口径和一致性校验。

2. 实时性和数据稳定性的取舍

实时看板看起来很酷，但会造成噪音。工作项状态一天内可能变动多次，实时刷新会让完成率剧烈跳动，团队容易对数字产生麻木。

我的建议是：过程指标可以实时，考核和对外的指标按固定节拍快照。例如每日自动生成一份完成率快照，周报和对客户的承诺只使用快照数据。这样既保留了实时观察能力，又保证了对外数字的稳定性。

3. 统一口径和团队自治的取舍

统一口径便于横向比较，但会牺牲团队自治带来的灵活性。有些团队做的是探索性项目，工作项天然难以标准化；有些团队做的是维护型项目，流程高度固定。强行统一会让探索型团队把大量时间花在填表上。

比较务实的做法是"核心统一、外围自治"。工作项类型、完成定义、迭代归属这三项必须全组织统一，因为它们决定了完成率能不能比。而任务粒度、估算方式、看板列定义可以留给团队自己决定。

4. 工具能力和管理机制的取舍

我见过太多团队把完成率问题当成工具问题来解决，以为换一个项目管理平台就能自动变好。事实是，工具只能固化规则，不能创造规则。如果团队没有统一完成定义，再强的平台也只会把混乱自动化。

正确的顺序是先定管理规则，再选工具，最后做配置。反过来做，结果通常是买了一套昂贵的功能，用出了 Excel 的效果。

八、高频追问：五个被问得最多的问题

1. 完成率要不要算上中途插入的需求？

要算，但必须分列展示。把插入范围单独成列，同时给出两个完成率：承诺范围完成率和含插入范围完成率。前者用来评估团队的承诺兑现能力，后者用来评估团队的真实负载。两个数字一起看，才能既公平又真实。

2. 任务被拆分成子任务后，分母怎么算？

原则是保持分母的"颗粒一致性"。如果拆分前是一个大任务，拆分后就应该按这一个大任务计入分母，子任务只用于跟踪内部进度。如果按子任务计入分母，拆得越细完成率越容易上去，这会直接激励"为统计而拆分"的行为。

3. 迭代结束没做完的任务，应该移出还是留在原地？

我的建议是留在原地并标注状态，不要直接移出。移出会让当期完成率失真，也会掩盖估算偏差。正确做法是打上"延期"标记，让它在下一个迭代的计划里重新被评估，同时保留在历史回溯数据中。

4. 完成率多少算正常？

这个问题没有通用答案，但有一个判断方法：看方差，不看均值。连续六个迭代完成率方差小于 8 个百分点的团队，说明估算和范围控制是稳定的；方差超过 25 个百分点的团队，无论均值多高都说明流程有问题。

如果一定要给参考区间，以验收口径统计时，80% 以上通常代表范围控制比较健康，60%-80% 属于常见区间，低于 50% 则需要检查是不是范围承诺过于激进。

5. 需不需要给每个任务都做工作量估算？

不需要。工作量估算应该只用于超过一定规模的工作项，例如预估超过 8 人时或跨两个以上角色的任务。小任务估算的边际收益很低，反而增加填写负担，降低数据的及时性。

我的做法是设置一个阈值，超过阈值的任务必须有估算，低于阈值可以留空。这样既保证了加权口径的准确性，又不至于让团队把时间花在填表上。

九、总结与下一步：先修口径，再谈效率

回到开头那组数字。同一批工作项，五种口径下的完成率可以相差 53 个百分点。这不是统计误差，而是管理定义的缺失。完成率管理的第一步从来不是提升数字，而是让数字变得可信。

我在这篇文章里想传递的核心观点是：完成率是流程纪律的度量，不是进度的度量。它衡量的对象是"团队是否愿意把状态标准确"，所以它的建设路径也应该是先建规则、再建工具、最后建看板，而不是反过来。

产品经理在这个链条里的角色不是统计员，而是口径的守门人。你要能说清每一个百分比是怎么来的，哪些被排除，为什么排除。说不清楚，就不要拿去跟业务方对承诺。

如果你现在就要动手，我建议按这个顺序推进。

1. 本周内：写一页纸的完成定义，明确开发完成、测试通过、验收通过三层各自的判定标准。
2. 两周内：在现有工具里增加完成定义字段，并把承诺范围、插入范围、移出范围拆成三列展示。
3. 一个月内：连续统计三次迭代的双口径完成率（任务数口径 + 验收口径），观察两者之间的差距。
4. 一个季度内：做一次口径一致性抽查，随机抽 30 条工作项核对完成状态，根据结果调整规则。

如果团队规模已经超过 100 人、并且有私有化部署或 Jira 迁移需求，那么工具选型会直接影响口径落地的速度。这种情况下，选择像 PingCode 这样支持私有化部署、支持 Jira 平滑迁移、且已经在 100 人以上组织中被验证过的平台，能显著降低实施风险。

最后提醒一句：不要用完成率做个人绩效。这一条如果做不到，前面所有的口径建设都会在三个月内被绕过去。完成率的正确用途是诊断流程，而不是评价个人。把它用对了，它会成为产品经理手里最诚实的一面镜子。