研發(fā)考核難的本質(zhì)是因?yàn)檫@三個(gè)特點(diǎn)

這里是Z哥的個(gè)人公眾號(hào)

每周五11：45 按時(shí)送達(dá)

當(dāng)然了，也會(huì)時(shí)不時(shí)加個(gè)餐～

我的第「212」篇原創(chuàng)敬上

大家好，我是Z哥。我坦白，這篇是早就寫好的庫存文章，包括上周的那篇也是。

原因是最近跳槽了，到新公司忙得飛起，都沒時(shí)間寫文章。還好我之前未雨綢繆準(zhǔn)備了幾篇提前寫好的文章作為余量～

我盡量能保持不斷更，如果實(shí)在頂不住就周五的時(shí)候給大家請(qǐng)假哈。

好了，回到這次聊的正題。

研發(fā)考核難是整個(gè)軟件開發(fā)領(lǐng)域眾所周知的問題，甚至可以說是跨世紀(jì)的難題了（上個(gè)世紀(jì)開始至今未被有效解決）。

近期我對(duì)這個(gè)問題有了一些新的思考，在這里和大家分享交流一下。

很多人覺得因?yàn)檠邪l(fā)考核很難考，所以索性就不考了。這個(gè)就有點(diǎn)因噎廢食了。

首先我們要搞清楚，考核存在的意義是什么？

我的理解是：為了達(dá)成團(tuán)隊(duì)的共同目標(biāo)。為了更好的管理團(tuán)隊(duì)、驅(qū)動(dòng)團(tuán)隊(duì)力往一處使。

但是管理大師德魯克又說過：

你如果無法度量它，就無法管理它。

德魯克

這句話既然能被各個(gè)時(shí)代的管理者所追捧，存在了幾十年，自然有它的道理。

所以，不管我們是不是為了考核，都得找到度量的方式方法。

有些團(tuán)隊(duì)的確找到了不少度量指標(biāo)，但是大多偏向技術(shù)層面，包括我們團(tuán)隊(duì)之前也是如此。

這些指標(biāo)一旦在具體實(shí)施之后往往發(fā)現(xiàn)效果甚至不如沒有考核的時(shí)候。這個(gè)背后的原因也有很多文章提到過，就是那些指標(biāo)不適合考核。

也有一些人經(jīng)歷了上面這個(gè)階段后覺得研發(fā)的考核不好做，不好量化。實(shí)則是因?yàn)檎也坏侥欠N直擊要害的關(guān)鍵指標(biāo)。

從這個(gè)問題的本質(zhì)上來說，大家之所以覺得研發(fā)考核難本質(zhì)是由于研發(fā)工作的三個(gè)特點(diǎn)導(dǎo)致的。

01? 無法標(biāo)準(zhǔn)化

這里的無法標(biāo)準(zhǔn)化并不只是難以度量，而是說同樣完成一個(gè)任務(wù)，不同的人會(huì)有不同的做法，最終的結(jié)果也可能會(huì)差別很大。

比如，同一個(gè)任務(wù)，有的人做了 5 天，有的人做了 10 天；有的人喜歡花很多時(shí)間在前期的設(shè)計(jì)階段，有的人則會(huì)花更多時(shí)間在后期的自測上。但是你也不能說一定是誰的方式更好。

02? 工作透明度低

實(shí)現(xiàn)同樣一個(gè)功能，如果有合理的代碼封裝，可能只要 100 行代碼。但是如果不花時(shí)間去構(gòu)思封裝，那么可能是 500 行，甚至是 1000 行。

此時(shí)，如果沒有第三者進(jìn)行 codereview 的話，甚至可能會(huì)覺得寫 1000 行代碼的人產(chǎn)出更大。

03? 工作時(shí)間的碎片化

不得不說，大多數(shù)人的工作時(shí)間其實(shí)大部分時(shí)候很難完全由自己掌控，一會(huì)有人找你問個(gè)事，一會(huì)需要參加一個(gè)會(huì)，一會(huì)又來個(gè)電話接一下。

