由于程式員的作業性質，使他們的作業時常很難量化，對于技術管理者來說，想要做好量化，應該從哪幾個方面出發呢？本文為 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）
關注馬蜂窩技術公眾號，查看演講視頻 + PPT
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/214413.html
標籤：其他