研发考核难的本质是因为这三个特点
大家好，我是Z哥。我坦白，這篇是早就寫好的庫存文章，包括上周的那篇也是。
原因是最近跳槽了，到新公司忙得飛起，都沒時間寫文章。還好我之前未雨綢繆準備了幾篇提前寫好的文章作為余量～
我盡量能保持不斷更，如果實在頂不住就周五的時候給大家請假哈。
好了，回到這次聊的正題。
研發考核難是整個軟件開發領域眾所周知的問題，甚至可以說是跨世紀的難題了（上個世紀開始至今未被有效解決）。
近期我對這個問題有了一些新的思考，在這里和大家分享交流一下。
很多人覺得因為研發考核很難考，所以索性就不考了。這個就有點因噎廢食了。
首先我們要搞清楚，考核存在的意義是什么？
我的理解是：為了達成團隊的共同目標。為了更好的管理團隊、驅動團隊力往一處使。
但是管理大師德魯克又說過：
你如果無法度量它，就無法管理它。
德魯克
這句話既然能被各個時代的管理者所追捧，存在了幾十年，自然有它的道理。
所以，不管我們是不是為了考核，都得找到度量的方式方法。
有些團隊的確找到了不少度量指標，但是大多偏向技術層面，包括我們團隊之前也是如此。
這些指標一旦在具體實施之后往往發現效果甚至不如沒有考核的時候。這個背后的原因也有很多文章提到過，就是那些指標不適合考核。
也有一些人經歷了上面這個階段后覺得研發的考核不好做，不好量化。實則是因為找不到那種直擊要害的關鍵指標。
從這個問題的本質上來說，大家之所以覺得研發考核難本質是由于研發工作的三個特點導致的。
01? 無法標準化
這里的無法標準化并不只是難以度量，而是說同樣完成一個任務，不同的人會有不同的做法，最終的結果也可能會差別很大。
比如，同一個任務，有的人做了 5 天，有的人做了 10 天；有的人喜歡花很多時間在前期的設計階段，有的人則會花更多時間在后期的自測上。但是你也不能說一定是誰的方式更好。
02? 工作透明度低
實現同樣一個功能，如果有合理的代碼封裝，可能只要 100 行代碼。但是如果不花時間去構思封裝，那么可能是 500 行，甚至是 1000 行。
此時，如果沒有第三者進行 codereview 的話，甚至可能會覺得寫 1000 行代碼的人產出更大。
03? 工作時間的碎片化
不得不說，大多數人的工作時間其實大部分時候很難完全由自己掌控，一會有人找你問個事，一會需要參加一個會，一會又來個電話接一下。
這些被動的意外之事都會使得做度量這件事變得困難，甚至還會將原來的計劃打亂，導致某些考核指標出現失真。
Z哥覺得研發考核指標怎么定這件事應該分為兩個問題去看。
能夠度量的指標有哪些？
怎么考核？
這兩個問題之間其實沒有必然聯系，如果老想著一箭雙雕，一次解決兩個問題，就會陷入前面提到的困境中。
我認為大部分的指標是用來作為幫助決策的信息源，而用于考核的指標不一定要多，要有業務價值。具體我來展開說說。
/01? 能夠度量的指標有哪些/
相信有不少指標已經馬上在你的腦海中跳出來了：
代碼行數
工時
bug 數
……
很多講考核的文章都會對這些指標嗤之以鼻，因為這些指標不適合用來考核，這是針對流水線工作性質的考核產物。這點不否認。
但是也不能否認，這些簡單的指標中也蘊含著有價值的信息。
因此在我的理念里，認為不應該主動放棄任何能被度量的指標。正如前面所說，研發工作本身就具有無法標準化、工作透明度低、工作時間的碎片化的特點。我們好不容易找到一些指標能夠幫助我們更清楚的認識我們的工作做得到底如何，為什么不要呢？
不適合考核不等于我們可以忽略他們。這也是我認為要將這事分為「能夠度量的指標有哪些？」和「怎么考核？」的原因。
除了這些大家都知道的指標，還有很多指標可以被度量。它們主要分為兩個維度：過程指標和結果指標。
常見的過程指標有：需求響應周期、發布前置時間、交付吞吐量、線上問題平均解決時長等；結果指標有：日均新增 bug 數，日均 bug 庫存數，線上問題數量等。
如果你所在的團隊對工程效率比較重視，相信還有不少指標可以被度量出來。
這些指標有什么用呢，我們需要每天觀察他們的變化，便于及時發現團隊里正在發生的變化是否符合預期。比如，
最近并沒有太多并行開發的版本，為什么平均交付時間反而變長了？是不是不夠敏捷？
比如最近生產環境的 bug 數明顯變多了，是不是質量團隊出了什么狀況？
……
/02 ?怎么考核？/
用上面列出的這些指標來考核嗎？自然不是。
Z哥認為考核還是得從業務下手，要想辦法找到與技術有一定關系的業務指標，比如，DAU、用戶平均停留時長等等。
可能很多人第一眼會覺得說，這些指標有很大比例是由業務決定的，技術在其中起不了什么作用。
其實并不然，你想象一下。如果我們的拉新用戶承接頁的穩定性不好，或者核心業務鏈路經常出錯，這對 DAU 和用戶平均停留時長必然會造成不好的影響。所以，業務指標真的與技術無關嗎？其實并不然。
怎么落地為考核呢？我的思路是建立在兩個邏輯之上的：
業務指標的移動平均值在一段時間里是一條趨勢向上或向下的曲線。平均范圍越長，曲線越平滑。
技術在短期不能顯著提高業務指標，但可以降低業務指標。
基于這兩個邏輯在落地為考核的時候有兩種方案。
一種是長周期考核，比如每半年或者每年一次的 OKR 考核。這種考核直接用指標在開始時和結束時的差值即可，大多數的偶發性事件直接被平滑掉了。
另一種是每個月都要進行的短期考核。這種考核建議使用環比變化作為依據。比如比上個月提升了就獎勵，降低了就懲罰，這樣從長期來看，偶發性事件帶來的影響也被平滑掉了。當然這里的獎勵和懲罰不一定是物質形式的，也可以是精神形式。
可能有的人會覺得，這樣的考核如果在業務快速發展期，不是躺賺嗎？
是的沒錯，只要技術能支撐快速發展的業務，不拖業務的后腿，我認為就應該獎勵。至于是不是躺賺，關鍵還是看選擇的業務指標以及如何制定具體的獎懲尺度。
今天就聊這么多吧。
研發考核這事和研發工作一樣，沒有「Sliver Bullet」，我今天和大家聊的也只是我的一家之言，歡迎大家一起探討。
本質上，我們也是在討論，如何更好地向非技術人員展示我們技術人工作成果的好壞。
好了，總結一下。
這篇呢，Z哥和你分享了我對研發考核這件事的看法。
首先，我認為考核還是要考的，不考核肯定不行。研發工作性質的三個特點導致考核指標很難定。
無法標準化
工作透明度低
工作時間的碎片化
所以，我的建議是找指標管找指標，考核管考核，兩件事分開看。
我們要盡可能多的收集研發過程和衡量結果的指標，它們不一定用來考核，但可以用來及時發現團隊中的潛在問題。
關于考核指標還是建議使用業務相關的指標，從中挑選有一定技術影響程度的。也分享了兩種落地方案，分別是長期用 OKR，短期用環比來考核。
希望對你有所啟發。拋磚引玉，歡迎在留言區分享你的觀點。
總結
以上是生活随笔為你收集整理的研发考核难的本质是因为这三个特点的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 单体应用 适合采用 dapr 构建吗？
- 下一篇： 实现一个基于 IConfiguratio