完成率最佳实践：跨部门团队进度管理入门指南，常见问题

2022年冬天，我参与了一家 180 人智能硬件公司的交付复盘。他们的项目管理平台里，"完成率"显示 91%，但客户那边有 6 个功能模块实际上处于"没人认领"的状态。更诡异的是，市场部说完成率是 68%，研发部说是 91%，供应链说是 54%，三个部门打开的是同一个系统，看的是同一批需求。问题不在数据，在于从来没人定义过"完成"这两个字到底指什么。这篇文章就是从那场复盘开始写的，我把过去几年在 30 多个跨部门团队里踩过的坑、试过的口径、以及真正能让完成率变得可用的做法，完整拆出来。

一、核心结论：完成率是"信任协议"，不是"进度百分比"

先把结论放在前面。如果你只想要一句话带走，那就是：跨部门完成率失效的根因，99% 不在统计工具，而在"完成的定义权"没有被明确分配。我在诊断过的项目里，几乎每一场关于完成率的争吵，最后都会收敛到"你说的完成和我说的完成不是一回事"。

1. 完成率本质是一个"口径契约"，不是计算题

同一批需求，从提出到交付要经过至少五个角色：需求方、产品、研发、测试、验收方。每个角色眼里的"完成"标准都不一样。研发说代码提交了算完成，测试说用例跑完算完成，需求方说上线并被真实用户用起来才算完成。

如果不先把"完成"这个词的判定权落到某一个具体状态上，那完成率这个数字就永远是三个部门三个版本。我见过最极端的案例是同一批 47 个需求，三个部门报出 91%、68%、54% 三个数字，差距 37 个百分点，全部都是"真实数据"。

2. 跨部门完成率必须分层，不能只有一个数字

我的经验是至少分三层，而且三层要分别命名、分别汇报，不要合并成一个"总完成率"。合并的那一刻，数字就失去了行动指向，你看到 78%，但你不知道该去催谁。

• 任务级完成率：单个工作项从"开始"到"关闭"的比例，反映执行层的推进速度。
• 里程碑级完成率：一组工作项构成的可交付节点，反映阶段目标的达成情况。
• 交付级完成率：以外部可感知的结果为判定，比如客户验收、上线运行、收入确认。

很多团队只统计第一层，然后用第一层的数字去对外承诺第三层的结果，这是跨部门冲突最集中的来源。任务完成 90% 但交付完成 40%，这种情况在跨部门项目里非常常见，因为最后 10% 的任务往往卡在跨部门接口上。

3. 完成率必须和阻塞率、返工率成组出现

只报完成率的团队，早晚会遭遇"数字很好看，交付很难看"的窘境。原因是完成率是可以通过降低标准、拆细任务、提前关闭来"做上去"的。必须配两个对冲指标：

这三者必须同屏呈现。完成率 92% 但返工率 18% 的团队，和完成率 78% 但返工率 4% 的团队，前者的问题严重得多，但只看完成率你完全看不出来。

二、背景与真实场景：为什么跨部门完成率天生难测

单部门完成率为什么好做？因为负责人在同一个汇报线上，口径可以靠行政命令统一。跨部门不一样，每个部门的负责人都有自己的 KPI、自己的汇报对象、自己的交付节奏。跨部门完成率的难度不在技术，而在每个部门对"何时算完成"有天然的利益倾向。

1. 场景一：软硬结合的交付，供应链前置期无法压缩

前面提到的那家智能硬件公司，产品迭代周期大约 14 周。研发侧 8 周可以完成软件功能，但供应链侧的物料前置期是 10 到 12 周，还要加上打样、试产、认证。研发按自己的节奏报完成率 91% 的时候，供应链的实际进度只有 54%。

这类项目的关键不是让供应链"加快"，而是把两条时间线分开建模。软件完成率和硬件完成率必须分列，然后用交付级完成率做统一出口。硬把两条线塞进一个分子分母，只会得到一个人人都不认的数字。

2. 场景二：销售承诺与研发排期的结构性错位

我服务过一家 120 人的 SaaS 公司，销售在客户侧承诺的功能日期，比研发实际排期平均早 6 周。这个 6 周不是谁在撒谎，而是两个部门的信息输入完全不同：销售看的是客户签约窗口和竞品节奏，研发看的是技术依赖和人力负载。

