[[379128]]

衡量技術(shù)團(tuán)隊的效能，是不是只要擺出一堆數(shù)字指標(biāo)就行?對交付價值的定義，通常有哪些誤區(qū)?好的量化指標(biāo)，一定會帶來好的結(jié)果嗎?本文從定義、衡量交付價值、研發(fā)成本、交付時長以及細(xì)化指標(biāo)四個方面，分享如何量化效能。

一 背景

項目管理的理論有很多，但大多是從理念和方法論的角度出發(fā)。當(dāng)在一個團(tuán)隊推行項目管理的某種實踐的時候，不免被挑戰(zhàn)的一個問題：“如何衡量技術(shù)團(tuán)隊的效能”。于是不得不試圖去把邏輯題轉(zhuǎn)成數(shù)學(xué)題，用數(shù)字指標(biāo)去證明一些“不證自明”的方法論。

但如果我們只是擺出一些指標(biāo)，不可避免地會陷入“上有政策、下有對策”的循環(huán)(只要不加其他約束，數(shù)字還不是想怎么優(yōu)化怎么優(yōu)化)。我們也應(yīng)該能看到這些數(shù)字背后，需要堅持的一些原則，和需要遵守的一些硬性標(biāo)準(zhǔn)。

假設(shè)目標(biāo)是提高技術(shù)團(tuán)隊的效能，會得到如下OKR(Objectives and Key Results，目標(biāo)與關(guān)鍵成果法)：

O：

• 提高技術(shù)團(tuán)隊的效能

KR：

• 增加總的價值交付率和交付質(zhì)量
• 增加單位研發(fā)成本的平均交付價值
• 降低單位價值的平均交付時長

本篇側(cè)重點在如何量化，而不是如何提高。所以接下來繼續(xù)分解，我們要做的事情就是：

• 定義、衡量交付價值
• 定義、衡量研發(fā)成本
• 定義、衡量交付時長
• 細(xì)化指標(biāo)

二 如何定義交付價值?

1 這里可能會存在兩個誤區(qū)

誤區(qū)1：交付的價值就是產(chǎn)出的方案、代碼的數(shù)量和質(zhì)量

這樣衡量交付價值，就很少有人愿意建設(shè)公共設(shè)施了(因為質(zhì)量好不好很難量化，建設(shè)公共設(shè)施初期的耗時往往明顯大于直接完成業(yè)務(wù)需求)，也很少有人愿意使用公共設(shè)施(因為用別人的，不如自己建，還能拿個結(jié)果)。而對于技術(shù)團(tuán)隊，長期創(chuàng)造價值的能力，離不開公共設(shè)施的完備和對公共設(shè)施的使用。

誤區(qū)2：交付的價值就是業(yè)務(wù)KPI中指標(biāo)的增量

有很多功能并不帶來直接的增量，或者比較難以衡量，但可能帶來公司的競爭壁壘，如產(chǎn)品的體驗。這樣衡量交付價值，帶來的問題就是，大家都只關(guān)注短平快的增量功能(比如營銷)，最終產(chǎn)品的競爭力下降。

2 我目前的答案：交付價值是需求背后的客戶價值

不完全是技術(shù)方案、代碼的數(shù)量和質(zhì)量，也不完全是KPI指標(biāo)的增量。交付價值就是按照用戶的需要，對用戶提供的整個產(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)品)對于客戶價值的判斷是基本準(zhǔn)確的

我們知道業(yè)務(wù)是會試錯的，給業(yè)務(wù)小成本試錯的機(jī)會、在業(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ā)在非功能性需求方面對上游的需求做補(bǔ)充。

三 衡量交付價值

交付價值有個非常主觀但有效的衡量方式，是上游(一般是產(chǎn)品業(yè)務(wù))的滿意度。背后的邏輯是，交付價值(背后代表的客戶價值)往往很難量化，而產(chǎn)品業(yè)務(wù)的滿意度，體現(xiàn)了技術(shù)與業(yè)務(wù)是否很好的協(xié)同，也反映了技術(shù)是否很好的交付價值。

需求的工作量不應(yīng)該通過人日來評估，因為不同團(tuán)隊，對于相同功能點的開發(fā)時長是不同的。需求的工作量的單位應(yīng)該是分解到最后的功能點數(shù)量。再細(xì)化一些，對于服務(wù)端是領(lǐng)域模型、領(lǐng)域服務(wù)數(shù)量，流程分支節(jié)點數(shù)量，對于前端、交互我不是很了解，但偏展示層可能更多的是頁面區(qū)塊、交互流程、行動點的數(shù)量。這些已經(jīng)有量化的可能性了。

四 定義、衡量研發(fā)成本

研發(fā)成本，在一般的工程效能里面有時候會被簡單的理解為人日，單純的交付人日的衡量，其實比較簡單，整個團(tuán)隊的 人數(shù)*工作天數(shù)。但容易被流程設(shè)計者忽視的是，站在企業(yè)成本的視角，交付人日，可能還要按照開發(fā)人員的收入進(jìn)行加權(quán)。從這個角度來看，技術(shù)團(tuán)隊效能里面的研發(fā)成本，準(zhǔn)確的來說就是公司對于研發(fā)的金錢投入，包括購買服務(wù)器、云服務(wù)、培訓(xùn)、行政投入。

這部分對于提升效能的啟發(fā)是：

