工程師績效不是看程式碼產量!Quip工程師這樣看進階指標設定

2016.07.05 by
張庭瑜
一名工程師主管為了激勵他的團隊找出和修復更多 bug,因此制定一個計畫:每發現和修復一個 bug,就可獲得 20 元獎勵金。不過獎勵計...

一名工程師主管為了激勵他的團隊找出和修復更多 bug,因此制定一個計畫:每發現和修復一個 bug,就可獲得 20 元獎勵金。不過獎勵計畫開始實行後,工程師開始刻意在程式碼埋下 bug,以獲得更多獎勵金。這項立意良善的計畫很快便終止。

你發現了嗎?錯誤的衡量指標不僅影響工作方式,也影響工作目標。曾任職於 Google 和 Quora 等公司、現任 Quip 軟體工程師的 Edmond Lau,同時也是《The Effective Engineer》作者,近日在部落格分享如何訂出衡量生產力的標準,他認為應隨時反問自己:這個衡量方法是否能激勵到我想要做到的事?

正確的衡量標準會依目標的不同而改變

衡量指標應隨著目標不同而改變。Lau 舉例,若以程式碼行數作為衡量指標,大家一定覺得很荒謬,不過以數量作為衡量標準在某些地方仍是有意義的。例如,在剛開始學新東西的階段,不論是寫程式、畫畫、表演或駕駛等,寫了幾行程式碼、畫了幾張草稿、排演了幾幕,以及在路上開車幾小時,都是重要的衡量指標,因為這些是發展新技能必經的練習過程。然而一旦技能發展到一定程度,專注產出數量的衡量指標便不再那麼適用,而是應持續精進技能,讓自己離開舒適圈。

舉例來說,Lau 在著手開始寫《The Effective Engineer》初稿時,品質並不是首要考慮重點,他更在乎盡快完成所有初稿,以看出所有內容如何拼湊在一起。具體做法為,以每天寫 1000 字定為衡量生產力的標準,可讓自己專注在產出新內容,而不是花很多時間重寫或修訂過去的產出。

圖說明
(圖片來源:unsplash.com

找到目標,並以此找到衡量指標

作為一名工程師,每個階段的目標都不一樣,衡量指標也隨之改變,Lau 列出工程師常用的工作目標與對應的衡量指標:

  • 學習新架構或程式語言:對學習而言,最簡單的衡量指標就是每天練習時間應達到多少小時。
  • 減少工作時分心:追蹤專注、有生產力的工作時數多久。可先以「番茄工作法」開始,意即每 25 分鐘的工作搭配 5 分鐘休息時間的工作方式,更能激勵自己全心投入工作,並避免被 Facebook、接收 Email 或瀏覽網頁打斷工作。
  • 加快關鍵子系統效能:追蹤改善多少平均值、95th 百分位的延遲,或是任何遇到的瓶頸,都是很重要的衡量方式。若很明確知道哪個功能該優化,應該做得更深入。例如,Instagram 便鎖定優化「每位活躍用戶在尖峰時間可執行的 CPU 指令數量」,取代過去「平均每個 request 花費的 CPU time」的衡量指標。
  • 改善搜尋結果品質:可追蹤改善多少點擊率,或是參考Google追蹤「長時間點擊率(long click-through rates)」,意即在搜尋結果頁面點下連結後,沒有立刻離開該頁面的點擊才算數。
  • 提升使用者成長和涉入程度(engagement):根據不同業務對每間公司的重要性不同而改變,你的衡量指標可能會是註冊率、付款轉換率、每周活躍用戶成長率、每周的留存率等。
  • 提升伺服器可靠性:假設你已經有很好的監測系統,可以用每周緊急通報系統出錯的次數作為衡量指標。此外,也可以進一步根據你在意的面向,調整權重。例如,提升伺服器可靠性,是為了最小化客戶中斷次數,還是避免員工在工作時間以外受到干擾?可以將在員工上班時間,以及伺服器非尖峰時間的系統緊急通報次數採不同權重計算。

Lau 強調,想知道應該以什麼當衡量指標,從界定你想要達成的目標開始。並問自己:「如果我只能選一個衡量指標有計畫的隨時間進行,哪一個才能更佳、更持續性地引領我到達目標?」這個答案就是你該採用的生產力衡量指標,而且可以影響指標最多的工作,就是你應該專注的最高優先順序工作項目。

代表圖來源:startupstockphotos.com
資料來源:The Effective Engineer

延伸閱讀:
會寫程式還不夠,矽谷傑出軟體工程師都有的5種能力
當個有戰力的工程師!先搞清楚修Bug和理解使用者其實是同一件事

每日精選科技圈重要消息