完成率流程与规范：企业管理者进度管理制度设计关键指标

去年第三季度，我参与了一家380人规模智能硬件公司的季度复盘。会议开到第40分钟，同一个项目出现了三个完成率：项目经理说82%，研发总监说65%，CEO面前的看板显示91%。三个数字都不算错，它们分别来自任务数口径、工时口径，以及一个把已关闭缺陷也计入分子的看板。这场争论最后没有产生任何行动项，因为它本质上不是数据问题，而是制度问题。

完成率被绝大多数企业当作一个"结果指标"来读，但它的真实身份是一个口径契约。分子怎么算、分母怎么定、什么时候拍快照、什么状态才算真的完成，这四个参数任意一个没写进制度，完成率就只是一个可以随时被解释的数字。这篇文章不讲完成率的公式，讲的是怎么把它变成一套能跨部门对齐、能跨季度比较、能经得起追问的管理制度。

一、核心结论：完成率是制度产物，不是统计产物

先把结论放在最前面，后面所有章节都在展开这五句话。

第一，完成率的可信度上限由采集路径决定，不由计算方式决定。一个从代码提交、流水线状态、测试用例执行结果自动推导出来的完成率，和一个人工填报的完成率，哪怕公式完全一样，可信度差距也在一个数量级以上。工具选型时最该问的不是"能不能算出完成率"，而是"这个数字是怎么流进来的"。

第二，口径必须先于工具。我见过太多团队先上线工具、再补制度，结果是工作流状态被各部门按自己的习惯命名，三个月后没人能说清楚"已解决"和"已完成"的区别。口径定义应该是一份不超过两页的文档，先签字，再配置。

第三，完成率必须配一对制衡指标。单独考核完成率的组织，一定会得到注水的完成率。有效的组合是"完成率 + 返工率"或"完成率 + 阻塞时长"，让提前关闭任务、拆细任务这类动作在另一个指标上留下痕迹。

第四，不同层级需要不同口径，强行统一是伪需求。任务级看完成数量与颗粒度，迭代级看按承诺交付的比例，项目级看里程碑达成，组合级看资源占用与交付节奏。用一个数字同时服务四个层级，等于四个层级都看不清。

第五，关键指标控制在6个以内。完成率、按期完成率、返工率、需求蔓延率、平均阻塞时长、计划偏差率，这六个指标已经足够支撑一家千人规模企业的进度治理，再加指标只会稀释注意力。

下面这张图是我在三个不同规模组织里做过的同一组对照：同一批迭代数据，切换四种口径后得到的结果差异。它说明一件事，口径选择带来的差异，远大于团队努力程度带来的差异。

二、背景与真实场景：完成率为什么越算越乱

完成率失真不是某个团队的问题，它是组织规模扩张过程中必然出现的制度性缺口。理解这个缺口在哪出现，比急着上工具更重要。

1. 三种典型现场

现场一：周会上的三方对账。产品经理看需求完成率，研发看任务完成率，测试看缺陷关闭率，三个数字来自三个视图、三套状态机。会议的前20分钟消耗在对齐数字上，而不是讨论风险。

现场二：看板数字与交付事实脱节。看板显示迭代完成率94%，但版本延期了9天。追问下去才发现，任务在"开发完成"时就置为已完成，而集成、联调、验收环节根本没有对应的任务项。

现场三：季度末的突击关闭。考核周期末最后三个工作日，任务关闭量占全周期的31%。其中一部分任务在下一季度第一周被重新打开，形成"关闭，重开"的往复。

2. 完成率失真的四个上游原因

原因一，状态语义没有书面定义。"进行中"和"待验证"的边界靠个人理解，导致同一状态在不同人手里承载不同含义，聚合后必然失真。

原因二，分母持续漂移。迭代进行中不断插入新需求，分母在变大，完成率却按原始承诺的分母计算，出现"完成率下降但实际产出增加"的反常现象。

原因三，完成阈值不统一。有人把"代码合并"当完成，有人把"自测通过"当完成，有人把"上线"当完成。阈值不统一时，完成率是一个区间而不是一个点。

原因四，数据靠人工搬运。任务状态靠开发在周五下午集中更新，导致完成率在时间轴上的分布严重扭曲。这也是我坚持认为采集路径优先于计算公式的原因。

3. 规模跃迁的三个断裂点

根据我在制造业、金融科技、企业软件三个行业的观察，完成率制度会在三个规模节点上失效，需要重建而不是修补。