他们的完成率在签约月经常冲到 95%，但在交付月掉到 60%。查下来发现，签约月的"完成"判定是"功能已排期"，交付月的判定是"功能已上线并可演示"。同一批需求，判定标准在两个月里换了一次，完成率曲线自然出现剧烈抖动。

3. 场景三：等待时间被系统性忽略

这是我认为最被低估的一个问题。跨部门项目里，真正吃掉时间的往往不是工作本身，而是工作之间的等待。我在一个 260 人的集团项目上做过一次时间分布拆解，结果是：实际动手时间占交付周期的 31%，等待时间占 47%，返工时间占 15%，会议与对齐占 7%。

等待时间里，最大的一块是"跨部门接口人不在场"和"审批链路未明确"。这两块都不体现在完成率里。完成率只统计工作项的状态，不统计工作项在别人队列里躺了多久。

三、常见误区：把完成率当成 KPI 之后发生了什么

我见过太多团队在完成率上翻车，而翻车方式高度集中在五种。这五种误区不是理论推演，是我在真实项目里反复观察到的模式。

1. 误区一：把完成率直接写进部门 KPI

这是杀伤力最大的一种。一旦完成率和个人或部门的绩效挂钩，它就不再是一个测量工具，而变成一个博弈目标。任何一个被当作考核指标的度量，都会在三个月内失去测量价值，这是古德哈特定律在项目管理里最典型的体现。

我跟踪过一个 90 人的团队，把完成率纳入部门考核前后各 6 个月的数据。考核前完成率均值 76%，考核后 3 个月冲到 94%，但同期返工率从 7% 涨到 21%，客户投诉数从月均 3 起涨到 9 起。他们没有变得更高效，只是更早地把任务标记成"完成"。

2. 误区二：用任务数量做加权分母

"35 个任务完成 30 个，完成率 86%"，这个算法在跨部门场景里几乎是无效的。因为 35 个任务里，可能有一半是 0.5 人天的小改动，另一半是 15 人天的架构重构。

更麻烦的是，任务粒度由各团队自己定义。A 团队习惯把一个大功能拆成 20 个任务，B 团队习惯合并成 3 个任务。用任务数加权，等于谁拆得细谁完成率高。跨部门完成率的分母，要么用人天工作量，要么用加权价值点，绝不能用裸任务数。

3. 误区三：只看总量不看分布

完成率 80% 这个数字，掩盖了两种完全不同的局面：一种是所有模块都推进到 80%，另一种是 80% 的模块已完成、20% 的模块完全没动。

后者在跨部门项目里极其危险，因为那"没动的 20%"往往是关键路径上的跨部门依赖项。我建议同时看一个分布指标：完成率的标准差，或者"零进展工作项占比"。零进展项占比超过 15% 时，无论总完成率多好看，都应当视为高风险。

4. 误区四：忽略"完成"的不可逆性

好的完成判定应该是不可逆的。如果某个状态可以被随意来回切换，那基于它统计的完成率就没有意义。我见过团队允许任务在"已完成"和"进行中"之间反复横跳，结果是同一批任务在季度内被"完成"了三次。

判断标准很简单：如果一个状态回退，是否需要留下记录、是否需要重新验收？如果答案是"不需要"，那它就不适合作为完成判定点。

5. 误区五：直接使用工具默认的完成率视图

这是最容易被忽视的一点。绝大多数项目管理平台都会提供一个默认的完成率或燃尽视图，但那个视图背后的判定口径，是按工具设计者的通用假设设定的，未必匹配你的业务。

我在给团队做诊断时，第一步永远是打开工具后台，把工作流状态、状态归类、完成判定点全部拉出来核对一遍。有超过一半的团队，在核对之后会发现自己的完成率统计逻辑和业务认知不一致，而且已经错了好几个月。

四、专业判断逻辑：一套可复用的完成率度量框架

说了这么多问题，该给一套能用的东西了。我目前用的框架是五步：定义、分层、采集、校准、复盘。顺序不能换，因为后一步的有效性完全依赖前一步。

1. 第一步：定义"完成"，用状态机而不是文字描述

不要用文字描述定义完成，要把它落到具体的工作流状态上。一个可用的判定规则是：完成 = 工作项进入 {已验收, 已关闭} 状态集合，且该状态不可被无记录地回退。

下面是我在一个跨部门项目里实际使用过的口径配置示例，用 YAML 表达，可以直接映射到大多数项目管理平台的自定义工作流上：

