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

一 背景

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

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

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

O：

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

KR：

• 增加總的價(jià)值交付率和交付質(zhì)量

• 增加單位研發(fā)成本的平均交付價(jià)值

• 降低單位價(jià)值的平均交付時(shí)長(zhǎng)

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

• 定義、衡量交付價(jià)值

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

• 定義、衡量交付時(shí)長(zhǎng)

• 細(xì)化指標(biāo)

二 如何定義交付價(jià)值？

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

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

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

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

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

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

不完全是技術(shù)方案、代碼的數(shù)量和質(zhì)量，也不完全是KPI指標(biāo)的增量。交付價(jià)值就是按照用戶的需要，對(duì)用戶提供的整個(gè)產(chǎn)品、服務(wù)的數(shù)量和質(zhì)量。這個(gè)定義幾乎是不證自明的，但是把交付價(jià)值定義為客戶價(jià)值，會(huì)不會(huì)讓這件事情更加復(fù)雜，變得更加不可能量化？這就需要我們轉(zhuǎn)變一下思路，通過(guò)按照優(yōu)先級(jí)加權(quán)的需求的工作量來(lái)衡量。

按照優(yōu)先級(jí)加權(quán)的需求的工作量代表著客戶價(jià)值，這里做一些基本假設(shè)（假設(shè)不成立的場(chǎng)景可以作為另外的問(wèn)題解決）。

假設(shè)1：技術(shù)的上游（一般是業(yè)務(wù)、產(chǎn)品）對(duì)于客戶價(jià)值的判斷是基本準(zhǔn)確的

我們知道業(yè)務(wù)是會(huì)試錯(cuò)的，給業(yè)務(wù)小成本試錯(cuò)的機(jī)會(huì)、在業(yè)務(wù)試錯(cuò)的過(guò)程中沉淀一些通用的產(chǎn)品技術(shù)能力，往往不是局部最優(yōu)，但是全局最優(yōu)。

假設(shè)2：技術(shù)的上游會(huì)按照客戶價(jià)值推演出優(yōu)先級(jí)然后給技術(shù)提需求

假設(shè)3：技術(shù)的上游提給技術(shù)的需求是充分的（不存在業(yè)務(wù)產(chǎn)品人員配置的缺失而導(dǎo)致需求質(zhì)量數(shù)量不足的情況）

基于這幾個(gè)假設(shè)，上游提出的需求可能就很大程度上代表著客戶價(jià)值，研發(fā)在非功能性需求方面對(duì)上游的需求做補(bǔ)充。

三 衡量交付價(jià)值

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

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

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

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

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

• 哪些功能自研、哪些功能靠購(gòu)買，有時(shí)候真的得算一筆帳。

• 軟件開(kāi)發(fā)是一個(gè)邊際成本遞減的行業(yè)，如何讓功能更簡(jiǎn)單的得到復(fù)用，可能是對(duì)效能提升最有幫助的部分之一（復(fù)用50個(gè)人日的功能模塊，就幾乎等于省了50人日的研發(fā)成本。當(dāng)然也可能存在復(fù)用及后期維護(hù)的成本大于新建成本的情況，需要有良好的設(shè)計(jì)去規(guī)避）。

五 定義交付時(shí)長(zhǎng)

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

于是單位價(jià)值的平均交付時(shí)長(zhǎng)，就變成了以下公式：

六 如何衡量交付時(shí)長(zhǎng)

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

• 需求立項(xiàng)到評(píng)審的時(shí)長(zhǎng)

• 需求評(píng)審到技術(shù)方案評(píng)審的時(shí)長(zhǎng)（如果項(xiàng)目很大可能會(huì)有多個(gè)層次的設(shè)計(jì)方案）

• 技術(shù)方案評(píng)審?fù)瓿傻介_(kāi)發(fā)完成自測(cè)的時(shí)長(zhǎng)

• 自測(cè)的時(shí)長(zhǎng)

• 多端聯(lián)調(diào)的時(shí)長(zhǎng)

• 測(cè)試的時(shí)長(zhǎng)

• bug驗(yàn)證的時(shí)長(zhǎng)，bug的數(shù)量（reopen可以數(shù)量+1）

• 環(huán)境部署等待的時(shí)長(zhǎng)

• 代碼合并的時(shí)長(zhǎng)（主干發(fā)布的情況下）

• 回歸的時(shí)長(zhǎng)

• 發(fā)布的時(shí)長(zhǎng)

• 灰度的時(shí)長(zhǎng)

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

• 需求的拆分成基本的功能閉環(huán)進(jìn)行迭代（以不引入或少引入測(cè)試的重復(fù)回歸為標(biāo)準(zhǔn)），或許能比較有效的降低需求價(jià)值量的平均交付時(shí)長(zhǎng)。

• 自測(cè)充分、減少bug數(shù)量，最終減少聯(lián)調(diào)、測(cè)試回歸的次數(shù)和時(shí)長(zhǎng)，在一定的單測(cè)覆蓋率要求以前，是收益大于成本的。

• 代碼合并有時(shí)候沖突解決很麻煩，會(huì)導(dǎo)致一次部署的時(shí)間很長(zhǎng)，且代碼合并引入了更多次的測(cè)試回歸工作（這可能是某些BU往主干開(kāi)發(fā)分支發(fā)布走的原因之一）。所以基于業(yè)務(wù)的理解，進(jìn)行應(yīng)用的拆分，減少單個(gè)應(yīng)用的并發(fā)數(shù)量，也可以提升研發(fā)效能。

• 在缺乏有效的項(xiàng)目管理的情況下，資源的相互等待可能是項(xiàng)目延期的一大因素，有時(shí)候某端開(kāi)發(fā)完了，另一端資源沒(méi)到位，一直不能聯(lián)調(diào)提測(cè)。項(xiàng)目管理的同學(xué)對(duì)于資源目前的分工和瓶頸應(yīng)該給上游及時(shí)的反饋。

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

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

七 最后

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

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

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

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

原文鏈接：https://developer.aliyun.com/article/781527?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開(kāi)發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開(kāi)發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開(kāi)發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的如何量化技术团队的效能？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。