Contents
本部落格原文One Key Question to Ask When Measuring Your Own Productivity
The Effective Engineer作者Edmond Lau授權翻譯
Scott Adams在他的呆伯特法則( The Dilbert Principle )分享了他從一位他的漫畫讀者那兒聽到一則關於如何度量生產力故事：
有一位工程經理想要激勵他的團隊找到並解決軟體的問題， 所以他發起了一個獎勵計畫來鼓勵高績效的人。 為了鼓勵品保團隊找到問題， 只要發現一個問題就有 $20 的 獎勵。 為了鼓勵工程師， 每解決一個問題也發給 $20 的獎賞。
接下來發生什麼事不難想像。 工程師開始故意製作一些問題讓測試人員找到， 然後他們再來解決。 有一位工程師甚至開起臭蟲( Bug )地下市集，還因此一個星期內就賺進 $1700。 這原本出於好意的計畫在這些事發生後很快就關掉了。
這一個有趣的小故事，點明了一個很重要的問題： 如何度量你的生產力將決定你將怎麼執行 。 每當你要去衡量你的生產力時， 考慮一個關鍵問題： “什麼樣的度量可以引導我往想去的方向前進？”
更進一步來說
你的目標決定什麼是正確的度量
大多數的工程師會嘲笑以程式碼行數做為產出度量的想法。 這是個荒誕的度量標準， 不是嗎？ 像這種忽視品質和程式碼影響力的度量怎麼會合理呢？
但是有時後在有些場合這種說法算是合理 –純粹度量產出的原始量也有價值。
當你剛開始學新的事物 — 不管是程式設計、畫畫、演戲、開車或其它–你寫幾行程式、畫了幾幅畫 、做了幾場表演、上路多少時數， 都是很重要的度量。 這些將可追蹤你是否做足夠的練習，擁有這方面的技能。 這就是為什麼養成習慣， 如一年跳 365 天的舞( dancing 365 days a year ) 或是 180 天建立180 個網站( building 180 websites in 180 days )對於剛開始學習的人這麼有效。 同樣的度量在技術達到某個水準後就沒有那麼舉足輕重了。 在此之後， 比較有用的是刻意去練習那些跳出舒適圈的技術， 這時單看原始的產出量，就不再是對改善有用的指標。
類似的， 當品質不是主要的重點， 數量為主的度量就有用了。 例如， 我在寫 The Effective Engineer 的初稿時， 品質對於從初稿到能看到是否所有的片段合不合得來的接近完成階段前都還不重要。 那時我以是否新增 1000 個字為目標來衡量每日的生產力。 我專心產出新的素材而不是花時間來重寫或修改我之前寫好的部分 — 許多作者傾向這麼做。
所以在第一眼你覺得這度量標準很荒誕， 後來你也有可能認為它可以擔任重要的角色。 一個度量是否合理取決於你的目標–且當你的目標改變了， 以前用的度量就有可能毫無用處。 那麼我們如何記取這教訓並應用到工程上的生產力呢？
釐清你的目標，然後回推你要用的度量標準
身為一位工程師， 問問你的目標–> 然後什麼是對的度量標準 –> 這些標準將因時而變。 你的目標有可能是：
- 學習新的架構或是程式設計語言。 以學習為目的， 採用簡單的度量標準來追蹤。 如每天應該最少花多少時間， 才足夠達成目標。
- 工作時避免分心。 運用蕃茄鐘來追蹤專注有生產力的工作時數。 戒除 Facebook、Twitter、email 或逛網站的習性會是你好的開始。
- 加速重要的次系統效能。 追蹤你要花多大的努力來增加平均產值、改進完成百分之 95 的系統反應時間或突破任何你正遇到的瓶頸並且確認這個瓶頸對你的影響很重大。 甚至你很清楚你想最佳化哪一個部分， 你可以更深入去最佳化， 例如 Instagram 針對每位尖峰時間活動的使用者做 CPU 指令的最佳化。
- 提升搜尋結果的品質 。你想要追蹤你的讀者點入率( CTR， click-through rate )能創造多深的印記， 或許從 Google 學習追蹤長的讀者點入率( long click-trough rate ) –從這些連結點擊進入後流連一段時間且沒有跳出。
- 增加使用者成長與互動。 要看對於通路的那一部份對你目前的生意最重要， 你將度量哪種有最大的影響力， 是註冊量？ 轉換訂單率？ 每星期活動使用者的成長率？ 每星期跟上一週比較的使用者保留率？還是其他通路的指標？
- 提升伺服器的可靠度。 如果你已經有很好的監控，可能你要度量每星期頁面調度的意外警報。 此關係到你是否想要最小化客戶遇到的系統崩潰，或是在你的團隊工作時間外面臨的系統崩潰問題。 你可能會放比較多的權重警覺在工作時間或非尖峰時間有可能出嚴重問題的任何意外警報。
請注意這些度量標準對你的影響會因領域而不同。而且對於各種目標， 可考慮的度量標準也很多， 並且都有其相關的激勵因子。
舉例來說， 如果你致力於應用程式的效能並專注於改善平均系統反應時間( latency )，通常你會做系統級的最佳化， 此幫助減少整體的 CPU、記憶體或頻寬的花費。 另一方面， 如果你專注於完成 95% 的反應時間( 95th percentile latency )， 大多時候你會專注於解決最差效能的問題案例 。 這些事件一般對於你最常用的使用者有比較大的影響。 這些使用者做最多的查詢、載入最多的頁面、跟隨最多的人或產生最多的資訊， 所以在運算上的處理也最費工。
要想清楚應該度量什麼， 從釐清你想達到的目標開始。 然後問自己“是否我可以選擇一項， 就只這一項， 與時並進地做系統性改善？ 怎樣才能有最大且持續發展地影響力， 往目標前進？”
你的回答將是你應該追蹤的生產力度量標準。 這些最能有效提升這度量的工作，將是你應該致力的高槓桿活動。
你可能會有興趣
- 歡迎參加The Effective Engineer – Team Package 團購 – 這是The Effective Engineer 作者Edmond 根據他的工作經驗與訪談多位資深矽谷工程師所寫的一本書，Team Package 比單買電子書多了兩份作者整理的檢核文件與他訪談的視訊，Team Package在作者網頁只開放給在同一家公司上班同事一起購買，Soft & Share 特地與 Edmond 聯繫，取得了可以使用社群團購的方式購買Team Package。
- Exercises for programmers – 學習新的程式設計語言要做那些刻意的練習？要如何度量你真的懂一門新的程式設計語言，這本書設計了 57 道挑戰，是一個不錯的度量方法。
喜歡我們的分享嗎？歡迎透過以下的社群分享按鈕分享給你的朋友吧！
發表迴響