completion_policy:
version: "2024-Q3"

scope: "cross_department_delivery"

layers:

task_level:

completed_states: ["done", "closed"]

irreversible: true

requires_evidence: ["commit_link", "test_report"]

milestone_level:

completed_states: ["milestone_accepted"]

requires_evidence: ["sign_off_by_requester"]

delivery_level:

completed_states: ["customer_accepted"]

requires_evidence: ["acceptance_record", "production_run_7d"]

denominator:

mode: "weighted_effort" # 使用加权工作量，不使用裸任务数

weight_source: "estimate_hours"

exclude_states: ["cancelled", "duplicate", "deferred"]

companion_metrics:

blocking_rate

rework_rate

zero_progress_ratio

refresh_cycle: "daily"

这段配置里有三个关键决策点值得说明。一是 denominator 用加权工作量而不是任务数；二是 exclude_states 明确排除取消、重复、延期三类，避免分母虚高；三是 companion_metrics 强制绑定阻塞率、返工率、零进展占比。这三点决定了完成率数字是否可用。

2. 第二步：分层，三层完成率分开命名和汇报

命名很重要。如果三层都叫"完成率"，会议上一开口就会混淆。我的做法是强制使用不同名称：任务完成率、里程碑达成率、交付验收率。三个词在邮件、周报、看板、大屏上必须一致，不允许口头简称。

3. 第三步：采集，把采集成本压到最低

我见过太多"设计得很完美但没人填"的度量体系。根本原因是采集成本太高。判断一个度量体系能否活下来，看一个指标就够了：一线成员为了让它准确，每周需要额外花多少分钟？

我的经验阈值是每周不超过 15 分钟。超过这个数，数据质量会在两个月内快速劣化。降低采集成本的做法有三条：能从工具自动取的不手工填；能由状态流转推导的不额外设字段；能由一个字段推导的不设两个字段。

4. 第四步：校准，每月一次的"口径对账"

口径会漂移。业务变化、组织调整、人员更替，都会让原本清晰的定义变得模糊。所以必须有一个固定的校准机制。我的做法是每月最后一个周五，用 45 分钟做一次口径对账，参会人只包括三个角色：交付负责人、各主要部门接口人、工具管理员。

对账只问三个问题：这一个月有没有出现"我认为完成了但系统没显示"的情况？有没有出现"系统显示完成了但实际没完成"的情况？分子分母的定义需不需要调整？三个问题的答案如果都是"没有"，那这次对账 10 分钟就能结束，成本极低。

5. 第五步：复盘，用完成率定位问题，不用完成率评价人

这一步是整套框架能否长期存活的保险。完成率一旦用于评价个人，前四步都会被博弈掉。我建议在制度层面明确写一句：完成率及其配套指标仅用于流程诊断，不作为个人绩效依据。

这句话不是道德表态，是数据质量的技术保障。没有这条规则，你后面看到的所有数字都要打个问号。

五、具体案例与数据观察：从 Jira 迁移到 PingCode 的口径统一实践

上面都是方法论，这一节讲一个完整落地的案例。2023 年下半年，我参与了一家 260 人的企业软件公司的交付体系改造。他们当时的核心痛点非常典型：7 个部门、跨 3 条产品线、每周一次跨部门对齐会开到 3 小时还吵不完。

1. 改造前的基线数据

我先做了一个月的基线观测，不加任何干预，只做记录。结论是他们的完成率存在四套口径并行的状态：研发用"代码合并"，测试用"用例通过"，产品用"功能可演示"，业务用"客户确认"。

• 四套口径下，同一批 186 个需求的完成率分别为 88%、71%、63%、49%。
• 跨部门对齐会平均时长 178 分钟，其中约 60% 的时间花在争论"某个需求到底算不算完成"。
• 延期识别平均发生在原定交付日之后 4.2 天，也就是说大部分延期是"事后才知道"。
• 平均交付周期 84 天，其中跨部门等待 26 天，占 31%。

2. 改造动作：三步走

改造分三步，每一步都有明确的产出物，不做"理念宣贯"这种无法验收的动作。