大约50人：从"大家互相知道"到"需要写下来"。50人以下，项目经理靠记忆和口头沟通就能掌握进度，完成率更多是汇报装饰。一旦超过这个规模，口头信息传递开始丢包，必须把状态语义变成文档。

大约150人：从"一套口径"到"多套口径需要映射"。研发、测试、交付、运营的工作节奏和交付物形态不同，强行用同一套状态机会导致某些部门填假数据。正确做法是各部门保留自己的状态机，再定义一层映射规则到统一口径。

大约400人：从"项目视角"到"组合视角"。单项目完成率已经没有决策价值，管理者关心的是资源在多个项目间的分配效率、关键路径项目的达成风险。此时需要引入加权完成率和资源占用口径。

下面这张图展示的是一个真实观察到的现象：在没有采集约束的团队里，一周内的完成率呈现明显的周末前冲高特征。任务关闭在周四、周五集中发生，周一到周三几乎不动。这不是团队前松后紧，而是状态更新本身滞后造成的。

三、六个常见误区：从错误做法到修正路径

这些误区我在不同企业里反复见到，而且往往同时存在。每一个都给出错误做法、直接后果和修正方向，方便对照排查。

1. 误区一：用任务数量当唯一分母

错误做法：完成率 = 已完成任务数 ÷ 总任务数。

直接后果：一个10分钟的任务和一个10天的工作量权重相同。团队很快学会把大任务拆成小任务，完成率轻松上到95%，但交付日期没有任何改变。我见过一个团队把一个模块拆成87个任务，完成率从62%涨到89%，版本仍然延期两周。

修正方向：任务数口径保留用于看响应速度和流转效率，交付进度口径改用加权方式。最小可行方案是给任务增加一个1/2/3/5的规模系数，用加权任务数替代原始任务数，实施成本很低但能消除大部分注水空间。

2. 误区二：把完成率直接接进绩效

错误做法：完成率未达标的团队扣减奖金，完成率排名前三的团队额外奖励。

直接后果：古德哈特定律生效，当指标变成目标，它就不再是好指标。可预期的行为包括：迭代末期集中关闭任务、把困难任务推迟到下一个周期、把验收标准悄悄放宽、拒绝接受新需求但不说明原因。

修正方向：完成率用于改进，不直接用于分配。如果必须挂钩，挂钩对象应该是"承诺达成的稳定性"而不是"完成率的高绝对值"。一个长期稳定在75%的团队，比一个在60%到95%之间剧烈波动的团队更值得信任。

3. 误区三：滚动分母与基线分母混用

错误做法：月初承诺20个需求，月中插入8个，完成率按28个算。

直接后果：团队做得越多，完成率越低，形成负向激励。团队开始抵制需求变更，或者在估算时预留大量缓冲，反而降低了整体响应能力。

修正方向：两个数字并列展示。基线完成率只算月初承诺范围内完成的部分，衡量承诺可信度；滚动完成率算上所有新增项，衡量实际吞吐。两者之间的差值，就是需求插入造成的冲击，这个差值本身就是很好的管理信号。

4. 误区四：只有"未完成"，没有"阻塞"

错误做法：任务状态只有待办、进行中、已完成三种。

直接后果：一个因为等接口、等环境、等审批而停摆了六天的任务，和一个正常开发了六天的任务，在完成率上完全不可区分。管理者看到的进度迟滞，无法归因到具体原因。

修正方向：至少增加"阻塞"状态，并要求填写阻塞原因与责任方。进一步的做法是记录阻塞进入和解除的时间戳，自动计算出"阻塞时长"和"阻塞占比"，这是完成率最重要的解释变量。

5. 误区五：没有明确的完成定义

错误做法：工作流里有"已解决"和"已关闭"两个状态，但没有文档说明区别。

直接后果：不同人按不同理解流转状态，聚合后的完成率含义模糊。更麻烦的是，当完成率被质疑时，谁也无法复现这个数字是怎么产生的。

修正方向：写一份一页纸的完成定义，明确规定进入已完成状态必须满足的全部条件。典型的条件组合包括：代码已合并到主干、单元测试通过、相关测试用例执行通过、文档已更新、需求方已确认。这些条件中能自动校验的，交给工具校验；不能自动校验的，用必填字段强制确认。

6. 误区六：追求一个全局完成率

错误做法：要求所有部门、所有类型的项目统一汇报一个完成率。

