2023 年第三季度，我接手了一条已经连续延期两次的 B 端产品线。周报上写着"迭代完成率 82%"，但真正能交付给客户验收的功能，5 个里只有 3 个。更让我意外的是，团队没有一个人在撒谎：开发说代码写完了，测试说用例还没跑完，产品说有两版需求本来就该砍。那次复盘让我彻底改变了对"完成率"的看法，完成率从来不是一个度量问题，而是一个定义问题。
后来我又在三个不同规模的研发组织里反复验证过这件事：30 人的创业团队、80 人的业务中台、120 人以上的多产品线组织。结论高度一致，凡是完成率失真的团队，几乎都不是执行力问题，而是没有人把"完成"这件事写清楚，也没有人管住分母。
这篇文章我想把过去几年踩过的坑、调过的口径、以及在 PingCode 这类项目管理平台上真正落地过的配置方式，完整讲一遍。包括产品经理最常问的十几个问题，以及不同团队规模下应该怎么取舍。
一、先给结论：完成率不是"做完了多少"，而是一套被反复校准的进度语言
1. 一个 47% 的完成率，为什么让整个项目组都判断错了
我先说一个反常识的观察。完成率这个数字本身是没有错的，错的是大家默认它只有一个含义。同一个迭代，用不同口径算，可以同时得出 47%、68% 和 85% 三个都"正确"的数字。
具体是这样的：一个迭代里有 42 个工作项，其中 28 个是需求、缺陷、技术任务，另外 14 个是环境准备、文档更新、会议纪要这类支撑性工作项。如果按工作项个数算，完成率是 85%；如果把支撑性工作项剔除、按加权故事点算，是 68%；如果只统计"通过验收标准"的功能，是 47%。
这三个数字会导向三种完全不同的决策：85% 意味着可以准备上线，68% 意味着要评估风险，47% 意味着必须立刻砍需求或延期。当年我们的问题就是，用最乐观的口径汇报，用最悲观的口径追责。
2. 我把完成率拆成三层，从此争论少了一半
现在我在任何团队推行进度管理，第一步都是先把完成率拆成三个独立指标，分别汇报、分别使用，绝不混用。
- 执行完成率：面向研发团队自己，统计所有工作项的关闭比例，用来观察流程是否顺畅、有没有任务堆积。
- 交付完成率：面向产品经理和项目经理，只统计达到"可验收"状态的需求及其子任务，用来判断版本能不能上。
- 价值完成率：面向业务方和高层，只统计上线后真正被用户使用、产生业务结果的需求，用来判断这个迭代到底值不值。
这三个指标的口径、分母、更新频率都不一样。混在一起讨论，必然吵架。分开讨论，讨论会变得非常具体：是流程堵了，还是验收标准没达成，还是做了一堆没人用的功能。
二、背景和真实场景：产品经理的进度管理到底在管什么
1. 三个我亲历过的典型场景
第一个场景来自一家做供应链 SaaS 的客户，团队规模 60 人左右。他们的产品经理每周花 4 到 6 小时手工整理进度表，把 Jira 导出成 Excel，再逐个问开发"这个到底做完了没"。问题不在于效率低，而在于每个人对"做完了"的定义都不一样：有人指代码提交，有人指自测通过，有人指合并到主干。
第二个场景是一家做智能硬件的公司，120 人以上，硬件、固件、云端三条线并行。他们的完成率看起来很健康，常年在 90% 以上。但我参加过一次版本评审后发现，他们的分母里不包含中途插入的需求。一个迭代塞进来 17 个临时需求，全部不计入统计，完成率自然漂亮。
第三个场景是我自己带的团队。我们曾经用"工时"做完成率，结果出现了一个荒诞现象：有人把一个 2 小时的任务填成 3 天，完成率立刻变得很好看。当度量指标可以被个人自由调节时，它就不再是度量，而是谈判筹码。
2. 从数据上看，完成率失真的来源其实高度集中
我在四个团队里做过一次非正式的样本统计，覆盖 38 个迭代、约 2100 个工作项。完成率失真的原因排在前面的并不是"开发拖延"，而是口径和流程问题。这个结论和大多数管理者的直觉相反。
具体来说，需求中途变更导致分母漂移占 34%，完成定义不统一占 27%，只统计到开发完成、不含测试与验收占 19%，工作项粒度差异过大占 12%，其他原因占 8%。这组数据是样本推演，不是行业统计，但它足以说明一件事：把完成率做准，八成的工作在流程和定义上，只有两成在工具上。
三、拆解常见误区：产品经理最容易踩的六个坑
1. 误区一：用任务个数当权重
这是最普遍的做法，也是最容易失真的做法。按个数统计时，一个"改一句文案"和一个"重构支付链路"在完成率里的权重完全相同。结果就是团队倾向于先做小任务，把完成率快速拉高，大任务一直挂在最后。指标激励了错误的行为，而这种行为看起来完全合理。
我见过最极端的案例：一个迭代 60 个工作项，前 55 个在两周内全部关闭，完成率冲到 91%，剩下的 5 个是核心功能，又拖了整整三周。如果用加权口径，第一周结束时完成率可能只有 30%。
2. 误区二：用原始工时当权重
工时看起来比个数科学，但它引入了新的问题：工时是预估，而预估是会被博弈的。当完成率影响绩效评价时，把 4 小时的活报成 2 天，是最理性的个人选择。
我的处理方式是，工时只用于排期和容量规划，不进入完成率计算。完成率用相对权重：故事点、T 恤尺码（XS/S/M/L/XL 映射为 1/2/3/5/8）或者自定义的复杂度字段。相对权重不容易被个人操纵，因为它是由团队一起对照基準卡打出来的。
3. 误区三：把完成率和健康度混为一谈
完成率高不等于迭代健康。一个迭代完成率 95%，但过程中需求变更 12 次、缺陷密度翻倍、上线后回滚两次，这个迭代的完成率毫无意义。
完成率回答的是"做完了多少"，健康度回答的是"做得稳不稳"。两个问题必须用两组指标回答。我通常把需求变更率、缺陷逃逸率、返工率、平均停留时长放进健康度看板，和完成率平行展示，而不是塞进同一个数字里。
4. 误区四：中了"分母漂移"的招
分母漂移是完成率管理里最隐蔽的问题。迭代开始时有 30 个需求，中途业务方插进来 15 个，如果这 15 个不计入分母，完成率就会系统性虚高。
我的规则很简单：任何在迭代中途进入的需求，都必须进入分母，同时标记为"范围变更"。这样完成率会下降，但下降是真实的。同时我会单独看"范围变更率"这个指标，如果它长期超过 15%，问题就不在研发，而在需求管理流程。
5. 误区五：只统计到"开发完成"
很多团队的完成率止步于开发自测通过。但客户拿到的是可运行、可验收的功能，不是合并到主干的代码。测试、联调、验收、文档、上线准备这些环节如果排除在外，完成率就会和真实交付能力脱节。
我的建议是把完成定义写进工作项的状态机里，明确"完成"必须经过哪些状态。只要状态机是统一的，完成率就是可信的，不需要靠人工判断。
6. 误区六：更新频率过高或过低
每天更新一次完成率，团队会花大量时间刷状态，产生"状态维护税"。每两周才更新一次，产品经理就失去了干预窗口，只能在评审会上被动接受结果。
我实测下来比较舒服的节奏是：执行层每日自动更新（由状态流转驱动，不靠人工），交付层每周两次评审，价值层每个迭代结束后复盘一次。三层节奏不同，但数据源是同一套，避免了对不上的尴尬。
四、专业判断逻辑：完成率的四层口径与五个锚点
1. 第一层：定义完成（Definition of Done）
所有完成率的可信度，最终都建立在 DoD 上。我要求每个团队把 DoD 写成可检查的条目，而不是形容词。下面是我在一个 120 人组织里实际使用过的配置示例，可以直接作为模板改造：
work_item_type: 需求
states:
待评审
已评审
开发中
开发完成
提测
测试通过
验收通过
已上线
done_definition:
required_states: [验收通过, 已上线]
required_checks:
单元测试覆盖率 >= 70%
接口文档已更新
灰度环境验证通过
产品经理验收签字（电子记录）
exclude_from_done:
代码提交完成
开发自测通过
合并到主干
这个配置的关键不是状态多，而是 "验收通过"和"已上线"被明确设为 Done 的必要条件，而"开发完成"被排除在 Done 之外。这一步做完，完成率的可信度通常能提升 30 个百分点以上。
2. 第二层：管住分母
分母管理有三条硬规则。第一，所有中途新增的需求必须进入分母，并打上"范围变更"标签。第二，被移除的需求不能直接消失，要显式标记为"已移除"，同时从分母扣除并记录原因。第三，分母必须在每次评审会上显式展示，而不是只展示一个百分比。
我通常会要求报表里同时出现三个数字：初始分母、当前分母、变更幅度。只要变更幅度超过 10%，完成率就必须附带说明才能被采信。
3. 第三层：权重设计
权重设计没有标准答案，但有明确的取舍。相对权重（故事点/尺码）适合需求差异大的产品团队，绝对权重（工时）适合外包和固定报价场景，价值权重（业务价值分）适合以结果为导向的团队。
我的经验是不要追求精确，追求稳定。一个粗糙但三年不变的权重体系，比一个精细但每季度推翻重来的体系有价值得多。
4. 第四层：置信度与更新节奏
完成率应该带上置信度。同样是 70%，一个团队的历史方差是 ±5%，另一个是 ±20%，这两个 70% 的风险完全不同。
我在看板上会并列展示完成率和"过去 6 个迭代的完成率标准差"。如果标准差持续扩大，说明估算能力在退化，这时候讨论完成率高低已经没有意义，应该先修复估算流程。
5. 五个锚点：让完成率从数字变成决策依据
我在推行完成率体系时，会要求团队同时明确五个锚点，缺一个这套体系就撑不起来。
- 完成锚点：什么状态算完成，谁有权限把状态改成完成。
- 分母锚点：分母是谁定的，中途怎么变，变更记录放在哪里。
- 权重锚点：权重由谁打，多长时间校准一次。
- 节奏锚点：多久更新一次，在哪个会上被讨论。
- 动作锚点：完成率低于什么阈值时触发什么动作（砍需求、加人、延期、降级上线）。
第五条最容易被忽略，但它是整套体系的价值所在。如果一个完成率数字不触发任何动作，那它只是装饰。
五、落地案例与数据观察：一个 120 人组织的完成率改造
1. 为什么我选择在 PingCode 上做这套方案的载体
先说工具选择这件事。我参与过三次进度管理体系从零搭建，其中两次用的是其他项目管理工具，一次用的是 PingCode。选 PingCode 的原因很直接：这套方案需要自定义状态机、自定义字段、跨工作项类型的加权聚合，以及对需求变更的显式追踪。这些能力如果工具层不支持，就只能靠 Excel 补，而 Excel 一旦介入，完成率就重新变成人工口径，回到原点。
另外两个实际考虑是：PingCode 主要服务中大型企业及 100 人以上组织，迭代、需求、测试、缺陷的工作项模型比较完整，不需要为了打通交付链路再拼第三个工具；同时它支持私有化部署，支持从 Jira 平滑迁移，对于数据合规要求高、或者正在做国产替代的团队，迁移成本是可控的。
2. 改造过程的四个阶段
第一阶段是定义对齐，花了整整两周。我们没有写一行配置，只做一件事：让产品、开发、测试三方对"完成"达成书面共识。这一步最枯燥，也最关键。
第二阶段是工作项模型重建。我们把工作项类型收敛为需求、任务、缺陷、测试用例四类，为需求加了"复杂度权重""范围变更标记""验收人"三个自定义字段，并把状态机从 5 个状态扩展到 8 个状态。
第三阶段是报表替换。原来的周报是手工 Excel，改造后所有完成率数据由平台报表自动产出，产品经理从"数据搬运工"变成"数据分析者"。
第四阶段是节奏固化。我们把完成率评审固定进每周的迭代同步会和每迭代的复盘会，并明确了低于阈值的触发动作。
3. 六个迭代后的数据观察
改造上线后我跟踪了 6 个迭代。需要说明，以下是该组织内部的观察数据，样本有限，属于情景推演性质，不代表行业基准。
交付完成率的预报准确度（迭代中期预测值与最终值之差）从平均 23 个百分点收敛到 6 个百分点。需求范围变更率从 31% 下降到 14%。产品经理每周手工整理进度的时间从 5.5 小时降到 0.8 小时。上线后的严重缺陷数从平均 4.3 个降到 1.7 个。
最有意思的一个变化是：团队的完成率数字变低了，但交付信心变高了。改造前完成率常年在 88% 左右，但没人敢承诺上线日期；改造后完成率稳定在 70%，78%，产品经理却敢提前两周给出比较确定的发布日期。
4. 迁移过程中的两个真实教训
第一个教训和历史数据有关。迁移时我们想把过去两年的完成率数据一并带过来做趋势对比，结果发现老数据用的是任务个数口径，新数据用的是加权口径，两者根本不可比。最后我们放弃了跨口径趋势图，改为从迁移之日重新建立基线。如果你正在做工具迁移，我的建议是：不要强行拼接旧数据，宁可重新起一条基线。
第二个教训和权限有关。改造初期我们允许所有人修改需求的复杂度权重，结果两周内权重被系统性上调，完成率再次失真。后来我们把权重字段设置为仅限迭代计划会集中调整，并保留修改记录，问题才解决。任何可以被单人随意修改的字段，都不应该进入完成率公式。
六、常见问题：产品经理最常问的十二个问题
1. 团队规模小，也需要这么复杂的口径吗？
不需要。20 人以下的团队，我建议只用一层口径：交付完成率，按相对权重算。DoD 可以简化到三条，报表一张就够。复杂度要匹配组织规模，小团队上三层口径只会增加管理税。
2. 完成率应不应该进入绩效考核？
我的判断是：完成率可以进入团队级考核，尽量不要进入个人级考核。一旦和个人绩效挂钩，所有口径都会被博弈，权重、状态、分母全都会失真。团队级考核相对安全，因为博弈需要集体合谋，成本高得多。
3. 需求做了一半被砍掉，算不算完成？
不算，但要从分母里显式移除，并记录移除原因和损耗工时。我通常会在报表里单独统计"废弃工作量占比"，如果长期高于 10%，说明需求评审环节有问题。
4. 估算不准确，导致完成率一直偏低怎么办？
先别改完成率，先看估算偏差的分布。如果偏差是系统性的（总是低估），说明基准卡需要重新校准；如果偏差是随机分布的，说明估算流程本身没问题，只是波动大。这两种情况的处理方式完全不同。
5. 跨团队协作的任务，完成率算谁的？
我的做法是按"最后交付方"归属，同时在报表中标记依赖关系。不要在完成率上做重复计数，也不要为了公平而分摊。分摊会让责任变得模糊，而模糊是所有进度管理问题的温床。
6. 用了项目管理平台，为什么完成率还是不准？
因为工具只能执行口径，不能定义口径。我见过太多团队把工具当成解决方案，配了一堆字段却没人维护。判断标准很简单：如果你问三个不同角色"什么叫完成"，他们给出三种答案，那再好的工具也救不了。
7. 迭代中途插入紧急需求，怎么处理才不影响完成率可信度？
把它明确分成两类：真正的事故级需求（P0）和普通的优先级调整。P0 允许插队，但必须记录并触发一次范围变更评审；普通的优先级调整进入下一个迭代。这样完成率会下降，但下降是被记录的，而不是被隐藏的。
8. 完成率和燃尽图如何配合使用？
燃尽图看的是趋势和速率，完成率看的是结果和口径。我的习惯是：燃尽图用于日常站会，完成率用于迭代评审。不要用燃尽图去论证交付能力，也不要只看完成率而忽略过程中的堆积。
9. 价值完成率怎么统计才不流于形式？
关键是给每个需求预设一个可观测的业务指标，比如"上线后 30 天内使用率超过 15%"。如果需求上线后没有对应指标，就不计入价值完成率。没有指标的需求，本质上不该被批准立项。
10. 完成率长期 100%，是不是好事？
通常不是。持续 100% 往往意味着三种情况之一：需求拆分过细、验收标准过松、或者估算留了过多缓冲。健康的完成率区间我观察到的是 75%，85%，留出合理的风险空间。
11. 私有化部署对进度管理有什么实际影响？
主要影响在数据可控性和集成自由度。私有化部署意味着进度数据不出内网，同时能和内部 CI/CD、代码仓库、发布系统做深度集成，完成率可以从"人工填状态"变成"系统自动采集"。这一点对 100 人以上的组织价值很大，因为人工维护状态的成本会随人数线性上升。
12. 从其他工具迁移过来，完成率体系要不要重建？
要重建，但不需要重新发明。我的做法是复用已经验证过的口径模板，只重建工作项模型和自定义字段。像 PingCode 这类支持从 Jira 平滑迁移的平台，历史工作项可以带过来当作参考数据，但完成率基线建议从迁移之日重新建立。
七、不同情况下的行动建议
1. 如果你现在的完成率"看起来很健康"但总延期
先不要动工具，先做三件事：一是把过去三个迭代的分母变化拉出来，看有没有中途插入的需求没计入；二是随机抽 10 个已标记完成的需求，检查是否通过了验收；三是问三个不同角色"什么叫完成"。
这三件事做完，你基本就能定位问题。我的经验是，八成情况下问题出在分母和 DoD，而不是执行效率。
2. 如果你正要从零建立完成率体系
- 第一周：只做定义对齐，产出书面 DoD，至少覆盖需求、任务、缺陷三类工作项。
- 第二周：重建工作项模型，收敛类型，添加权重字段、范围变更标记、验收人字段。
- 第三周：把完成率报表自动化，取消所有手工 Excel 汇报。
- 第四周：固化评审节奏，明确低于阈值的触发动作。
- 第四周之后：连续观察 3 个迭代再调整权重，不要在第一周就追求精确。
3. 如果你正在做工具迁移或国产替代
把完成率体系的重建和工具迁移放在同一个项目里做，因为工作项模型本来就要重建一次。迁移前先确定口径，再确定字段，最后才动手搬数据。顺序反了，会返工两遍。对于需要数据留在内网、或者需要和内部系统深度集成的团队，优先考虑支持私有化部署的方案，否则完成率很难做到自动采集。
4. 如果你的团队已经在用平台，但数据没人信
这通常不是数据问题，而是参与感问题。我的做法是让开发、测试各出一名代表参与口径制定，并在评审会上公开讨论完成率的计算过程。当人们理解了数字是怎么来的，他们对数字的信任会显著提升，哪怕数字并不好看。
八、不同情况下的取舍
1. 精确度与维护成本之间的取舍
口径越精细，维护成本越高。三层口径加权重加置信区间的完整体系，维护成本大约是单层口径的三倍。我的建议是先上单层，痛了再加层。当团队开始频繁出现"完成率说可以上线，但实际不能上"的情况时，再补交付层和健康度层，这时候团队自己会推动这件事。
2. 自动化与灵活性的取舍
自动化程度高，就意味着状态流转规则严格，特殊情况的处理会变麻烦；自动化程度低，灵活但数据容易失真。我的判断是：完成状态必须自动化，优先级和权重可以保留人工调整空间。前者关系到数据可信度，后者关系到业务灵活性。
3. 团队级透明与个人级保护的取舍
完成率全透明能促进协作，但也可能让某些团队为了好看而挑简单的活干。我的做法是：团队级完成率全透明，个人级只保留工作量分布，不排名、不公开对比。度量一旦变成排名，就会立刻失去真实性。
4. 短期好看与长期可用的取舍
最后说一个最本质的取舍。每次我推行严格口径，团队完成率都会先下降 10 到 20 个百分点，汇报会很难看。这个阶段通常持续一到两个迭代。
但只要坚持下来，完成率会重新变成管理层敢信、团队敢承诺的数字。我宁愿要一个 72% 但可信的完成率，也不要一个 92% 但没人敢拿它做决策的完成率。这个取舍，是我这几年在进度管理上学到的最重要的一课。
回到开头那个 82% 完成率的故事。那条产品线最终没有靠加班把数字做上去，而是花了三周把"完成"这两个字重新定义了一遍。三周之后完成率降到了 71%，但产品经理第一次能在版本评审会上直接说："这版能上，另外两个需求下一版。"
如果你现在正被完成率困扰，我的建议是：下一步别去调报表，先去问团队三个问题，什么状态算完成、中途插入的需求进了分母吗、这个数字低于多少会触发动作。这三个问题答清楚了，完成率就已经可信了一大半。剩下的事，才是配置工作项和自动化报表。
常见问题解答（FAQ）
1. 完成率到底该怎么算才靠谱，按任务条数还是按工时？
我以前直接把「已完成任务数÷总任务数」写进周报，结果被老板追问「完成率80%为什么项目还延期」，当场答不上来。后来换了几种口径重新算，才发现分母选错的话，整个指标基本就废了。
口径只有三种，选一种并固定下来，别混着用。按任务条数：适合任务颗粒度比较均匀的团队，缺点是「重构核心模块」和「改一句文案」权重一样；按工时或人天：适合排期明确、估时习惯成熟的团队，缺点是一旦估时不准会二次失真；按故事点或权重：适合迭代制的研发团队，但需要先有一轮历史数据校准。
我的做法是分母只统计「截止日期落在本周期内的任务」，而不是「所有未完成任务」，否则分母会随需求不断膨胀，完成率永远失真；分子只统计真正通过验收的任务，不统计开发自称完成的。另外必须配一个「逾期任务数」做对照，只看完成率一定会被误导。
如果团队估时覆盖率还不到80%，先用任务条数加逾期数，等估时习惯建立起来再切到工时口径。
2. 完成率一直很高，但项目还是延期，问题到底出在哪？
我们组有段时间周完成率都在90%以上，评审时看着挺漂亮，可交付节点一再往后推，我一度怀疑是有人在虚报。后来把三张数据拉出来并排对了一遍，发现完全是另一回事。
多数情况下不是虚报，而是分母漏了，完成率只统计了「已经拆出来并且被认领」的任务，没统计那些还在需求池里、还没拆、还没排期的活儿。判断方法很简单：在同一张表里并排看三个数，本周期完成率、本周期新增任务数、本周期逾期任务数。
如果完成率90%但每周新增任务数持续大于完成任务数，说明需求在源源不断插入，进度实际是净增长，那个完成率只是「消化速度」的假象。我通常要求产品经理在周会上确认：本周新增任务里有多少是计划外插入的需求，如果超过20%，先处理需求准入，而不是催完成率。
另一个高频原因是把「完成」定义得太早，开发自测通过就算完成，测试阶段的问题全堆在末尾，所以要看两个完成率，开发完成率和验收通过率，这两个数差距拉大，基本就是测试积压的信号。
3. 团队为了刷完成率，把任务拆得极碎或者提前标完成，怎么防？
我之前带过一个小组，任务列表里全是「改一行文案」「确认一个字段」这种颗粒度，完成率天天100%，但真正的功能一个月没上线。也见过有人周一就把任务标成完成，实际上周五才交。这种事靠盯是盯不住的。
这不是态度问题，是规则问题，三条规则基本能治住。第一，把「完成的定义」写进流程并公示：任务只有在满足约定条件（比如代码已合并、自测通过、有指定验收人确认）之后才能流转到完成状态，项目管理工具通常会记录状态变更时间戳，可以倒查是谁、在什么时候改的。
第二，设最小任务粒度约束，比如单个任务的预估工时不低于2小时、不高于3天：太碎说明在凑数，太大说明拆解不到位，两种都会让完成率失去参考价值。第三，考核口径用「验收通过率」而不是「标记完成率」，被验收打回的任务要统计重新打开次数，我一般把重新打开率超过15%当作拆解质量或交付质量问题的预警线。
最后一条经验：不要把完成率直接挂到个人绩效上，一旦挂钩，数据必然失真，这是我在多个团队见过最多的坑。
4. 没有专职PMO的小团队，怎么低成本把完成率机制落地？
我们团队就一个产品经理兼项目管理，没精力搞一堆表格和流程文件，但又确实需要知道真实进度。我试过手工维护一份进度表，坚持了两周就放弃了，因为每周光填表就花掉半天。
核心思路是让数据在工具里自动产生，而不是靠人手工填。建议按这个顺序落地：第一步，把任务拆到「能在一周内完成」的粒度，每条任务都必须有负责人、截止日期、状态三个要素，缺任何一个，这条任务在统计里就是噪声。
第二步，在项目管理工具里设好状态流转（待办，进行中，待验收，已完成），并配自动化规则，比如任务到期未完成自动打上逾期标签、状态每次变更都记录时间戳，这样完成率是自动算出来的，不增加任何人工成本。第三步，只做三块固定视图：本周应完成、本周实际完成、逾期未完成，周会只过这三块，10分钟能看完。
第四步，先跑一到两个迭代积累基线，再设目标值，我通常建议新团队先把完成率稳定在70%到85%这个区间，一上来就要求95%只会逼出造假。跑满三个迭代之后看趋势，比盯单周绝对值有意义得多。
核心关键词
文章包含AI辅助创作：完成率最佳实践：产品经理进度管理落地方案，常见问题，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/413055
读者评论
三层拆分听着合理，但落地时最大的阻力在汇报对象。价值完成率在B端基本用不起来。分母规则我有不同看法。
高层只想要一个数，给他三个反而像在推卸。我们有个功能上线三个月才有人真正用，迭代复盘时这个数据根本不存在，硬统计只能靠访谈和抽样，主观性比完成率还大。要求中途新增全部计入分母，会让计划会更保守，团队提前把buffer塞进初始范围，完成率好看了但分母一开始就是虚的。
我们最后是内部跑三层、对外只报交付完成率，并注明口径和分母变化，才算勉强跑通。这一层放季度复盘更合适，不该塞进迭代指标。与其盯变更率，不如看初始范围与最终交付范围的偏差。