去年 Q4，我帮一家 380 人的硬件+软件混合型公司做交付复盘。他们的项目管理平台里，四个研发部门的平均迭代完成率分别是 96%、94%、97%、95%，数字漂亮到可以直接放进季度汇报。但同一季度的客户承诺交付准时率只有 61%，有 7 个已经标记"完成"的需求，在验收环节被客户打回来重做。完成率和真实交付之间，差了 34 个百分点。
这不是个例。我在过去六年里接触过 40 多个 50 到 800 人规模的组织，几乎每一家在"进度管理从 0 到 1"的阶段都会撞上同一堵墙：把完成率当成一个统计动作，而不是一个口径设计动作。团队花两周时间做出一个漂亮的进度看板，三个月后没人看，半年后数据彻底失真。
这篇文章我想讲清楚三件事：完成率到底该怎么定义、从 0 到 1 的进度管理要按什么顺序搭、以及在什么情况下你应该主动放弃某种完成率口径。文中所有数据来自我参与的实际改造项目，涉及商业信息的部分做了脱敏和比例化处理。
一、先给结论：完成率从来不是"统计问题"，而是"口径问题"
如果你只从这篇文章带走一句话，我希望是这句：完成率做不对，90% 的原因不在工具，在你没定义清楚"谁的完成、什么算完成、按什么权重完成"。
1. 完成率必须分三层，混在一层就会失真
大多数团队只统计一层完成率，就是"任务完成率"。但任务完成率和交付结果之间隔着两道衰减，这两道衰减恰恰是项目负责人最该管的东西。
我在实践中固定使用三层口径，并给每一层配上不同的汇报对象和使用场景：
- 第一层，任务完成率：面向执行团队，回答"今天的工作推进了多少"。颗粒度是任务，更新频率是日或周。
- 第二层，交付物完成率：面向项目负责人，回答"这个里程碑能不能按期交付"。颗粒度是需求、用例、交付件，必须带验收状态。
- 第三层，价值完成率：面向业务方和管理层，回答"客户/业务目标达成多少"。颗粒度是业务结果，比如上线可用、客户签收、指标达标。
三层之间的衰减是常态，不是异常。在一个健康组织里，任务完成率 85%、交付物完成率 70%、价值完成率 55% 是合理的。如果三层数字几乎一样，通常说明口径没有真正分开，或者有人在中间做了美化。
2. 从 0 到 1 的进度管理，有严格的搭建顺序
我见过太多团队跳步：一上来就买工具、建看板、做燃尽图。结果三个月后看板变成摆设，因为前置的"状态定义"和"权重规则"根本没有共识。
正确的顺序是这样的四步，每一步都以前一步为前提：
- 统一状态定义：把"完成"从口头共识变成书面规则，明确谁有权把任务推进到"完成"。
- 统一颗粒度基线：规定任务拆分的最大工时上限，通常是 1 到 3 天。超过就强制继续拆。
- 统一加权规则：决定完成率是数个数还是算权重，权重按工时、按故事点还是按价值。
- 接入自动采集：把数据从人工填报切换到系统自动统计，让口径无法被手工绕过。
跳过的步骤越靠前，返工的代价越大。跳过第 1 步去做第 4 步，你会得到一套跑得飞快但统计垃圾数据的自动化系统。
3. 一张表看清四种进度管理成熟度
判断你的组织现在处在哪个阶段，可以对照下面这张表。它也是我每次进场做诊断时用的第一张工具。
| 成熟度阶段 | 完成率来源 | 典型问题 | 管理者能做的决策 |
|---|---|---|---|
| L0 无度量 | 口头汇报、周会感知 | 没人知道真实进度 | 只能靠经验拍板 |
| L1 有度量 | Excel 或工具手工填报 | 数字失真、口径不一 | 知道大致趋势，不敢用于考核 |
| L2 有节奏 | 统一口径 + 固定更新周期 | 颗粒度不均、阻塞不透明 | 可以识别风险项目并介入 |
| L3 有预测 | 自动采集 + 速率/趋势分析 | 对流程纪律要求高 | 可以预测交付时间并做资源调度 |
大多数组织卡在 L1 到 L2 之间，而卡点几乎总是口径而不是工具。如果你现在连"完成"的定义都没写下来，L3 的燃尽图和速率分析对你毫无意义。
二、真实场景：一个 132 人组织，完成率长期"稳定"在 78%
2022 年我以外部顾问身份介入一家做企业级 SaaS 的公司，研发体系 132 人，分 6 个 Scrum 团队，产品交付周期从承诺到上线平均 11 周。他们当时的进度管理方式是：平台里记任务，每周五各团队负责人手工填一个完成率到共享表格，PMO 汇总后发给高管。
1. 第一个坑：三家周报，三个口径
我把 6 个团队连续 8 周的填表记录拉出来对比，发现了明显的口径分裂。团队 A 的口径是"任务条数完成比例"，团队 B 的口径是"工时消耗比例"，团队 C 的口径是"故事点完成比例"，还有两个团队直接用了平台自带的完成率字段，但那个字段的默认算法是"状态为已完成的任务数 ÷ 任务总数"。
最要命的是第三个团队：他们的故事点估算由不同的人做，同一个功能，有的人估 3 点，有的人估 8 点。故事点完成率在这种基础上只能反映"谁估得小"，不反映"谁做得快"。
结果就是：同一周里，6 个团队的完成率可以横向比较，但这个比较毫无意义。PMO 每次汇报只能说"整体完成率 78%"，高管听了两年，其实没人知道这 78% 代表什么。
2. 第二个坑：任务颗粒度相差 11 倍
我随机抽取了各团队 200 个"已完成"任务，统计它们的实际工时。数据出来后会议室里安静了几秒：团队 A 的中位数是 0.6 天，团队 F 的中位数是 6.8 天，两者相差约 11 倍。
这意味着什么？用"任务条数"计算完成率时，一个 6.8 天的大任务和一个 0.6 天的小任务权重完全相同。谁把任务拆得细，谁的完成率就天然好看。这不是激励问题，这是数学问题。
3. 第三个坑：完成率好看，交付一直延迟
改造前的 12 个月里，这个组织的平均完成率是 78%，但平均交付准时率只有 52%。我做了进一步拆解，发现一个规律：迭代结束前 3 天，完成率会从 55% 左右快速跃升到 80% 以上。
这不是团队最后三天特别高效。真实原因是"完成"的判定标准被临时放宽了，开发自测通过就算完成，代码评审、集成验证、文档更新都被挪到了迭代之后。这些被挪走的动作最终在验收环节集中爆发，造成交付延迟和返工。
4. 改造后的结果：完成率降了，准时率涨了
我们用 5 个月做了完整的口径重构，核心动作是把"完成"重新定义为"通过内部验收"，并引入加权完成率。改造前后 6 个月的对比如下。
当时我在复盘会上说了一句话，被他们的研发 VP 抄在了白板上：你不需要一个好看的完成率，你需要一个能提前三周告诉你"这个项目要黄"的完成率。
三、拆解八个常见误区
下面八个误区，是我在 40 多个项目里反复见到的。它们有明确的出现顺序，通常是从第 1 个开始，逐层恶化。
1. 误区一：把完成率当成一个数字而不是一组分布
汇报里只写"整体完成率 82%"，这种表述掩盖了最关键的信息：是 6 个团队都在 82% 附近，还是 2 个团队 100%、4 个团队 73%？后者才是需要立即介入的状态。
我的做法是固定输出"完成率 + 团队区间 + 最低三个项目"的组合，而不是一个均值。
2. 误区二：任务颗粒度不设上限
没有上限，就会出现"一个任务两周没动"和"一天关掉 15 个任务"并存的局面。我给客户的硬性规则是：任何计划工时超过 3 天的任务必须继续拆分，除非它在技术上确实不可分割，且需要项目负责人书面确认。
3. 误区三：只看完成率，不看完成率的趋势
完成率是存量指标，趋势才是预测指标。两个项目完成率都是 70%，一个连续三周每周增长 8%，一个连续三周停滞，风险完全不同。前者大概率按期交付，后者基本确定延期。
4. 误区四：依赖人工填报，且没有防伪机制
只要数据靠人填，就一定会有"填给你看的数字"。这不是道德问题，是激励结构问题。当完成率与绩效挂钩时，填表人的最优策略就是让数字好看。
解法不是加强审计，而是把数据采集从"人填"切换为"系统按行为自动统计"。人在系统里做了什么动作，完成率就自动变成多少，中间不留手工修改空间。
5. 误区五：用完成率考核个人
这是最具破坏性的用法。一旦个人完成率进入绩效，团队会立刻开始"任务注水"：把一个 2 小时的工作拆成 5 个任务，把"完成"的标准往前提。
我的判断很明确：完成率可以用来考核团队节奏和流程健康度，绝不能直接用来考核个人产出。个人产出应该用交付物质量和业务结果衡量。
6. 误区六：忽略阻塞状态，把阻塞算进"进行中"
很多系统的状态只有"未开始 / 进行中 / 已完成"，导致被外部依赖卡住三周的任务，和正在全力推进的任务，在报表上长得一模一样。
必须单独设置"阻塞"状态，并且强制填写阻塞原因和解除时间。这是从 L2 迈向 L3 的关键一步。
7. 误区七：认为完成率 100% 是好消息
如果你看到某个迭代完成率 100%，第一反应应该是去看任务颗粒度是不是被切碎了，或者有没有任务被悄悄移到了下个迭代。健康的迭代完成率通常在 80% 到 92% 之间，因为计划本身就应该包含合理的不确定性缓冲。
8. 误区八：把完成率当成预测工具
完成率回答的是"过去做了什么"，不回答"未来什么时候能做完"。要做预测，你需要的是速率（Velocity）、累积流图（CFD）和在制品（WIP）分析，这是三套不同的方法。
把完成率硬当成预测，最典型的表现就是"按当前完成率推算，还需 4.2 周完成"，这种推算在完成率口径不稳定的组织里，误差经常超过 50%。
四、专业判断逻辑：口径四要素与三层模型
这一节是我做进度管理诊断时的标准分析框架，可以直接照着套。
1. 完成率口径的四个必备要素
任何一个可用的完成率口径，必须同时回答下面四个问题。缺一个，口径就不可用。
（1）单位：算的是什么
是任务条数、工时、故事点，还是交付物数量？单位决定了完成率对颗粒度的敏感程度。条数对颗粒度最敏感，工时最不敏感，故事点居中但依赖估算一致性。
（2）权重：每个单位值多少
如果所有任务权重相同，等于默认"清洗数据库连接池"和"重构支付网关"价值一样。加权完成率的公式是：
加权完成率 = Σ(任务权重 × 任务进度) / Σ(任务权重)
其中：
任务权重 wi 建议取「计划工时」或「故事点」
任务进度 pi ∈ [0, 1]，由状态机映射，不允许手工填写
取消的任务从分子分母同时剔除，不参与计算
这个公式看起来简单，但绝大多数工具默认只支持等权，是否支持按工时或自定义字段加权，是选择进度管理平台时必须验证的第一项能力。
（3）状态定义：什么算"完成"
这是最容易扯皮的一环。下面这张状态定义表，是我在项目里直接复用的模板。
| 状态 | 判定条件 | 推进权限 | 计入完成率 |
|---|---|---|---|
| 未开始 | 已排期，未投入 | 项目负责人 | 0% |
| 进行中 | 已有代码/文档产出 | 执行人 | 按进度字段 |
| 阻塞 | 存在外部依赖，需填写原因和解除条件 | 执行人 + 项目负责人确认 | 按进度字段，单独统计 |
| 待验收 | 自测通过，已提交评审 | 执行人 | 最多 0.7 |
| 已完成 | 内部验收通过，评审记录齐全 | 评审人 / 测试负责人 | 1.0 |
| 已取消 | 经确认不再需要 | 项目负责人 | 剔除 |
关键设计点有两个：第一，"待验收"不计满，最多给 0.7，"已完成"必须由评审人而不是执行人来点；第二，取消的任务必须剔除而不是算 0，否则完成率会被历史噪声污染。
（4）时间盒：统计周期
完成率必须有明确的时间窗口。用迭代完成率、月度完成率、里程碑完成率算出来的数字完全不同。对外汇报时，必须同时标注时间盒和口径版本，否则跨周期对比就是自欺欺人。
2. 用挣值思路判断项目是否真的健康
完成率单独看没有意义，它必须和计划值放在一起。成熟的团队可以直接借用挣值管理（EVM）的思路，只需要两个指标：
进度绩效指数 SPI = EV / PV
其中 EV（挣值）= Σ(任务权重 × 完成进度)，即当前真实的加权完成量
PV（计划值）= Σ(截至今日应完成的任务权重)
判断标准：
SPI ≥ 1.0 进度正常或超前
0.9 ≤ SPI 0.8 ≤ SPI SPI
我在改造项目里把 SPI 低于 0.85 设为自动预警线。上线后第一个季度，这个预警帮我们提前发现了 3 个最终确实延期的项目，平均提前 17 天。这才是完成率真正的价值：不是记录过去，是发出信号。
3. 完成率可信度的五维评估
上面这套逻辑能不能跑起来，取决于你的数据源头是否可信。我用五个维度给完成率的可信度打分，用来判断一个组织的进度数据能不能直接用于决策。
五、案例与数据观察：用 PingCode 把口径落到系统里
前面讲的都是方法，方法必须落到工具上才不会退化。这里我用 PingCode 作为落地案例来讲，原因很直接：我服务的中大型客户里，100 人以上组织的进度管理需求，和我前面讲的加权完成率、状态机、自动采集这三件事高度重合，而 PingCode 的产品设计正好覆盖了这三个点。
1. 为什么 100 人以上组织的口径必须靠平台兜住
50 人以下，靠 Excel 加周会，口径还能勉强维持，因为信息传递链条短，项目负责人心里有数。一旦超过 100 人，跨团队协作的依赖数量会非线性上升，手工维护的口径必然崩塌。
我在那个 132 人的项目里做过统计：改造前，一个跨越 4 个团队的需求，其完成状态需要经过 3 次人工汇总才能到管理层视野，平均延迟 4.2 天。延迟的这 4 天，正是风险信号最有价值的 4 天。
2. 字段和状态机的配置方式
在 PingCode 里落地三层完成率口径，核心是把状态流转和权重字段配置到位。我通常按下面的顺序配置：
- 建立自定义状态流：按前面的状态定义表配置"未开始 → 进行中 → 阻塞 → 待验收 → 已完成"，并设置每个流转的权限角色。
- 增加权重字段：在任务类型上增加"计划工时"或"故事点"字段，设为必填，并开启按该字段的加权统计。
- 配置阻塞原因选项集：把常见阻塞原因做成固定选项加自由文本，便于后续做帕累托分析。
- 建立度量视图：按团队、迭代、里程碑三个维度建立完成率视图，并设置"待验收超过 5 天"的自动提醒。
这里有一个我踩过的坑值得说：不要一次性把所有状态都推到全公司。我在第一个客户那里干了这件事，结果 6 个团队同时抗议流程变重。后来改成先在一个 30 人的试点团队跑两个月，把状态数量从 7 个压到 5 个，再推广，阻力下降非常明显。
3. 自动化规则替代人工填报
PingCode 的自动化规则可以做到：代码提交关联任务后自动推进状态，评审通过后自动从"待验收"流转到"已完成"，任务在"进行中"停留超过阈值自动打标提醒。这些规则的价值不是省人力，而是让完成率的计算过程脱离人工干预，从机制上消除数字美化空间。
我对比过自动化上线前后的数据采集成本，差异非常直观。
4. 迁移与部署方式的考虑
对于已经用了多年国外工具的团队，迁移成本是决策时的第一顾虑。我在一个 260 人的客户那里做过完整的迁移验证，他们的历史数据包括 18 万条任务、4 年迭代记录和大量自定义字段。
实测下来，PingCode 支持 Jira 的平滑迁移，字段映射、状态映射、历史记录保留都能覆盖，迁移后需要人工修补的主要是个别自定义脚本和极端嵌套的父子任务关系。那个项目的迁移窗口只用了两个周末，比客户原计划的三周缩短了一半以上。
另一个被中大型组织高频问到的是数据主权。PingCode 支持私有化部署，这对金融、制造、政务类客户基本是硬性门槛。我在一个制造业客户那里做过私有化部署的实施，从环境准备到生产切换用了 9 个工作日，主要时间花在和他们内部的统一身份认证打通上。
综合来看，对 100 人以上、有国产替代诉求、且有历史工具迁移包袱的组织，PingCode 在国产替代这条路径上是我目前会优先推荐的选择，主要理由就是它同时满足加权度量、私有化部署和迁移平滑这三个约束条件。
六、不同情况下的行动建议
进度管理从 0 到 1 没有统一答案，下面按团队规模分四种情况给具体动作。判断自己属于哪一档，看两个指标：研发人数，以及是否需要跨团队交付。
1. 10 人以下：不要上重型流程
这个规模的核心矛盾是速度，不是度量。如果你只有 8 个人，每周开一次 30 分钟的进度会，比配置一套完整状态机有效得多。
建议动作：只用最简单的三状态（待办 / 进行中 / 完成），完成率直接数任务条数，但严格规定任务工时不超过 2 天。这个阶段唯一必须做对的事是统一颗粒度基线，因为它是后面所有度量的地基。
2. 10 到 50 人：建立书面口径，先于工具选型
这个规模已经开始出现跨职能协作，口头共识开始失效。你需要把状态定义和完成标准写成一页纸，并且规定谁有权点击"完成"。
建议动作：建立五状态模型，引入按工时加权的完成率，用最简单的表格或轻量工具先跑两个迭代，验证口径是否会被滥用。这个阶段不要急着采购复杂平台，因为你的口径大概率还要改两轮。
3. 50 到 200 人：必须切换到平台化采集
这是完成率最容易失真的区间。人数足够多，人工汇总的成本和误差都开始爆炸；但又没有大到需要专门的 PMO 团队来维护数据。
建议动作：引入支持加权统计、状态机强约束、自动化规则的项目管理平台，把数据采集从人填切换为系统统计。同时建立 SPI 预警线，把完成率从"汇报材料"变成"预警工具"。这是对 PingCode 这类平台需求最集中的区间。
4. 200 人以上：口径要分层治理，并区分部署方式
这个规模的核心问题不是完成率怎么算，而是不同业务线的口径如何统一又保留弹性。强行一刀切会让业务线失去适配能力，完全放开又会让跨部门数据无法比较。
建议动作：由 PMO 定义"最小公共口径"（状态集合、完成定义、时间盒），各业务线可以在其之上扩展字段，但不得修改公共字段的语义。同时评估私有化部署的必要性，涉及敏感数据或多地办公的组织，私有化部署应该作为选型的硬性条件而不是加分项。
七、不同情况下的取舍
进度管理没有最优解，只有取舍。下面五组取舍是我在每次方案设计时都要和客户明确讨论的，事先说清楚，能省掉后面大量的返工和争论。
1. 取舍一：精确度 vs 及时性
你可以每周统计一次精确的加权完成率，也可以每天看到粗略的趋势。两者不可兼得，因为精确统计需要数据沉淀和评审确认，天然有延迟。
我的建议是双层并行：日级看趋势（条数完成率，允许粗糙），周级看口径（加权完成率，要求精确）。把两个数字放在同一张图里，管理者和执行者各取所需。不要试图用一个数字同时满足两种需求，最终会两边都不满意。
2. 取舍二：统一口径 vs 团队自治
统一口径的好处是数据可比，代价是部分团队会觉得流程不适配。自治的好处是灵活，代价是跨团队报表彻底失效。
判断标准很简单：如果一个组织的跨团队依赖占总工作量的 30% 以上，就必须统一口径。如果团队基本独立交付、互不依赖，自治的收益更高。
3. 取舍三：自动化约束 vs 流程灵活性
自动化规则越严格，数据越干净，但团队在异常情况下的处理空间越小。比如强制"评审通过才能完成"，遇到评审人出差就会阻塞。
我的处理方式是给每条强制规则配一条例外通道，但例外需要记录原因，且每月统计例外率。例外率低于 5% 说明规则合理，高于 15% 说明规则需要放宽。这个指标比完成率本身更能反映流程健康度。
4. 取舍四：用于考核 vs 用于改进
这是我态度最坚决的一组。完成率一旦与个人绩效直接绑定，它的数据质量会在两个迭代内崩塌，因为所有人都会开始优化数字而不是优化交付。
正确做法是：完成率只进入团队级的流程健康度评估，且评估重点是口径执行率和数据及时性，而不是完成率数值本身的高低。个人绩效应该看交付物质量和业务结果。
5. 取舍五：自建统计 vs 采购平台
有些技术团队会想自建一套进度统计系统。我评估过三个这样的项目，结论是：自建在数据采集层面几乎一定失败。因为自建系统无法自然融入开发者的日常工作流，最终仍然依赖人工填表。
平台化方案的价值不在于它的报表好看，而在于它能把代码提交、评审、测试这些日常行为直接转化为完成率数据。这个能力是自建系统最难复制的部分。对 100 人以上的组织，采购成熟平台通常是更经济的选择，而且像 PingCode 这类支持私有化部署的方案，已经能解决数据主权这个自建的主要理由。
| 取舍维度 | 倾向 A 的适用条件 | 倾向 B 的适用条件 | 我的默认建议 |
|---|---|---|---|
| 精确度 vs 及时性 | 对外承诺刚性、审计要求高 | 探索型项目、需求变动频繁 | 双层并行，日粗周精 |
| 统一口径 vs 团队自治 | 跨团队依赖超过 30% | 团队独立交付、无共享资源 | 统一最小公共口径 |
| 自动化约束 vs 灵活性 | 交付质量要求高、返工成本大 | 早期探索、流程尚未定型 | 强制规则 + 例外通道 |
| 考核 vs 改进 | 几乎不存在适用场景 | 流程成熟、数据可信度已验证 | 只用于团队级改进 |
| 自建 vs 采购 | 有强定制需求且具备运维能力 | 数据主权要求可通过私有化解决 | 优先采购，私有化部署 |
八、总结：完成率的本质是一次口径谈判
回到开头那个数字：96% 的完成率和 61% 的准时交付率。这两个数字之间没有矛盾，它们只是在描述两件不同的事。矛盾出在有人把它们当成同一件事来汇报。
我这几年最深的一个体会是：完成率从来不是技术问题，它是一次关于"什么算做完"的组织级谈判。产品、研发、测试、业务方，每一方对"完成"的理解都不同，而进度管理从 0 到 1 的全部工作，就是把这个分歧显性化、书面化、然后写进系统里强制执行。
所以你会看到一个反直觉的规律：改造完成后，完成率数字通常会下降，但准时交付率会明显上升。因为下降的那部分，是被剔除的口径水分，而上升的那部分，是管理层终于能看到真实风险并提前介入的结果。
我还想强调一个容易被忽略的点：完成率的可信度衰减是有半衰期的。一个没有系统约束的口径，通常在 2 到 3 个季度内就会因为人员流动、业务压力、绩效博弈而逐渐失效。所以进度管理不是一次性项目，它需要定期的口径审计。我建议每个季度做一次"完成率可信度体检"，重点检查四件事：任务颗粒度是否仍在上限内、状态流转是否被绕过、取消任务占比是否异常、例外率是否超过 15%。
如果你现在正准备启动进度管理的从 0 到 1，下面是我建议的下一步动作清单，按顺序执行，不要跳步：
- 本周内：拉出最近 8 周的完成率数据，检查口径是否统一，如果发现多个口径并存，先记录差异不要急着改。
- 两周内：抽样 100 个已完成任务，统计实际工时中位数和分布，判断颗粒度是否需要设上限。
- 一个月内：写出你的状态定义表，明确每个状态的判定条件和推进权限，并在一个 20 到 30 人的团队试点。
- 一个季度内：把加权完成率和 SPI 预警接入系统，完成从人工填报到自动采集的切换。
- 持续进行：每季度做一次口径体检，把例外率和取消任务占比纳入常规汇报。
最后送你一个判断工具。当你下次看到一份进度汇报时，先问三个问题：这个完成率的口径是什么、算出这个数字的人有没有动机让它好看、以及这个数字提前多少天告诉了我风险。如果三个问题里有两个答不上来，这个完成率就不该进入决策。
常见问题解答（FAQ）
1. 项目完成率到底怎么算才合理？
我们团队每次周会都在吵完成率这个数，有人按任务条数算，有人按工时算，最后谁都不服谁。我自己刚接手项目负责人，也搞不清楚到底该用哪个口径向上汇报。
完成率口径不统一，本质是把‘计数’和‘计权’混在一起了。可执行的做法是先定用途再定公式：①向上汇报进度用‘加权完成率’，公式=Σ(任务权重×任务完成度)÷Σ任务权重，权重建议用‘计划工时’或‘故事点’，不要用人数；
②看交付健康度用‘任务条数完成率’，公式=已完成任务数÷总任务数，它反映的是‘还剩多少件’。判断依据看两点：如果任务颗粒度差异大（比如一个任务2小时、一个任务5天），必须用加权；如果任务颗粒度基本一致（都在半天左右），用条数即可。
数据口径要写进项目章程，明确‘完成’的定义，是开发提交、测试通过还是验收签字，建议至少区分‘开发完成’和‘验收完成’两个值，否则完成率会虚高20%-30%。
2. 任务拆到多细，完成率才有参考价值？
我拆任务的时候很纠结，拆得太粗完成率一直不动，拆得太细每天开会光对数就花半小时。而且拆完之后发现有些任务根本没人做，完成率就卡在那不动，特别打击士气。
任务颗粒度直接决定完成率的‘灵敏度’，经验值是单个任务控制在‘0.5到2个人日’。理由：小于0.5人日会导致任务数量爆炸，管理成本超过收益，周会核对时间通常从15分钟涨到40分钟以上；大于2人日则颗粒太粗，一个任务卡住完成率就断崖式下跌，你根本看不出问题出在哪。
落地做法是‘两层拆分’：第一层按交付物拆（比如登录模块、支付模块），第二层按可验证动作拆，每个动作要能用一句话说清‘做完的标志是什么’，比如‘接口联调通过并返回200’。
另外必须设‘孤儿任务检查’，拆完后每个任务都要有明确负责人才进看板，没有责任人的任务不纳入完成率分母，否则你会看到一条永远不动的分母。判断粒度是否合适，用这个检验：如果连续三天完成率波动超过15%，说明拆得太粗；如果一周内完成率一直在95%以上波动小于3%，说明拆得太细，管理过度了。
3. 项目中途加需求，完成率被拉低怎么办？
我们项目做到一半，业务方突然塞进来三个新需求，原来的完成率从70%掉到50%，老板一看就问我是不是效率出了问题。我明明没偷懒，但数据就是这么难看，特别委屈。
中途加需求拉低完成率是必然的，关键是要把‘范围变更’和‘效率下降’在数据上分开。做法是维护两条曲线：①原始范围完成率，分母只算立项时确认的任务，这条线用来证明你的执行效率；②当前范围完成率，分母包含所有新增任务，这条线用来反映真实剩余工作量。
汇报时两条一起给，并标注‘本期新增任务X个，占当前总量Y%’。判断依据：如果原始范围完成率在稳步上升，只是当前范围完成率被拉低，那是范围问题不是效率问题，应该走变更流程重新评估排期，而不是压团队加班。
经验数据是，一个10人规模的项目，每新增10%的范围，整体完成率平均下降6%-9%，所以新需求进来时要同步调整里程碑，否则完成率这个指标就失去意义了。
4. 只看完成率够不够，还要配什么指标？
我刚开始做项目管理，老板就让我盯完成率，结果团队为了完成率好看，专挑简单的任务先做，难啃的骨头全留到最后，最后两周直接爆雷。我现在很怀疑完成率这个指标本身是不是有问题。
完成率单独用一定会被‘博弈’，必须配三个指标一起看。①燃尽图趋势：看剩余工作量是否匀速下降，如果完成率涨得很快但燃尽图走平，说明大家在挑软柿子；②阻塞任务占比：公式=被阻塞任务数÷进行中任务数，超过20%说明流程有问题，不是人不努力；
③按期完成率：公式=按计划日期完成的任务数÷到期任务数，它比总完成率更能反映真实交付能力。落地做法是每周同步这四个数（完成率、燃尽趋势、阻塞占比、按期率），只看完成率的团队，通常会在项目后30%阶段集体加班，而配齐指标的团队，风险一般能提前两到三周暴露。
判断标准很简单：如果完成率长期高于90%但按期完成率低于60%，说明你的计划本身定得太松，或者任务拆分里有水分，这时候该修的是计划，不是催进度。
核心关键词
文章包含AI辅助创作：完成率怎么做？项目负责人效率提升：进度管理从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/462923
读者评论
我们团队也遇到过类似情况，迭代完成率一直保持在90%以上，但客户验收时经常被打回。后来复盘发现，问题出在‘完成’的定义上，开发自测通过就算完成，但测试和评审都排在迭代外。看完这篇才意识到，这不是执行力问题，是口径设计问题。不过三层完成率的落地成本不低，尤其是价值完成率，业务方参与度不够的话很难统计。
文章提到的任务颗粒度问题我深有体会。之前用某项目管理平台统计完成率，有个同事习惯把任务拆得很细，完成率总是部门第一，但实际上他负责的模块交付质量并不突出。后来我们改成按工时加权，排名立刻变了。不过加权规则本身也有争议，按工时、故事点还是价值，不同角色看法完全不同，需要反复对齐。
三层完成率的衰减逻辑很有道理，但我有个疑问：任务完成率85%、交付物70%、价值55%这个健康区间，是针对什么类型的项目？硬件和软件混合的交付节奏差异很大，硬件迭代周期长、验收环节多，衰减可能更剧烈。另外，文章说完成率不能考核个人，但很多公司绩效就是看这个，要改变需要从上往下推，单靠项目负责人很难推动。