直接后果：研发、交付、市场的工作形态差异被抹平，得出的数字既不能指导研发改进，也不能指导交付决策。数据质量差的部门开始编造数字以应对汇报。

修正方向：底层保留各部门自己的口径，上层定义映射规则。映射规则的核心是"完成物"而非"活动"，无论中间过程如何，最终交付物是否可用、是否被验收，这是唯一可以跨部门统一的标准。

下面这张散点图是我在一个320人研发组织里做的观察，横轴是团队内任务颗粒度的离散程度（用任务规模的标准差表示），纵轴是完成率与交付事实的偏差。两者呈现明显的正相关。

接下来这张图是关于考核强度与数据质量的权衡。我把三个事业部的考核挂钩强度分为三档，观察完成率水平和返工率的变化。

四、专业判断逻辑：可审计的完成率制度怎么搭

把前面的问题理清之后，制度设计的逻辑其实不复杂。核心是四件事：定口径、分层级、配制衡、留版本。

1. 先定口径，再定工具

口径定义我建议写成结构化文档，而不是散落在会议纪要里。一份可执行的口径定义至少包含以下字段，我用 YAML 的形式给出模板，因为它比表格更适合被版本管理工具追踪变更。

metric: completion_rate
version: 2.1

effective_from: 2024-07-01

numerator:

definition: 在统计快照时刻处于"已完成"状态的工作项

required_conditions:

代码已合并至主干分支

关联测试用例执行通过率 100%

需求方确认字段已填写

denominator:

type: baseline

definition: 迭代启动时冻结的工作项集合

frozen_at: 迭代开始日 23:59

snapshot:

frequency: daily

time: "23:30"

timezone: Asia/Shanghai

exclusions:

类型为"调研"且未排期的工作项

迭代中途取消且已记录原因的工作项

change_log:

version: 2.1

change: 新增"需求方确认字段已填写"条件

reason: 出现开发自认为完成但需求方不认可的情况

approved_by: 研发效能委员会

version: 2.0

change: 分母由滚动改为基线冻结

reason: 需求插入导致完成率负向激励

这份文档的价值不在于写得漂亮，而在于每次变更都留下原因和批准人。当半年后有人问"为什么7月的完成率突然掉了一截"，答案就在 change_log 里，不需要重新考古。

2. 分层指标：四个层级各看各的

下表是我在多个组织验证过的分层方案。核心思路是每一层的分母形态不同，避免用同一个数字服务所有决策。

需要特别说明组合级。单看项目完成率，管理者无法判断资源是否被合理使用。加权完成率应该以人力投入为权重，一个投入30人、完成率60%的项目，和一个投入5人、完成率90%的项目，在组合视角下的紧迫程度完全不同。

3. 完成率必须配一对制衡指标

我在前面反复强调制衡。具体怎么配，取决于组织最担心哪种失真行为。

• 担心提前关闭：配"返工率"（迭代内被重新打开的任务占比），健康区间通常在5%到12%。
• 担心拆细任务：配"任务规模中位数"，如果中位数持续下降而完成率上升，说明存在拆细行为。
• 担心需求堆积：配"需求蔓延率"（迭代内新增工作量 ÷ 启动时工作量），超过25%时应触发流程审查。
• 担心阻塞被隐藏：配"平均阻塞时长"，这个指标上升往往先于完成率下降两到三周出现。

不要一次配四个制衡指标。选一到两个最贴合当前痛点的，跑满两个季度再调整。指标频繁变动本身就是数据失真的来源。

4. 采集路径决定可信度上限

这是我个人最看重的一点。同样一个完成率数字，来自三条不同的采集路径，可信度差异巨大。

路径一：人工填报。开发在迭代末期集中更新状态。成本最低，可信度最低，适合50人以下或探索性项目。

路径二：状态自动流转。通过工作流规则约束状态变更条件，例如"必须关联测试用例且全部通过才能进入已完成"。成本中等，可信度中等偏高，是大多数100到500人组织的合理选择。

路径三：与研发活动联动。状态变更由代码提交、合并请求、流水线执行结果自动触发。可信度最高，但要求工具链具备原生集成能力，且对工程规范有较高要求。

我的经验判断是：100人以上的组织，至少要做到路径二，并且把路径二中的关键校验做成工具强制而非流程约定。写在文档里的规则会被遗忘，配在工作流里的规则不会。