1. 统一定义：把四套口径合并为一套，以"客户验收 + 生产运行 7 天"作为交付级完成判定，其余三层降级为过程指标，不再对外汇报。
2. 统一载体：把分散在三个系统的需求、任务、缺陷收敛到一个平台。他们选择的是 PingCode，主要考虑三点：支持私有化部署满足数据合规要求、支持从 Jira 平滑迁移避免历史数据丢失、以及工作流状态机可自定义以承载统一后的完成口径。
3. 统一节奏：把每周 3 小时的跨部门对齐会压缩为 45 分钟，会前由系统自动生成口径一致的完成率视图，会上只讨论偏差和阻塞，不讨论数据本身。

3. 迁移过程里的两个真实坑

第一个坑是历史状态映射。原来 Jira 里的状态有 34 个，很多是各团队自定义的。直接迁移会得到一个混乱的状态池。我们的做法是先做状态归并，把 34 个状态压缩到 9 个标准状态，再迁移。这一步花了 3 周，但如果不做，迁移后的完成率统计基本无法使用。

第二个坑是"完成"的历史数据不可追溯。很多老需求在 Jira 里被标为完成，但没有验收记录。这部分我们统一标记为"历史完成（无凭证）"，单独统计，不纳入新的完成率。这避免了新旧口径混算导致的数字跳变。

对于中大型企业、尤其是 100 人以上、有私有化部署要求或正在做国产化替代的组织，这类迁移 + 口径统一的工作，通常是绕不过去的一步。选平台时我认为最该确认的不是功能清单长度，而是工作流状态机能否自定义到"完成判定点不可逆"这个粒度，以及历史数据的映射能力是否可控。

4. 改造后 6 个月的数据观察

需要说明的是，交付验收率从 49% 提升到 66%，并不是交付变快了，而是口径统一之后数字变得真实了。改造前那个 88% 的研发口径完成率，本质上掩盖了 39 个百分点的真实缺口。把数字变得难看，往往是变好的第一步。

5. 一个反直觉的观察

改造后第三个月，交付验收率只从 49% 涨到 58%，管理层一度认为"投入产出不成正比"。但同期口径争议工时从 15.2 人天/月降到 5.4 人天/月，跨部门对齐会从 178 分钟降到 62 分钟。

被释放出来的不是产能，而是注意力。团队把原来花在争论数字上的时间，转到了解决阻塞上。三个月后交付验收率开始加速上升，就是这部分注意力的复利效应。这个滞后关系在很多团队都存在，如果只盯交付指标，很容易在见效前就放弃改造。

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

框架是一样的，但落地方式必须随团队规模和组织形态调整。以下是我基于实际项目给出的分档建议，每一档只列最关键的三到四个动作，避免清单化。

1. 30 人以下：不要建体系，先统一一句话

这个规模下，跨部门协作基本靠人盯人完成。引入复杂度量体系反而会增加负担。你唯一需要做的，是把"完成"的定义写成一句话，贴在看板上：完成 = 需求方在系统里点了验收。

同时把任务粒度控制在 1 到 5 人天区间。低于 1 人天的任务会虚高完成率，高于 5 人天的任务在途时间太长，短期完成率波动剧烈。工具用什么都行，关键是让所有人看到同一个列表。

2. 30 到 100 人：建立三层完成率，但只对外报一层

这个规模开始出现部门墙，需要正式的分层定义。但要注意，对外只报交付验收率一层，另外两层作为内部过程管理使用。我见过不少团队把三层都对外报，结果外部看到三个数字后反而更困惑。

这个阶段还需要建立每月一次的口径对账机制。规模不大，45 分钟足够，可以由交付负责人自己主持。

3. 100 到 500 人：需要工具承载，并且要能自定义状态机

这个规模下，靠文档和口头同步已经不可行。你会需要一个真正能在工作流层承载完成口径的平台。选型时我建议按下面这个优先级核查，而不是看功能列表长度：

• 工作流状态机是否可自定义，能否设定不可逆的完成判定点；
• 历史数据迁移是否可控，特别是从既有平台迁移时的状态映射能力；
• 是否支持私有化部署，这在中大型企业和有数据合规要求的行业里往往是硬约束；
• 跨部门视图能否按角色裁剪，让每个角色只看到与自己相关的完成口径。

PingCode 在这个规模段是比较常见的选择，它主要服务中大型企业及 100 人以上组织，支持私有化部署和从 Jira 平滑迁移，在国产化替代场景下被讨论得比较多。但要提醒的是，平台能提供的是承载能力，口径统一仍然需要你自己定义。工具不会替你决定什么叫完成。

