在很多公司里，交付经理的 KPI 看起来非常“丰富”。

• 项目按期率
• 里程碑完成率
• 客户满意度
• 验收通过率
• 投诉数量

但如果你真的在一线做过交付，就会慢慢意识到一件事：

这些 KPI，大多数只是“结果的影子”，
而不是交付真正被评价的那一刻。

交付经理真正被审视的，从来不是报表里的数字。

一、交付真正被考核的，从来只有一个场景

这个场景你一定不陌生。

项目做到最后阶段，系统已经上线，
功能也基本齐全，但问题开始密集暴露：

• 有些功能不好用
• 有些流程绕不开
• 有些性能不稳定
• 有些需求当初没说清

客户没有明确表态，没有确认，也没有反对。

只是说了一句：

这个问题，我们再考虑一下。

对很多人来说，这意味着“还有机会”。

但对交付来说，这是一个高度危险的信号：
——判断权已经不在你手里了。

真正成熟的交付，不会等客户“做决定”，
而是会把一个模糊的状态，重新拉回到可判断、可承担的范围内。

二、交付经理的KPI

在真实项目中，你几乎一定会面对：

• 需求在过程中变化
• 资源在过程中被削减
• 时间在过程中被压缩
• 外部环境在过程中变化

如果交付的 KPI 设定为“完美结果”，
那交付经理唯一能做的，就是——
不断失败。

成熟的交付，不是追求完美，
而是追求一个判断：

在当下的约束条件下，
什么样的结果，客户是“接得住”的？

三、交付经理为什么天然关注“接受度”，而不是“完成度”？

这是交付和项目、产品的一个本质差异。

• 产品经理关心：方向是不是对
• 项目经理关心：事情有没有按计划推进
• 交付经理关心：这个结果，现实世界买不买账

现实世界包括什么？

• 客户能不能用
• 用了会不会出事故
• 出事故之后谁负责
• 后续还能不能继续合作

所以你会发现一个很有意思的现象：

越成熟的交付经理，
越少说“我们已经完成了”，
而是反复问：“能不能接受现在这个状态？”

四、为什么“可被接受”是一种极难的能力？

因为它不是一个技术判断，而是一个综合判断。

一个结果是否“可被接受”，至少需要你同时判断四件事：

1️⃣ 技术底线有没有被突破？

• 会不会引发系统性风险？
• 有没有不可逆的问题？

这是硬底线，不能谈条件。

2️⃣ 业务目标是否还能成立？

• 核心流程是否跑通？
• 关键指标是否还能支撑业务？

如果业务目标不成立，再稳定也没意义。

3️⃣ 客户的真实预期在哪里？

注意，是真实预期，不是嘴上说的。

有些客户嘴上说“可以接受”，
但你心里要非常清楚：

这是暂时妥协，还是长期认可？

4️⃣ 后续空间是否被保留？

一个成熟的交付，会为未来留出空间：

• 能否渐进式优化？
• 是否有清晰的补偿或迭代计划？

如果这一步没想清楚，
今天的“可接受”，
就是明天的“翻旧账”。

五、很多交付失败，其实败在“误判可接受”

我见过太多项目，
问题不在技术，也不在态度，
而在一个判断上：

交付方以为客户能接受，
但客户其实并没有。

这种错判，通常来自三个原因：

把“沉默”当成“同意”

客户不说话，
不代表他接受了，
很可能只是暂时没力气继续拉扯。

把“签字”当成“认可”

签字有时候只是为了推进流程，
而不是心理认同。

你如果把签字当 KPI，
迟早会被现实补一刀。

把“妥协”当成“共识”

客户在压力下的妥协，
并不等于他真正接受了这个结果。

六、真正成熟的交付 KPI，是一种“判断力”

说到这里，我想给你一个非常重要的判断：

交付经理真正的 KPI，不是结果本身，
而是对“可被接受边界”的判断力。

这是一种长期积累出来的能力：

• 你见过足够多失败的项目
• 你理解技术和业务的真实限制
• 你知道客户在哪些点上会翻脸
• 你也知道哪些问题，时间真的能解决

所以交付的价值，
不在于“交了多少项目”，
而在于：

你有没有把事情，交到一个“不会炸”的状态。

七、为什么交付经理的 KPI 很难量化？

因为“可被接受”本身就是一个灰度概念。

它不像：

• 上线时间
• 功能数量
• Bug 数

那样可以简单统计。

但你在组织里，一定能分辨出两种交付：

• 一种是：项目交完，关系也断了
• 另一种是：项目不完美，但合作还能继续

这中间的差异，就是交付真正的 KPI。

八、交付不是完成，是被现实接住

我想用一句非常“交付感”的话，来结束这一讲：

交付不是把事情推到终点，
而是把结果，交到一个能被现实接住的位置。

不是系统不再出问题，
而是出问题时，不会一地鸡毛；
不是需求全部满足，
而是核心价值没有塌。

如果你正在做交付，
并且你经常感到累、纠结、两头不讨好，
那很可能不是你做得不够好，
而是你正在承担一个——
很少被真正理解，但极其重要的 KPI。

这，就是交付经理真正的考核标准。