由於程式設計師的工作性質，使他們的工作時常很難量化。對於技術管理者來說，想要做好量化，應該從哪幾個方面出發呢？本文為 2019 年 3 月 23 日馬蜂窩技術副總裁張矗在由 TGO 鯤鵬會主辦的 GTLC 北京站發表的演講整理，希望可以通過文字和各位技術管理者一起思考。
口述 | 張矗
整理 | Rainie Liu
張矗，馬蜂窩技術副總裁，北京理工大學工學碩士，TGO 鯤鵬會會員，擁有 10 多年的網際網路技術和管理經驗。2000 年加入新浪網；2007 年作為聯合創始人蔘與建立開心網；2012 年加入馬蜂窩旅遊網，擔任技術副總裁。
大家好，我是來自馬蜂窩的張矗。在座的很多朋友可能都用過我的一些 App，2012 年我來到馬蜂窩進行二次創業，我的整個工作經歷都是集中在網際網路行業，今天分享內容更多的適合在網際網路領域，其他領域的同學可以參考一下。
無法衡量就無法管理
無法衡量就無法管理，這句話是管理學大師——彼得·德魯克說的。其實後面還有一句話叫，無法管理就無法改進它。今天分享的主題主要是關於技術研發人員在績效考核上如何進行衡量、量化。
我的分享主要分為三個部分，第一部分，對技術研發人員績效考核這個事情的難度在哪裡；第二部分，在做績效考核這個事情上要去做量化的績效考核，以及它的誤區；第三部分，是在馬蜂窩實踐中所總結出來的一些思考。
績效考核量化，難於上青天
由於程式設計師工作性質，很多時候工作無法進行量化，那麼對於技術管理者來說，做好績效考核量化就好比上青天。那麼想要做好量化，應該從哪幾個方面出發呢？
1、創造性工作
首先，我們需要意識到自己所做的工作本質上是創造性工作、腦力勞動。腦力勞動是需要思考的，是需要靈感的，可是你的個人情緒、工作節奏、團隊狀況都會影響整個團隊的產出，你也不知道靈感什麼時候能夠迸發，創造性的工作在網際網路領域其實是需要很多的試錯，試錯的成本也是很難預估的。
2、黑盒
技術研發的很多工作成果其實是一個黑盒。我們都知道用一些功能性的黑盒進行測試，但你並不知道黑盒後面真正發生了什麼。同樣是一個列表頁，過去可能是排序，但今天可能變成推薦演算法，工作量是不可同日而語的。
如果我們想用白盒測試，那麼將會給成本帶來很大的提升。有一個經常發生的現象，如果你是用外行考核內行的時候，黑盒效應會更加明顯。
3、經驗量化
經驗對網際網路行業中的工程師來說，作用是非常巨大的。舉個例子，就像外科手術，有經驗的大夫一刀下去，有問題的組織會給你清理得乾乾淨淨，並且術後對於病人的生活質量是有很大的保障和提升；沒有經驗的大夫可能會下刀更多，也沒有清理乾淨，如果要讓病人接受這樣的手術還不如不動手術，這個類比放在程式碼重構是特別典型的事情。經驗這個事情也很複雜，因為它很可能是區域性的，你只是對某個領域有經驗而已，並且它也是不穩定的，可能這一刀還可以，下一刀未必行。
4、時間管理
時間管理對於工程師的工作產能來說是非常重要的。很多工程師和設計師每天都會因為各種會議、面試，以及需求不斷地被打擾，大家都身處其中，誰催得著急一些，那我就優先做誰的工作，只有到夜深人靜的時候才能做一些自己真正想做的事情。那麼不擅長於掌握時間管理的工程師經常會陷入應激式工作的方法，而不是統籌式工作的方法。這種多工的工作，一件任務沒有完成，另外一件任務接踵而來，會給心裡形成一個巨大的壓力，本質上是會造成崩潰的，並陷入絕望的狀態，工程師應該都很清楚多工系統切換起來效率影響也是巨大的。
5、協作
工程師很多時候也不是獨自孤立地在工作，他需要與產品、設計師、測試、商務人員、銷售共同完成網際網路作品的呈現。在這個過程中，需要彼此間具有同理心，互相去理解對方，幫助對方彌補思維的缺陷，最終完成這件事情。在這個過程中你很難去比較誰的貢獻更大，誰的工作更多，而且這裡面還有不少很重要的崗位，以及它們還具有年齡的差異。
現在我們看各種釋出會時，會發現不少 90 後的產品經理已經上位了。相信今天來到本次 GTLC 全球技術領導力峰會北京站的參會者大多還是 80 後、85 後的技術管理者，可能有些在場同學已經開始著急如何與 90 後產品經理一塊 PK 了，這件事情已經發生了，如果你一味的憂愁可能會讓事情變得更加複雜。
技術工作量化的誤區有哪些？
1、程式碼行數
大部分朋友都知道在技術工作量化上第一個誤區是程式碼行數。當前我們常常對工程師提出要求——把程式碼寫得精簡易讀，但有些“經驗豐富”的工程師仍然很容易地在程式碼里加入很多沒用的東西，或者是用工具實現程式碼行數的增加，以此來體現“彰顯”工作量。
2、BUG 數量
大家會覺得考察 BUG 數量也不是一個好的方法，雖然在實踐過程中會不斷地提出來用 BUG 數量進行考核，但當你真正用 BUG 數量考核時，通常會形成很不好的引導。因為很可能會出現，工作越多，BUG 數量就會越多的情況，從長期來看這樣的引導是無法激勵大家爆發出更大的潛力。
3、專案完成時間
專案完成時間的考核方法具有一定的迷惑性。我們大多都喜歡把專案提前完成的團隊，但專案完成時間通常是由專案執行者來決定的。如果用專案完成時間來考核大家，我們一定會使用保守估計時間的方式，為自己留一段時間緩衝。
4、潛力>產出
2018 年我加入 TGO 鯤鵬會時，在一次分享中，搜狐的高琦老師（高琦，搜狐高階技術經理 & TGO 鯤鵬會會員）講解燃盡圖時，從敏捷的角度看，燃盡圖是一條傾向於直線的角度，如果我們傾向於把專案的預估時間和實際預估時間趨於此，用它們作為考核也會很有問題。
總結來看，我們希望考核是激發大家更大的工作潛力，而不是引導大家迴歸工作或者是逃避問題。
關於這些年我在馬蜂窩技術工作的績效考核思考
明白了難度和誤區，那麼這些年裡我又產生哪些思考呢？
1、關注目標，而不是任務
我曾經工作的第一家公司也實施過 KPI，但是我覺得是非常失敗的。因為它像一場運動，我完全預料不到結果，就這麼過去了。
而在上一家公司，我們用到了 O（目的）G（目標）S（策略）M（衡量和檢測）的方法，這個方法實施得相當不錯，其中最核心的部分是 O 和 G 的制定過程，再到 S 和 M 的拆解，但 OGSM 的方法在網際網路圈沒有 KPI 和 OKR 這麼流行，因此大家瞭解得也不多。
最近一兩年，馬蜂窩事業部也開始嘗試使用 OKR 的方式進行績效考核。因為 OKR 大家都比較瞭解，並且 OKR 的概念已經存在了很長時間，現在又不斷地被提出來，去年起百度也是全面開始轉向 OKR。
由此，我想到了如何量化我們的績效指標上相當重要、熟悉的一個話語，關注目標，而不是任務。
我們經常說我釋出了什麼，啟動了什麼，建立了什麼，上線了什麼，這些都是任務而不是目標。目標應該是我將某某指標從 X 轉變成了 Y，只有這樣才是目標，目標應該是可量化的。
舉一個內部的例子給大家分享一下，在馬蜂窩內部有很多的員工使用的系統，如 OA 系統、企業郵箱、程式碼管理，以及各個事業部他們自己運營的系統，這些對於員工來說是相當複雜的，需要去記住每個系統的密碼，以及我需要在哪一處登入。為了給大家提供一個更加安全、便捷的登入方式，我們計劃去打造統一登入的 SCS 系統，並且把所有第三方的系統和我們自己研發的系統的登入都要切換到統一的登入系統中。
一開始，我們團隊認為只要完成系統研發任務就完成了，可我們的目標並不是去研發一套 SCS 系統，而是要將沒有使用 SCS 的系統從 50 個減少為 3 個，以此達到安全和便捷的目的，但是我們一開始並沒有注意從目標出發。在完成研發任務的過程中，團隊也解決了很多的問題，包括一開始沒有想到的場景，以及思維轉化的過程。漸漸地，研發統一登入的 SCS 系統變得不是重點了，而變成我們要去切換某個系統，推進第三方研發，這樣的轉化使得我們的工作成果變得更有實際意義。
馬蜂窩對於團隊的要求是，不光要求你會寫程式碼，還需要具備溝通協調的能力，以及規範的能力。我們可以看看業務團隊，或者支援業務團隊的研發團隊，他們的指標需要去確定，業務團隊的目標就是整個團隊的目標，業務團隊的目標就應該成為支撐這個業務團隊和研發團隊的主要目標。
有一種聲音會說業務團隊的目標完成好或者不好，有些時候跟研發一點關係都沒有，這會讓我們形成階段性的短視現象，我們更應該從長期來看它是否有更公平和有效的方法。但短期誤判也是倒逼我們審視業務團隊和目標很重要的方法，因為團隊是需要長期投資才能看到價值。比如說管理團隊，我們也需要幫助他們找到一些可量化的目標，這個可量化的目標包括系統的穩定性標準、效能維持標準，員工滿意度標準等。
2、平衡
主要的方法確定了我們也需要加入一些平衡的因素來解決我們實際操作中的困難，那麼我們該如何平衡呢？
只關注業務的目標確實會形成短期的現象，如團隊貢獻、考勤，但這兩個目標都具備一個特點，它是一種階段性的狀態，它會階段性的好或者是不好。
如團隊貢獻，你這個月在團隊內部做了一個分享，你可能就拿到團隊貢獻；你幫助這個團隊組織了一次團建，你也具備這樣的團隊貢獻。再比如，考勤並不是讓大家給自己的兄弟們上下班打卡，它可以帶著主觀的因素，你可以觀察誰經常遲到早退，這是你能感受到的主觀印象，你也會感受到有些人天天為了專案加班到很晚。這個過程你還需要識別有一些同學他是天天加班的，是為了混一個晚餐或者是叫車費，這個鑑別還是比較容易的。
找平衡的過程也是把我們管理者的主觀判斷落實在客觀標準的過程，團隊中我們都會喜歡在群裡積極回答別人的問題，樂於給大家做分享的同學，他們對團隊的氛圍貢獻是非常有幫助的，因此更應該在團隊貢獻上拿到更多的分數。
有的同學會說把個人成長、學習能力、解決問題的能力這樣的因素納入到績效考核的指標上來，但是我認為這是不妥的。個人成長這個事情很難衡量，這個月我看了一本書叫《成長》，在書中作者提到，他將能力範疇指標，與成績晉升和基礎薪資掛鉤會顯得更有效一些。
3、層級區分
當你跟團隊成員設計目標的時候，一定要關注他當前所在的層級。
初級工程師，按時完成工作、寫好程式碼、完成測試，以及做好文件的編撰就是他的目標，那你要從這個方向上想好怎麼給他量化；
稍微有一些年限的工程師，需要做好架構設計、規避專案的風險，那麼你可能需要從這些方面給他做好設計；
更資深的工程師或者是技術經理位，他需要做到判斷需求的輕重緩急，做好專案的安排，以及專案上線後的跟蹤和整個狀態的反饋。
總之，對於越是高階的人員，他的績效考核越是要跟業務 KPI 關聯起來，當給他設計目標的時，一定要想他的目標對他的上級、部門、公司、使用者和社會的意義和價值所在。
現在我們能看見有很多工程師，他的專業技能已經達到了高階的水平，但是在理解上級目標，確定自己的目標或者是行動還沒跟上。“巨嬰”就是指，需要哄著才能幹活的程式設計師。比如我們上線一個新的功能，大家在上線前也都很努力，為了完成任務，加班熬夜終於在深夜把這個專案推上線，但上線後很多工程師沒有對新的資料表現和使用者行為做跟蹤。現在大家的分工越來越細，很多這樣的活都是產品經理或者是公司幫助你，那麼這樣的工程師必然淪為螺絲釘。
我們只有不斷拓寬自己的眼界，提升自己的視野，才能使我們不斷從初級向高階進化。
4、評估週期
最後一點思考就是對於評估週期的思考。我們都很希望上級能告訴我，未來一個季度該做些什麼工作。舉個例子，比如某個團隊會支援很多客戶的工作，但是他只知道我當前有這樣的事，這個月差不多能幹完，接下來兩個月該幹什麼還不太確定。這時，我給大家的建議是不妨把考核的週期縮短，按月來考核。考核的內容包括這個月實際做的工作，實際支援的客戶的成果等。或者，你也可以對下個月的挖掘作為考核指標，不超過三個月進行一次考核。在網際網路領域裡，三個月一次考核我認為也是上限，當你對未來不是那麼確定時，不妨縮短考核週期。
總體來看，想要通過業務量化研發人員的工作，我們首先是完成思維轉化，這樣的轉化對那些具有綜合能力的研發人員，或綜合能力比較強的研發人員更有利的；對於管理者來說，你要思考如何用其他的方法來確保搞鑽研的科學家們不會被虧待，以此確保你的長期利益和短期利益的平衡，最終才能達到長期利益的最大化。
最後，我們再回到關注目標這個詞，如果大家在關注目標，實踐關注目標這個事情碰到一些困難時，我也給大家提一個建議，你可以多想想老闆都在想什麼，謝謝大家。
（本文轉載自公眾微訊號：TGO）