5. 口径变更要有版本号

口径不是一成不变的。业务形态变了，口径必须跟着变。但变更必须可追溯，否则历史数据就变成了不可比的噪声。

（1）变更前：保留至少两个完整周期的旧口径数据，用于对比。

（2）变更中：新旧口径并行运行一个周期，展示差异幅度，让所有使用方理解数字会怎么变。

（3）变更后：在报表上标注口径版本，跨版本的趋势线断开显示，不做直接连线。

下面这张图是一个工作项从创建到最终确认为有效完成的转化路径。它说明为什么"完成率"在采集路径不完善时，分子里混入了大量并未真正交付的工作项。

下面这张雷达图对比四类组织在完成率制度成熟度上的差异

不同业务形态的组织，制度建设的优先顺序完全不同。这是我在四类组织里做诊断时的典型剖面，评分维度包括口径明确度、采集自动化率、制衡指标完备度、变更可追溯性和跨部门一致性。

五、具体案例：一家420人研发组织的12个月改造

下面这个案例来自我深度参与的一个项目，数据经过对方同意后做了脱敏处理。它是一个中等规模组织重建完成率制度的完整过程，包含踩过的坑。

1. 案例背景与起点

这家企业做企业级软件，研发加测试加产品共420人，分布在6个产品线。改造前的状态是：使用某海外项目管理工具三年，工作流状态被各产品线自行扩展，同一含义出现了11种不同的状态命名。

最尖锐的矛盾发生在季度经营会上。CEO看到的是完成率87%，但客户侧统计的版本按期交付率只有61%。两个数字的差距成为了推动这次改造的直接原因。

我们做的第一件事不是换工具，而是把6个产品线的所有状态命名拉出来，做一次语义归并。结果发现，11种状态命名实际对应的语义只有5种，但其中"已完成"这个语义被拆成了3种不同严格程度的定义。这就是26个百分点的差距来源。

2. 在 PingCode 里把口径固化下来的四个动作

语义归并完成后，这家企业选择了 PingCode 作为新的项目管理平台。选择理由有三个：一是需要私有化部署以满足客户的合规审计要求；二是从原有海外工具迁移的历史数据量很大，需要平台具备平滑迁移能力；三是组织规模已经到了420人，需要能支撑多产品线组合视图的平台。

（1）用自定义工作流重建状态语义。把归并后的5种语义固化成标准工作流，每个状态设置进入条件。其中"已完成"状态设置为必须满足三项校验：关联测试用例全部通过、需求方确认字段非空、关联代码合并记录存在。任一项不满足时，状态流转会被平台拒绝，而不是仅给出提示。

（2）用必填字段强制口径落地。在工作项上增加"规模系数""阻塞原因""预期交付日期"三个字段。规模系数采用1/2/3/5/8的斐波那契序列，由创建人在需求评审时确定，后续修改需要记录原因。这一步看起来只是加了几个字段，但它让加权完成率成为可能，也让拆细任务的行为留下了痕迹。

（3）双轨制指标并行。迭代级同时展示基线完成率和实际吞吐量两个数字。前者基于迭代启动时冻结的工作项集合，后者包含中途新增项。两个数字的差值被定义为"需求冲击强度"，超过25%时触发迭代回顾中的专项讨论。

（4）建立快照机制。每天23:30由平台自动生成一次进度快照，不做任何人工干预。所有对外汇报的完成率数据都从快照中读取，不允许使用实时查询结果。这一点很关键，实时查询的数字会随着查询时间点不同而变化，导致同一份报告在不同时间被翻出来时对不上。

3. 迁移与私有化带来的额外收益

这家企业的迁移过程用了六周，包含历史数据清洗、字段映射、状态转换规则配置和三轮并行验证。这里有一个判断值得分享：迁移不是技术动作，而是口径梳理的最佳时机。

因为迁移必须回答"旧系统的这个字段在新系统里对应什么"这个问题，这个过程会强迫所有人把过去模糊的口径讲清楚。我们在这六周里沉淀出的口径文档，比过去三年积累的都要完整。

私有化部署带来的收益是数据主权的可控性。这家企业的客户中包含金融机构，审计时要求提供完整的需求变更轨迹和状态流转日志。私有化部署让这些日志保留在企业内网，审计取证时间从过去的三天缩短到半天。

4. 12个月的数据变化

以下是改造前后关键指标的对比。需要说明的是，完成率在改造后是下降的，这不是退步，而是口径收紧后的真实水平回归。