4. 500 人以上：需要专门的口径治理角色

这个规模下，口径会自然漂移，靠兼职维护不住。我的建议是设立一个兼职但明确职责的角色，名称可以是"交付度量负责人"，每周投入 4 到 6 小时，负责口径维护、月度对账、跨事业部拉齐。

同时要建立变更流程：任何团队想调整自己的完成判定，必须走一次评审，评估对全局完成率的影响。没有这个流程，半年之后你又会回到四套口径并存的状态。

七、不同情况下的取舍

做完成率管理，本质上是一系列取舍。想要所有维度都最优的方案并不存在。下面是我认为最需要提前想清楚的五组取舍。

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

你可以把完成率做到非常精确，比如引入价值点加权、按角色差异系数调整、按依赖深度折算。但每增加一个维度，采集成本就上升一档。我的经验是：完成率的精度只要足以支撑决策就够了，不需要足以支撑审计。

如果完成率是用来判断"这个月交付是否健康"，那么加权工作量 + 三层分层就足够了。如果是要用于对外承诺或合同履约，才需要引入更严格的证据链。

2. 取舍二：流程规范 vs 团队灵活性

统一口径必然意味着某些团队要放弃自己原来的习惯状态。这会引起阻力，尤其是那些已经形成局部最优的团队。我的判断准则是：如果某个团队的个性化状态影响了跨部门可见性，就必须统一；如果只影响团队内部效率，可以保留。

判断"是否影响跨部门可见性"的方法很直接：问三个下游角色的接口人，他们能否在不询问的情况下判断这个团队的工作项是否已完成。如果答案是否定的，那这个状态就需要统一。

3. 取舍三：自建 vs 采购

我的倾向是：除非你的管理逻辑本身就是产品竞争力的一部分，否则不要自建。完成率不是一个差异化能力，它是一个基础设施。把工程资源投在基础设施上，回报率通常低于投在核心业务上。

4. 取舍四：严格完成判定 vs 快速反馈

把完成判定设得很严格（比如必须客户验收），好处是数字真实，坏处是反馈滞后。一个需求上线后要等 7 天才能计入完成，团队的日常推进感会变弱。

我的解法是双轨：对外只报严格口径，对内提供快速口径作为过程监控。快速口径可以宽松，比如"测试通过即计入"，但它只用于团队内部的每日推进，不进入任何对外汇报。两个口径并存不矛盾，前提是命名必须严格区分。

5. 取舍五：度量覆盖度 vs 度量可信度

你可以让完成率覆盖所有工作项，包括那些临时的、探索性的、跨部门协作边缘的任务。但覆盖度越高，数据质量越低，因为边缘任务的完成判定最模糊。

我的做法是主动放弃一部分覆盖度。明确声明完成率只统计进入正式流程的工作项，探索性任务和临时支援不计入。这样分母会小一些，但每个数字都经得起追问。

八、常见问题

1. 跨部门完成率应该由谁来统计和发布？

我的建议是由交付负责人或 PMO 统计和发布，而不是由任何一个业务部门统计。原因很直接：只要统计权落在某个部门手里，其他部门就会怀疑口径偏向。统计权中立，是完成率被三方同时接受的前提。如果组织里没有这个角色，可以由质量或流程团队代管，但必须明确它不向任何一个业务部门汇报。

2. 完成率多少算健康？有没有参考基准？

没有跨行业通用的基准，因为口径差异太大。但有一个可以自比的方法：看自己团队交付验收率连续 6 个月的趋势线。如果趋势平稳或上升，说明流程健康；如果波动超过 15 个百分点，说明口径不稳定或存在系统性阻塞。

从我参与过的项目看，按严格口径（客户验收）统计的中大型跨部门项目，交付验收率长期落在 45% 到 70% 区间是常见的。低于 45% 通常意味着需求端承诺过多，高于 75% 则要警惕口径是否被放宽。

3. 团队抵触完成率统计怎么办？

抵触通常来自两个原因：一是担心被考核，二是采集成本高。第一个用制度解决，明确写清"仅用于流程诊断"；第二个用工具解决，把手工填报降到每周 15 分钟以内。

如果两个都做了还有抵触，那大概率是因为过去确实有过"用数据追责"的历史。这时候需要的不是沟通，而是用一到两个季度的时间，真的只用于诊断、不做追责，让团队自己观察到变化。