這些被動(dòng)的意外之事都會(huì)使得做度量這件事變得困難，甚至還會(huì)將原來的計(jì)劃打亂，導(dǎo)致某些考核指標(biāo)出現(xiàn)失真。

Z哥覺得研發(fā)考核指標(biāo)怎么定這件事應(yīng)該分為兩個(gè)問題去看。

• 能夠度量的指標(biāo)有哪些？

• 怎么考核？

這兩個(gè)問題之間其實(shí)沒有必然聯(lián)系，如果老想著一箭雙雕，一次解決兩個(gè)問題，就會(huì)陷入前面提到的困境中。

我認(rèn)為大部分的指標(biāo)是用來作為幫助決策的信息源，而用于考核的指標(biāo)不一定要多，要有業(yè)務(wù)價(jià)值。具體我來展開說說。

/01? 能夠度量的指標(biāo)有哪些/

相信有不少指標(biāo)已經(jīng)馬上在你的腦海中跳出來了：

• 代碼行數(shù)

• 工時(shí)

• bug 數(shù)

• ……

很多講考核的文章都會(huì)對(duì)這些指標(biāo)嗤之以鼻，因?yàn)檫@些指標(biāo)不適合用來考核，這是針對(duì)流水線工作性質(zhì)的考核產(chǎn)物。這點(diǎn)不否認(rèn)。

但是也不能否認(rèn)，這些簡單的指標(biāo)中也蘊(yùn)含著有價(jià)值的信息。

因此在我的理念里，認(rèn)為不應(yīng)該主動(dòng)放棄任何能被度量的指標(biāo)。正如前面所說，研發(fā)工作本身就具有無法標(biāo)準(zhǔn)化、工作透明度低、工作時(shí)間的碎片化的特點(diǎn)。我們好不容易找到一些指標(biāo)能夠幫助我們更清楚的認(rèn)識(shí)我們的工作做得到底如何，為什么不要呢？

不適合考核不等于我們可以忽略他們。這也是我認(rèn)為要將這事分為「能夠度量的指標(biāo)有哪些？」和「怎么考核？」的原因。

除了這些大家都知道的指標(biāo)，還有很多指標(biāo)可以被度量。它們主要分為兩個(gè)維度：過程指標(biāo)和結(jié)果指標(biāo)。

常見的過程指標(biāo)有：需求響應(yīng)周期、發(fā)布前置時(shí)間、交付吞吐量、線上問題平均解決時(shí)長等；結(jié)果指標(biāo)有：日均新增 bug 數(shù)，日均 bug 庫存數(shù)，線上問題數(shù)量等。

如果你所在的團(tuán)隊(duì)對(duì)工程效率比較重視，相信還有不少指標(biāo)可以被度量出來。

這些指標(biāo)有什么用呢，我們需要每天觀察他們的變化，便于及時(shí)發(fā)現(xiàn)團(tuán)隊(duì)里正在發(fā)生的變化是否符合預(yù)期。比如，

• 最近并沒有太多并行開發(fā)的版本，為什么平均交付時(shí)間反而變長了？是不是不夠敏捷？

• 比如最近生產(chǎn)環(huán)境的 bug 數(shù)明顯變多了，是不是質(zhì)量團(tuán)隊(duì)出了什么狀況？

• ……

/02 ?怎么考核？/

用上面列出的這些指標(biāo)來考核嗎？自然不是。

Z哥認(rèn)為考核還是得從業(yè)務(wù)下手，要想辦法找到與技術(shù)有一定關(guān)系的業(yè)務(wù)指標(biāo)，比如，DAU、用戶平均停留時(shí)長等等。

可能很多人第一眼會(huì)覺得說，這些指標(biāo)有很大比例是由業(yè)務(wù)決定的，技術(shù)在其中起不了什么作用。

其實(shí)并不然，你想象一下。如果我們的拉新用戶承接頁的穩(wěn)定性不好，或者核心業(yè)務(wù)鏈路經(jīng)常出錯(cuò)，這對(duì) DAU 和用戶平均停留時(shí)長必然會(huì)造成不好的影響。所以，業(yè)務(wù)指標(biāo)真的與技術(shù)無關(guān)嗎？其實(shí)并不然。

