导读：衡量技术团队的效能，是不是只要摆出一堆数字指标就行？对交付价值的定义，通常有哪些误区？好的量化指标，一定会带来好的结果吗？本文从定义、衡量交付价值、研发成本、交付时长以及细化指标四个方面，分享如何量化效能。
一 背景
项目管理的理论有很多，但大多是从理念和方法论的角度出发。当在一个团队推行项目管理的某种实践的时候，不免被挑战的一个问题：“如何衡量技术团队的效能”。于是不得不试图去把逻辑题转成数学题，用数字指标去证明一些“不证自明”的方法论。
但如果我们只是摆出一些指标，不可避免地会陷入“上有政策、下有对策”的循环（只要不加其他约束，数字还不是想怎么优化怎么优化）。我们也应该能看到这些数字背后，需要坚持的一些原则，和需要遵守的一些硬性标准。
假设目标是提高技术团队的效能，会得到如下OKR（Objectives and Key Results，目标与关键成果法）：
O：
提高技术团队的效能
KR：
增加总的价值交付率和交付质量
增加单位研发成本的平均交付价值
降低单位价值的平均交付时长
本篇侧重点在如何量化，而不是如何提高。所以接下来继续分解，我们要做的事情就是：
定义、衡量交付价值
定义、衡量研发成本
定义、衡量交付时长
细化指标
二 如何定义交付价值？
1 这里可能会存在两个误区
误区1：交付的价值就是产出的方案、代码的数量和质量
这样衡量交付价值，就很少有人愿意建设公共设施了（因为质量好不好很难量化，建设公共设施初期的耗时往往明显大于直接完成业务需求），也很少有人愿意使用公共设施（因为用别人的，不如自己建，还能拿个结果）。而对于技术团队，长期创造价值的能力，离不开公共设施的完备和对公共设施的使用。
误区2：交付的价值就是业务KPI中指标的增量
有很多功能并不带来直接的增量，或者比较难以衡量，但可能带来公司的竞争壁垒，如产品的体验。这样衡量交付价值，带来的问题就是，大家都只关注短平快的增量功能（比如营销），最终产品的竞争力下降。
2 我目前的答案：交付价值是需求背后的客户价值
不完全是技术方案、代码的数量和质量，也不完全是KPI指标的增量。交付价值就是按照用户的需要，对用户提供的整个产品、服务的数量和质量。这个定义几乎是不证自明的，但是把交付价值定义为客户价值，会不会让这件事情更加复杂，变得更加不可能量化？这就需要我们转变一下思路，通过按照优先级加权的需求的工作量来衡量。
按照优先级加权的需求的工作量代表着客户价值，这里做一些基本假设（假设不成立的场景可以作为另外的问题解决）。
假设1：技术的上游（一般是业务、产品）对于客户价值的判断是基本准确的
我们知道业务是会试错的，给业务小成本试错的机会、在业务试错的过程中沉淀一些通用的产品技术能力，往往不是局部最优，但是全局最优。
假设2：技术的上游会按照客户价值推演出优先级然后给技术提需求
假设3：技术的上游提给技术的需求是充分的（不存在业务产品人员配置的缺失而导致需求质量数量不足的情况）
基于这几个假设，上游提出的需求可能就很大程度上代表着客户价值，研发在非功能性需求方面对上游的需求做补充。
三 衡量交付价值
交付价值有个非常主观但有效的衡量方式，是上游（一般是产品业务）的满意度。背后的逻辑是，交付价值（背后代表的客户价值）往往很难量化，而产品业务的满意度，体现了技术与业务是否很好的协同，也反映了技术是否很好的交付价值。