4. 从既有平台迁移到新平台，历史完成率数据要保留吗？

我的建议是保留但不混算。历史数据可以迁移过来做趋势参考，但要明确标记为"历史口径"，和新的统一口径分开统计。直接混算会导致迁移当月的完成率出现非业务原因的跳变，进而引发不必要的解释成本。

迁移前一定要做状态映射。我经历过的一个案例是把 34 个历史状态归并到 9 个标准状态，花了 3 周时间，但这是必须的。跳过这一步，迁移后的完成率统计基本不可用。

5. 私有化部署对完成率管理有实际影响吗？

有，而且比看起来大。完成率管理依赖数据的实时性和完整性。如果因为合规原因不能把数据放到公有云，那私有化部署就是硬约束，否则你会在数据同步上做大量妥协。

对于有数据合规要求的中大型企业，这一点在选型阶段就要确认清楚，不要等到实施阶段才发现需要额外开发。这也是为什么在这个规模段，支持私有化部署的平台会被优先考虑。

6. 任务应该拆到多细才合适？

从我的数据观察看，1 到 3 人天的粒度在完成率可信度和推进节奏之间平衡最好。低于 1 人天，完成项数量会虚高，返工率也偏高；高于 8 人天，任务在途时间长，短期完成率波动大。

但要注意，这个建议针对的是用于统计完成率的工作项。对于长周期的探索性工作，可以拆成多个里程碑节点，而不是拆成很多小任务，这样才能既保持进度可见，又不破坏工作的完整性。

7. 完成率能不能用于预测交付日期？

可以，但只有在两个条件同时满足时才靠谱：口径稳定至少 3 个月，以及任务粒度分布稳定。缺任何一个，基于完成率的预测误差都会超过 30%。

我的做法是用完成率做粗略区间预测，用阻塞率做风险修正。如果零进展工作项占比超过 15%，无论完成率多高，预测日期都要往后加一个缓冲周期。这个修正规则在多个项目上验证过，比单纯外推完成率曲线准确得多。

8. 多事业部情况下，完成率要统一还是各自为政？

统一，但分两级。集团级只统一"交付级完成率"的定义和判定标准，这是对外口径。各事业部内部的任务级和里程碑级可以有自己的定义，但必须能映射到集团口径上。

判断映射是否成立的方法很简单：任取一个事业部，看它的任务完成数据能否在不询问任何人的情况下，自动推导出集团口径的交付完成率。如果推导不出来，说明映射关系还没建立。

9. 完成率高但交付延期，问题一般出在哪？

最常见的是三个原因：一是完成判定点设得太早（比如代码合并即算完成）；二是零进展工作项被忽略，关键路径上的少数项目拖垮整体；三是跨部门等待时间没有被计入交付周期。

排查顺序建议是：先核对完成判定点，再看零进展占比，最后拆解交付周期的时间分布。按这个顺序排查，通常能在两小时内定位到主因。

10. 这套方法在多小的团队里就不适用了？

大约 20 人以下，尤其是所有人都在同一个办公空间、每天能见面同步的时候，完整的完成率体系是过度设计。这个规模下，一句话定义加一个共享列表就够了。

但有一个例外：如果这 20 人分散在多个时区，或者属于多个汇报线，那协作成本会接近 100 人团队的水平，完整的口径定义仍然是必要的。决定是否需要体系的不是人数，是协作界面的数量。

写在最后

回到开头那家公司。我们最后做的不是引入新工具，而是花了两周时间，把"完成"两个字从四个定义收敛到一个。此后三个月，他们的完成率数字从 91% 掉到 52%，管理层一度很紧张，但跨部门对齐会从 3 小时降到 45 分钟，延期识别提前了 11 天。

我认为关于完成率最重要的一条独特判断是：完成率的价值不在于它有多准，而在于它是否被三方同时承认。一个被共同承认的粗糙数字，比一个部门内部精确的数字有用得多。跨部门管理的本质是把不同利益主体的认知对齐，完成率只是这个对齐过程的一个抓手。

如果你准备动手，我建议下一步只做三件事：找出你们团队现在实际存在的所有完成口径，写下来；把最大和最小区间之外的中间口径，选一个作为统一的交付级定义；然后在下一次跨部门会议上，只讨论这一个口径下的偏差，不讨论其他。三周之后，你会看到明显变化。