更重要的是改造后12个月的趋势变化。完成率的绝对值下降了，但它的波动性和解释力显著提升。

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

制度设计没有标准答案，但有明确的适配逻辑。下面按组织规模和业务形态给出四组建议，可以直接作为启动清单。

1. 50人以下团队：先解决状态语义，不要上复杂指标

这个规模的核心问题是口头传递的信息丢包，不是指标不够精细。

• 把工作流状态压缩到4个：待办、进行中、阻塞、已完成。
• 为"已完成"写一句明确的定义，长度不超过两行，贴在团队可见的地方。
• 不引入工时填报，不引入故事点，完成率用任务数口径即可，够用。
• 每周固定一次15分钟的进度同步，重点看阻塞项而不是完成率数字。

这个阶段最该避免的是过度设计。我见过30人的团队配置了七级工作流和两套审批，结果所有人都在填表，没人在做事。

2. 100到500人研发组织：口径固化与采集自动化并重

这是最需要系统性建设的规模区间，也是我建议优先考虑专业项目管理平台的区间。

1. 第一步，做状态语义归并。把所有团队的状态命名拉出来，归并成语义清晰的集合，形成书面定义。
2. 第二步，选定完成率口径版本。基线完成率作为主口径，滚动吞吐量作为辅助数字，两者并列展示。
3. 第三步，把口径落到工作流里。能自动校验的条件全部做成强制规则，不依赖人的自觉。
4. 第四步，配置一对制衡指标。研发密集型团队优先配返工率，交付型团队优先配阻塞时长。
5. 第五步，建立每日快照。所有汇报数据统一从快照读取，避免实时查询带来的对不上账。

工具层面，这个规模的研发组织通常需要私有化部署能力和历史数据迁移能力。以 PingCode 为例，它主要服务中大型企业及100人以上组织，支持私有化部署，也支持从主流海外项目管理工具的平滑迁移，这在国产替代场景下是比较务实的选择。但我更想强调的是：工具能解决的是采集路径和规则强制问题，口径本身还是得组织自己想清楚。平台不会替你决定什么叫"完成"。

3. 500人以上多项目组合：从项目视角升维到组合视角

这个规模下，单项目的完成率已经不足以支撑决策，因为资源是共享的。

• 建立资源占用视图，按人力投入加权计算项目完成率。
• 区分关键路径项目与非关键路径项目，使用不同的完成率阈值作为预警线。
• 建立跨产品线的口径映射表，允许底层差异，但保证上层的数字可比。
• 引入完成率的预测用途，用滚动四周的数据外推迭代末的达成概率。

组合视角最容易被忽略的是分母的交叉计算。一个工程师同时参与三个项目，他的工作量应该按什么比例分摊到三个分母上？如果没有分摊规则，所有项目的完成率都会偏高。我的建议是按实际投入时间分摊，并且每月做一次校准，而不是按项目数量平均分摊。

4. 交付型/项目型组织：以验收为唯一锚点

这类组织的完成定义相对简单，客户验收就是唯一标准，难的是过程中的可见性。

• 完成率分母锚定合同或工作说明书中的交付物清单，不用内部任务数。
• 过程中用里程碑达成率作为中间指标，避免等到验收才知道延期。
• 重点关注验收周期的统计，从提验到客户确认的平均天数往往被严重低估。
• 变更管理要严格，客户提出的变更必须走书面流程并调整分母。

七、不同情况下的取舍

制度设计的本质是取舍。下面五组取舍没有标准答案，但每组都给出我的判断依据，方便你对照自己的情况做决定。

1. 精确性 vs 及时性

取舍点：要一个经过完整校验、准确但延迟三天的完成率，还是要一个实时更新但可能不准确的完成率？

我的判断：看用途。用于日常执行协调，及时性优先，实时视图配上明显的"未校验"标记即可；用于对外汇报和资源决策，精确性优先，宁可晚一天也要用经过校验的快照数据。

最忌讳的是两个场景用同一份数字。用实时数据对外汇报，三小时后对方再查一次发现数字变了，信任度会直接崩塌。

2. 统一口径 vs 部门自治

取舍点：强迫所有部门使用同一套状态机和同一套完成定义，还是允许各部门自建再向上映射？

我的判断：150人以下统一，150人以上分层。