• 哪些功能自研、哪些功能靠購買，有時候真的得算一筆帳。
• 軟件開發(fā)是一個邊際成本遞減的行業(yè)，如何讓功能更簡單的得到復(fù)用，可能是對效能提升最有幫助的部分之一(復(fù)用50個人日的功能模塊，就幾乎等于省了50人日的研發(fā)成本。當(dāng)然也可能存在復(fù)用及后期維護(hù)的成本大于新建成本的情況，需要有良好的設(shè)計去規(guī)避)。

五 定義交付時長

我自己之前曾經(jīng)陷入一個誤區(qū)，認(rèn)為交付時長就是從開始開發(fā)，到完成上線，這個就是交付時長。但是回到客戶價值這個維度來思考，技術(shù)團(tuán)隊交付時長(這個時候可能說產(chǎn)研團(tuán)隊更合適一些)，應(yīng)該是從業(yè)務(wù)的一個想法，到驗證、立項、完成發(fā)布、灰度，到最終用戶可以真正使用的時長。

于是單位價值的平均交付時長，就變成了以下公式：

六 如何衡量交付時長

衡量交付時長其實也比較簡單，記錄下業(yè)務(wù)提出該功能的時間以及功能開發(fā)的時間。難點可能是整個價值流交付過程中細(xì)化的指標(biāo)，而細(xì)化的指標(biāo)更能幫助我們發(fā)現(xiàn)問題。于是我們可以從一般項目的生命周期來看，哪些節(jié)點的時長會影響我們的交付：

• 需求立項到評審的時長
• 需求評審到技術(shù)方案評審的時長(如果項目很大可能會有多個層次的設(shè)計方案)
• 技術(shù)方案評審?fù)瓿傻介_發(fā)完成自測的時長
• 自測的時長
• 多端聯(lián)調(diào)的時長
• 測試的時長
• bug驗證的時長，bug的數(shù)量(reopen可以數(shù)量+1)
• 環(huán)境部署等待的時長
• 代碼合并的時長(主干發(fā)布的情況下)
• 回歸的時長
• 發(fā)布的時長
• 灰度的時長

這部分對于提升效能容易忽視或有啟發(fā)的點是：

• 需求的拆分成基本的功能閉環(huán)進(jìn)行迭代(以不引入或少引入測試的重復(fù)回歸為標(biāo)準(zhǔn))，或許能比較有效的降低需求價值量的平均交付時長。
• 自測充分、減少bug數(shù)量，最終減少聯(lián)調(diào)、測試回歸的次數(shù)和時長，在一定的單測覆蓋率要求以前，是收益大于成本的。
• 代碼合并有時候沖突解決很麻煩，會導(dǎo)致一次部署的時間很長，且代碼合并引入了更多次的測試回歸工作(這可能是某些BU往主干開發(fā)分支發(fā)布走的原因之一)。所以基于業(yè)務(wù)的理解，進(jìn)行應(yīng)用的拆分，減少單個應(yīng)用的并發(fā)數(shù)量，也可以提升研發(fā)效能。
• 在缺乏有效的項目管理的情況下，資源的相互等待可能是項目延期的一大因素，有時候某端開發(fā)完了，另一端資源沒到位，一直不能聯(lián)調(diào)提測。項目管理的同學(xué)對于資源目前的分工和瓶頸應(yīng)該給上游及時的反饋。

容易陷入誤區(qū)的點是：

• 技術(shù)方案(架構(gòu)、詳細(xì)設(shè)計)的評審既然是很大的一塊耗時，是不是可以直接寫代碼，少寫方案。我理解在技術(shù)方案寫不熟練的情況下，寫技術(shù)方案確實比較耗時。但是技術(shù)方案體現(xiàn)的是分析設(shè)計的過程和結(jié)果，這部分如果不寫出來，增加的是大量的溝通成本。而分析設(shè)計就算不寫出來，這部分工作量在編寫代碼的時候也是沒辦法省略掉的，只是變成了在大腦中進(jìn)行(也許在大腦中真的不如在紙上寫出來來的快和清晰，真的省略了設(shè)計，最終就會成為技術(shù)負(fù)債)。我個人感覺對于多大的需求需要技術(shù)方案評審的比較好的實踐，是以Code Review能否不基于技術(shù)方案直接閱讀代碼為準(zhǔn)。

七 最后

但我仍然認(rèn)為，好的量化的指標(biāo)往往是好的結(jié)果的必要不充分條件。簡單粗暴的優(yōu)化某項指標(biāo)往往會因為兩個問題而使得最終的結(jié)果背道而馳：

某項指標(biāo)變好，帶來的是其他指標(biāo)的降低，局部最優(yōu)并非全局最優(yōu)(如：取消技術(shù)方案的編寫和評審，造成的是編碼時間或者后期維護(hù)時間的增加)。

效能是多個變量共同作用的結(jié)果，缺乏理論基礎(chǔ)和方法論的情況下，很可能在短期優(yōu)化指標(biāo)的時候，忽略了長期的團(tuán)隊成長、系統(tǒng)能力沉淀等因素;或是忽視了業(yè)務(wù)方滿意度等難以量化的因素。

所以，效能的優(yōu)化，不止應(yīng)該有指標(biāo)，還應(yīng)該有路徑，而路徑往往是最難的部分。