導(dǎo)讀：衡量技術(shù)團隊的效能，是不是只要擺出一堆數(shù)字指標就行？對交付價值的定義，通常有哪些誤區(qū)？好的量化指標，一定會帶來好的結(jié)果嗎？本文從定義、衡量交付價值、研發(fā)成本、交付時長以及細化指標四個方面，分享如何量化效能。
一 背景
項目管理的理論有很多，但大多是從理念和方法論的角度出發(fā)。當在一個團隊推行項目管理的某種實踐的時候，不免被挑戰(zhàn)的一個問題：“如何衡量技術(shù)團隊的效能”。于是不得不試圖去把邏輯題轉(zhuǎn)成數(shù)學題，用數(shù)字指標去證明一些“不證自明”的方法論。
但如果我們只是擺出一些指標，不可避免地會陷入“上有政策、下有對策”的循環(huán)（只要不加其他約束，數(shù)字還不是想怎么優(yōu)化怎么優(yōu)化）。我們也應(yīng)該能看到這些數(shù)字背后，需要堅持的一些原則，和需要遵守的一些硬性標準。
假設(shè)目標是提高技術(shù)團隊的效能，會得到如下OKR（Objectives and Key Results，目標與關(guān)鍵成果法）：
O：
提高技術(shù)團隊的效能
KR：
增加總的價值交付率和交付質(zhì)量
增加單位研發(fā)成本的平均交付價值
降低單位價值的平均交付時長
本篇側(cè)重點在如何量化，而不是如何提高。所以接下來繼續(xù)分解，我們要做的事情就是：
定義、衡量交付價值
定義、衡量研發(fā)成本
定義、衡量交付時長
細化指標
二 如何定義交付價值？
1 這里可能會存在兩個誤區(qū)
誤區(qū)1：交付的價值就是產(chǎn)出的方案、代碼的數(shù)量和質(zhì)量
這樣衡量交付價值，就很少有人愿意建設(shè)公共設(shè)施了（因為質(zhì)量好不好很難量化，建設(shè)公共設(shè)施初期的耗時往往明顯大于直接完成業(yè)務(wù)需求），也很少有人愿意使用公共設(shè)施（因為用別人的，不如自己建，還能拿個結(jié)果）。而對于技術(shù)團隊，長期創(chuàng)造價值的能力，離不開公共設(shè)施的完備和對公共設(shè)施的使用。
誤區(qū)2：交付的價值就是業(yè)務(wù)KPI中指標的增量
有很多功能并不帶來直接的增量，或者比較難以衡量，但可能帶來公司的競爭壁壘，如產(chǎn)品的體驗。這樣衡量交付價值，帶來的問題就是，大家都只關(guān)注短平快的增量功能（比如營銷），最終產(chǎn)品的競爭力下降。
2 我目前的答案：交付價值是需求背后的客戶價值
不完全是技術(shù)方案、代碼的數(shù)量和質(zhì)量，也不完全是KPI指標的增量。交付價值就是按照用戶的需要，對用戶提供的整個產(chǎn)品、服務(wù)的數(shù)量和質(zhì)量。這個定義幾乎是不證自明的，但是把交付價值定義為客戶價值，會不會讓這件事情更加復(fù)雜，變得更加不可能量化？這就需要我們轉(zhuǎn)變一下思路，通過按照優(yōu)先級加權(quán)的需求的工作量來衡量。
按照優(yōu)先級加權(quán)的需求的工作量代表著客戶價值，這里做一些基本假設(shè)（假設(shè)不成立的場景可以作為另外的問題解決）。
假設(shè)1：技術(shù)的上游（一般是業(yè)務(wù)、產(chǎn)品）對于客戶價值的判斷是基本準確的
我們知道業(yè)務(wù)是會試錯的，給業(yè)務(wù)小成本試錯的機會、在業(yè)務(wù)試錯的過程中沉淀一些通用的產(chǎn)品技術(shù)能力，往往不是局部最優(yōu)，但是全局最優(yōu)。
假設(shè)2：技術(shù)的上游會按照客戶價值推演出優(yōu)先級然后給技術(shù)提需求
假設(shè)3：技術(shù)的上游提給技術(shù)的需求是充分的（不存在業(yè)務(wù)產(chǎn)品人員配置的缺失而導(dǎo)致需求質(zhì)量數(shù)量不足的情況）
基于這幾個假設(shè)，上游提出的需求可能就很大程度上代表著客戶價值，研發(fā)在非功能性需求方面對上游的需求做補充。
三 衡量交付價值
交付價值有個非常主觀但有效的衡量方式，是上游（一般是產(chǎn)品業(yè)務(wù)）的滿意度。背后的邏輯是，交付價值（背后代表的客戶價值）往往很難量化，而產(chǎn)品業(yè)務(wù)的滿意度，體現(xiàn)了技術(shù)與業(yè)務(wù)是否很好的協(xié)同，也反映了技術(shù)是否很好的交付價值。