150人以下，部门间差异还不足以造成沟通成本，统一口径带来的对齐收益更大。150人以上，强行统一会导致某些部门填假数据，比如让运维团队用研发的状态机，他们只能选择最接近的状态，精度就丢了。正确的做法是底层自治、中层映射、上层统一。映射规则要文档化，并且定期校验映射的准确性。

3. 自动化采集 vs 填报成本

取舍点：为了拿到高可信度的数据，要求团队增加填报动作，会带来多少抵触？

我的判断：任何需要新增填报动作的字段，都要先问三个问题。

1. 这个字段能不能从已有活动中自动推导出来？如果能，就不要让人填。
2. 如果必须填，能不能在某个团队已经在做的动作里顺带完成？
3. 这个字段的使用频率有多高？如果一个季度才用一次，不值得让所有人每周填。

我的经验是每增加一个必填字段，团队的填报质量会下降约5%，因为他们会把填写当成走过场。所以字段必须精简，宁缺毋滥。

4. 考核挂钩 vs 改进导向

取舍点：完成率要不要进绩效？

我的判断：短期不挂钩，长期看数据的成熟度。

在完成率口径刚建立的前两个季度，绝对不要挂钩。这个阶段的数字波动主要来自口径调整而非执行变化，挂钩会混淆信号。等到完成率的月度波动收敛到±8个百分点以内、并且与外部交付事实的相关性稳定后，可以考虑挂钩完成率的稳定性而非绝对值。

更稳妥的替代方案是：把完成率作为对话的输入而不是分配的依据。迭代回顾上讨论"为什么这个迭代的完成率比上个月低了12个百分点"，这个讨论本身产生的改进，比任何考核都有效。

5. 私有化部署 vs SaaS 方案

取舍点：数据主权与运维成本之间怎么平衡？

我的判断：看客户结构而不是看组织规模。

如果企业的客户中包含金融机构、政府部门或对数据出境有明确要求的行业，私有化部署基本是必选项，审计取证的便利性会远超额外的运维投入。如果客户结构不涉及这些约束，SaaS 方案的迭代速度和使用成本更有优势。

需要提醒的是，私有化部署的隐性成本主要在升级维护上。做决策时应该把未来三年的升级频率和所需人力也算进去，而不只是比较首年的采购成本。我见过企业因为低估这部分成本，导致部署后两年没有升级，最终版本落后到无法使用新功能。

下面这张图是五组取舍在不同组织情境下的倾向分布，可以作为决策时的对照参考。

八、总结与下一步行动

回到开头那场30分钟的争论。如果那家公司在项目启动时就写清了口径定义文档，三个人不会在会议上给出三个数字，那30分钟会用来讨论真正的风险。完成率制度的价值，从来不是让数字更漂亮，而是让组织在同一个事实上讨论问题。

我这几年最深的一个体会是：完成率是一个制度的投影，而不是一个计算的结果。你无法通过优化公式得到可信的完成率，只能通过定义口径、约束采集、配置制衡、记录变更来得到它。公式在整个体系里的权重，可能不到20%。

另一个体会是：完成率下降往往是好消息。当一家企业告诉我他们改造后完成率从85%掉到68%，我的第一反应通常是祝贺。这说明过去被隐藏的问题现在可见了，而可见的问题是能解决的，隐藏的问题不能。

下一步怎么做，我建议按这个顺序推进，不要跳步。

1. 本周内，把你们组织里所有在用的工作流状态名称拉一张清单，做一次语义归并，看看有多少种命名对应同一个含义。这一步不需要任何工具，用表格就能完成。
2. 两周内，写出一页纸的完成定义，包含分子条件、分母边界、快照时点和完成校验项。找一个真实的历史迭代，用新口径重算一遍，看看和原来的数字差多少。
3. 一个月内，选一对制衡指标配上去。如果返工率目前无法采集，就从"迭代内被重新打开的任务数"这个最简单的版本开始。
4. 一个季度内，在项目管理平台里把口径做成强制规则，让状态流转的条件由系统把关而不是靠人自觉。这一步是效率提升最明显的环节，也是最能减少跨部门争议的环节。
5. 两个季度后，再考虑要不要把完成率接进考核。在此之前，让数据先稳定下来。

完成率制度不需要一次做到完美。它需要的是被写下来、被版本化、被持续校准。一套运行了两年、修订过七次的口径文档，比一套设计精美但从未更新过的方案有价值得多。现在就可以开始第一步，把状态清单拉出来。