怎么落地為考核呢？我的思路是建立在兩個(gè)邏輯之上的：

1. 業(yè)務(wù)指標(biāo)的移動(dòng)平均值在一段時(shí)間里是一條趨勢向上或向下的曲線。平均范圍越長，曲線越平滑。

2. 技術(shù)在短期不能顯著提高業(yè)務(wù)指標(biāo)，但可以降低業(yè)務(wù)指標(biāo)。

基于這兩個(gè)邏輯在落地為考核的時(shí)候有兩種方案。

一種是長周期考核，比如每半年或者每年一次的 OKR 考核。這種考核直接用指標(biāo)在開始時(shí)和結(jié)束時(shí)的差值即可，大多數(shù)的偶發(fā)性事件直接被平滑掉了。

另一種是每個(gè)月都要進(jìn)行的短期考核。這種考核建議使用環(huán)比變化作為依據(jù)。比如比上個(gè)月提升了就獎(jiǎng)勵(lì)，降低了就懲罰，這樣從長期來看，偶發(fā)性事件帶來的影響也被平滑掉了。當(dāng)然這里的獎(jiǎng)勵(lì)和懲罰不一定是物質(zhì)形式的，也可以是精神形式。

可能有的人會(huì)覺得，這樣的考核如果在業(yè)務(wù)快速發(fā)展期，不是躺賺嗎？

是的沒錯(cuò)，只要技術(shù)能支撐快速發(fā)展的業(yè)務(wù)，不拖業(yè)務(wù)的后腿，我認(rèn)為就應(yīng)該獎(jiǎng)勵(lì)。至于是不是躺賺，關(guān)鍵還是看選擇的業(yè)務(wù)指標(biāo)以及如何制定具體的獎(jiǎng)懲尺度。

今天就聊這么多吧。

研發(fā)考核這事和研發(fā)工作一樣，沒有「Sliver Bullet」，我今天和大家聊的也只是我的一家之言，歡迎大家一起探討。

本質(zhì)上，我們也是在討論，如何更好地向非技術(shù)人員展示我們技術(shù)人工作成果的好壞。

好了，總結(jié)一下。

這篇呢，Z哥和你分享了我對(duì)研發(fā)考核這件事的看法。

首先，我認(rèn)為考核還是要考的，不考核肯定不行。研發(fā)工作性質(zhì)的三個(gè)特點(diǎn)導(dǎo)致考核指標(biāo)很難定。

1. 無法標(biāo)準(zhǔn)化

2. 工作透明度低

3. 工作時(shí)間的碎片化

所以，我的建議是找指標(biāo)管找指標(biāo)，考核管考核，兩件事分開看。

我們要盡可能多的收集研發(fā)過程和衡量結(jié)果的指標(biāo)，它們不一定用來考核，但可以用來及時(shí)發(fā)現(xiàn)團(tuán)隊(duì)中的潛在問題。

關(guān)于考核指標(biāo)還是建議使用業(yè)務(wù)相關(guān)的指標(biāo)，從中挑選有一定技術(shù)影響程度的。也分享了兩種落地方案，分別是長期用 OKR，短期用環(huán)比來考核。

希望對(duì)你有所啟發(fā)。拋磚引玉，歡迎在留言區(qū)分享你的觀點(diǎn)。

推薦閱讀：

• 別等了，全面「遠(yuǎn)程辦公」涼了
  

• 十個(gè)現(xiàn)象，識(shí)別程序員的“水份”
  

原創(chuàng)不易，如果你覺得這篇文章還不錯(cuò)，就「點(diǎn)贊」或者「在看」一下吧，鼓勵(lì)我的創(chuàng)作 ：）

也可以分享我的公眾號(hào)名片給有需要的朋友們。

如果你有關(guān)于軟件架構(gòu)、分布式系統(tǒng)、產(chǎn)品、運(yùn)營的困惑

可以試試點(diǎn)擊「閱讀原文」