年底了，各企業年度績效都做完了，未來還能撐得下去的企業都開始發年終獎了。
前些天，騰訊發年度終獎的消息爆屏了。先是騰訊雲的陽光普照獎，人手一台 iPhone 11 Pro，總獎金超過三千萬。
而後據稱微信支付團隊拿到了騰訊 2019 年的公司創始人獎，獎勵微信支付團隊 2 億，按照一千人算，一人 20 萬。這 2 億還不算是年終獎，有消息稱微信支付團隊的年終獎都是 10 個月工資起算。
（這是一張老闆們不想看到的截圖）
網際網路企業的年終獎
網際網路頭部企業錢多，年終獎往往豐厚得讓人秒變檸檬精。
阿里今年在香港再次上市，不知道獎金是否會變多，據阿里員工反映，他們還在走績效流程。按照慣例，會在 4 月份發放年終獎。普通程式設計師一般可拿到 4-9 個月的獎金，那麼稅前至少是 10-25 萬。
今年是百度成立 20 年，但主打的 AI 布局也很需要現金流的支撐，目前還沒有拿多少年終獎的確切消息。百度在 2019 年改為全年 15 薪，脈脈上有人反映今年拿了 4 個月的年終獎，按照百度工資計算，這個數比起其他大廠略少。
華為的年終獎最豐厚，據華為內部人說，華為人的收入三分之一靠工資，三分之一靠股票，三分之一靠年終獎。其中股票和年終獎，各級領導的話語權比較大。一般員工年終獎都能拿到 2、30 萬。
不過華為雖然獎金多，但是個體差別也很大。這位內部人士舉例：「比如前些年 18 級左右的員工，如果績效打 A 會給 60 萬；如果績效打 B 就只有一半，30 萬，相差會有小几十萬；績效拿 C 的話，一年就白幹了「。真真正正的用「薪」激勵啊。
以低績效為名的「裁員」
除了根據績效來發年終獎，還有企業根據績效結果來「裁員」。我們看到有一則求助：
某 BAT 頭部企業的老員工了，今天跟 HR 聊了，HR 總體意思是：你的績效不是很符合預期，這個是你個人能力有問題，你必須相信這一點。你抓緊時間找工作吧，我們可以推薦獵頭，我們沒有裁員，不會有賠償。好慌，求助。
被離職不賠償，這可以解讀為以績效為名被 PUA 了嗎？
BAT 和華為等幾家公司的績效管理都有個特點，就是都有 10% 左右的最低檔績效，還有的是要求強制分布。
對於中基層的員工，百度和騰訊都是按照五檔打分，都會有 10% 在最低檔。阿里的中基層員工整體打分按照 3-6-1 比例進行強制分布，即 30% 為「最好」，60% 為「一般」，10% 為「較差」。特別的是「價值觀」導向，價值觀占據 50% 。阿里 2019 年推出「新六脈神劍」，價值觀方面有 20 個選項，績效考核更為複雜。
華為的年終績效考評，分為 A、B+、B、C 幾個檔次，80% 的人都是 B 或 B+，C 檔最低，比例為 5%-10％且要求強制分布。他們的考核最為獨特，要根據投票來評定。比如 CT（績效評定團隊）投票，一般三票左右，直接主管占據一票，評定完了後交由 AT（行政管理團隊）覆核。
雖然在很多企業里，背最低檔不意味著「必須離職」，但是也免不了有企業會拿業績之外的東西去評定一些員工，進行「人員淘汰」。
當我看到某 HR 這樣說一名老員工——「他今天要不自己離開，未來一年也一定會因為績效問題被公司開了」的時候，我感到了在這 HR 考評背後一股非常強的暗流和不可見的力量讓她干出了這樣一件匪夷所思的事。
——技術人的「績效考核」 陳皓（左耳朵耗子）
程式設計師的績效怎麼考核
要麼」被裁員「要麼獎金相差小几十萬，這些都要靠年終績效來決定。那麼如何用績效來評斷程式設計師的工作呢？尤其是如果這家公司還是一家小公司，是不是就更難了？
在 InfoQ 的一次活動上，有人提出這樣的問題：」我目前帶 40 人的研發團隊，正在考慮考核問題，我分了三部分：第一部分仍然保持主觀打分，第二部分是量化的東西（Bug ），第三部分是額外的工作。請問這種量化是正確的嗎？「
在考評中加入可量化的指標來考核一名程式設計師確實是可以做到更公平公正，但是以 Bug 數來評定，這就有些」狗血「了吧。歷史上我們也是見證過好幾種「程式設計師工作成績」衡量指標的，比如 Bug、代碼行、提交次數等等，這些科學嗎？
以代碼行為例，代碼行大約有 70% 是噪音，比如空行、評論等。而且程式語言之間的差異也大，比如在 CSS 文件中編寫的一行代碼與在 Java 文件中編寫的一行代碼的工作量有很大的不同。因此，根據這個指標，「最有價值的開發人員」往往是添加最多 CSS、空白和第三方庫的人。
再說提交計數。從概念上講，提交只不過是開發人員工作過程中的一個「保存點」。程式設計師多久會保存一次他們的工作要看個人喜好。如果你使用「提交計數」作為指標來考核開發人員，那麼你實際上是鼓勵他們培養一種個人偏好，寫完一行代碼就提交。
偏差較小的衡量應該是將多個指標放到一起使用：
- 需求交付時間（Lead time)：從創意到交付軟體需要多長時間。
- 周期時間（cycle time）：對軟體系統進行更改並將該更改投入生產環境需要多長時間。
- 團隊速率（team velocity）：團隊通常在一個疊代（或叫做 Sprint）中，完成多少個「單位」數量的軟體。
- 缺陷開 / 閉率（Open/Close ）：在特定時間段內，報告和關閉的生產問題數量。總體趨勢比具體數字更重要。
- 應用的崩潰率（application crash rate）：應用程式崩潰的次數除以使用次數。
- …
留住老程式設計師
G 是一位老程式設計師，經歷過十幾次的績效評估。對於這些評估，他吐槽說很大一部分感覺結果並不公平，也數次因為不滿績效考核而選擇離職。評判經驗豐富的老程式設計師的工作，更要讓大家「心服口服」。
對軟體工作進行評估難免在某些部分會產生偏差。消除偏差的方式，可以利用覆核評議，用面談進行解決。面談之前雙方需要收集足夠多的信息，用來糾正「遺漏」或「片面」的評價：
- 1 v 1 會議記錄。
- 程式設計師在參與的項目中負責了哪些功能，難度如何？
- 產生的輸出：代碼，文檔，電子郵件。
- 收到的反饋：同行反饋，通過電子郵件或其他方式收到的感謝，以及能找到的其他反饋。
- 給出的反饋：代碼審查、計劃文檔審查、與他人的交互。
此外覆核評議也是保持兩者之間信任的關鍵。特別被打」低績效「或面臨「被離職」時候的面談，這一環節也最容易出事兒或「上新聞」，如果公司的」解釋權「使用不恰當的話。
「如果事情有可能變壞，它就遲早會變壞。」——墨菲定律
墨菲定律總是給我們無情的打擊。軟體研發的績效管理是如此之難，其副作用是如此之多，以至於很多時候為了處理問題我們已經耗費了大多數精力。怎麼在這種複雜環境中應用好績效管理，避免副作用，讓績效管理真正能激發員工激情，推動組織創新，成為公司績效的發動機？這是值得深思的問題。
結束語
作為程式設計師的你，今年的年終獎發了嗎？獎金高的話說出來讓大家酸一酸？
你有沒有因為什麼 Bug 使你的績效受到影響？
你認為你的年終績效結果，老闆打的分數合適嗎？不合適也歡迎在評論區留言吐槽！