馬蜂窩張矗：我對技術團隊績效考覈管理的幾點思考

因爲程序員的工做性質，使他們的工做時常很難量化。對於技術管理者來講，想要作好量化，應該從哪幾個方面出發呢？本文爲 2019 年 3 月 23 日馬蜂窩技術副總裁張矗在由 TGO 鯤鵬會主辦的 GTLC 北京站發表的演講整理，但願能夠經過文本和各位技術管理者一塊兒思考。

口述 | 張矗

整理 | Rainie Liu

張矗，馬蜂窩技術副總裁，北京理工大學工學碩士，TGO 鯤鵬會會員，擁有 10 多年的互聯網技術和管理經驗。2000 年加入新浪網；2007 年做爲聯合創始人蔘與建立開心網；2012 年加入馬蜂窩旅遊網，擔任技術副總裁。

你們好，我是來自馬蜂窩的張矗。在座的不少朋友可能都用過個人一些 App，2012 年我來到馬蜂窩進行二次創業，個人整個工做經歷都是集中在互聯網行業，今天分享內容更多的適合在互聯網領域，其餘領域的同窗能夠參考一下。

沒法衡量就沒法管理

沒法衡量就沒法管理，這句話是管理學大師——彼得·德魯克說的。其實後面還有一句話叫，沒法管理就沒法改進它。今天分享的主題主要是關於技術研發人員在績效考覈上如何進行衡量、量化。

個人分享主要分爲三個部分，第一部分，對技術研發人員績效考覈這個事情的難度在哪裏；第二部分，在作績效考覈這個事情上要去作量化的績效考覈，以及它的誤區；第三部分，是在馬蜂窩實踐中所總結出來的一些思考。

績效考覈量化，難於上青天

因爲程序員工做性質，不少時候工做沒法進行量化，那麼對於技術管理者來講，作好績效考覈量化就比如上青天。那麼想要作好量化，應該從哪幾個方面出發呢？

一、創造性工做

首先，咱們須要意識到本身所作的工做本質上是創造性工做、腦力勞動。腦力勞動是須要思考的，是須要靈感的，但是你的我的情緒、工做節奏、團隊情況都會影響整個團隊的產出，你也不知道靈感何時可以迸發，創造性的工做在互聯網領域實際上是須要不少的試錯，試錯的成本也是很難預估的。

二、黑盒

技術研發的不少工做成果實際上是一個黑盒。咱們都知道用一些功能性的黑盒進行測試，但你並不知道黑盒後面真正發生了什麼。一樣是一個列表頁，過去多是排序，但今天可能變成推薦算法，工做量是不可同日而語的。

若是咱們想用白盒測試，那麼將會給成本帶來很大的提高。有一個常常發生的現象，若是你是用外行考覈內行的時候，黑盒效應會更加明顯。

三、經驗量化

經驗對互聯網行業中的工程師來講，做用是很是巨大的。舉個例子，就像外科手術，有經驗的大夫一刀下去，有問題的組織會給你清理得乾乾淨淨，而且術後對於病人的生活質量是有很大的保障和提高；沒有經驗的大夫可能會下刀更多，也沒有清理乾淨，若是要讓病人接受這樣的手術還不如不動手術，這個類比放在代碼重構是特別典型的事情。經驗這個事情也很複雜，由於它極可能是局部的，你只是對某個領域有經驗而已，而且它也是不穩定的，可能這一刀還能夠，下一刀未必行。

四、時間管理

時間管理對於工程師的工做產能來講是很是重要的。不少工程師和設計師天天都會由於各類會議、面試，以及需求不斷地被打擾，你們都身處其中，誰催得着急一些，那我就優先作誰的工做，只有到夜深人靜的時候才能作一些本身真正想作的事情。那麼不擅長於掌握時間管理的工程師常常會陷入應激式工做的方法，而不是統籌式工做的方法。這種多任務的工做，一件任務沒有完成，另一件任務接踵而來，會給內心造成一個巨大的壓力，本質上是會形成崩潰的，並陷入絕望的狀態，工程師應該都很清楚多任務系統切換起來效率影響也是巨大的。

五、協做

工程師不少時候也不是獨自孤立地在工做，他須要與產品、設計師、測試、商務人員、銷售共同完成互聯網做品的呈現。在這個過程當中，須要彼此間具備同理心，互相去理解對方，幫助對方彌補思惟的缺陷，最終完成這件事情。在這個過程當中你很難去比較誰的貢獻更大，誰的工做更多，並且這裏面還有很多很重要的崗位，以及它們還具備年齡的差別。

如今咱們看各類發佈會時，會發現很多 90 後的產品經理已經上位了。相信今天來到本次 GTLC 全球技術領導力峯會北京站的參會者大多仍是 80 後、85 後的技術管理者，可能有些在場同窗已經開始着急如何與 90 後產品經理一塊 PK 了，這件事情已經發生了，若是你一味的憂愁可能會讓事情變得更加複雜。

技術工做量化的誤區有哪些？

一、代碼行數

大部分朋友都知道在技術工做量化上第一個誤區是代碼行數。當前咱們經常對工程師提出要求——把代碼寫得精簡易讀，但有些「經驗豐富」的工程師仍然很容易地在代碼里加入不少沒用的東西，或者是用工具實現代碼行數的增長，以此來體現「彰顯」工做量。

二、BUG 數量

你們會以爲考察 BUG 數量也不是一個好的方法，雖然在實踐過程當中會不斷地提出來用 BUG 數量進行考覈，但當你真正用 BUG 數量考覈時，一般會造成很很差的引導。由於極可能會出現，工做越多，BUG 數量就會越多的狀況，從長期來看這樣的引導是沒法激勵你們爆發出更大的潛力。

三、項目完成時間

項目完成時間的考覈方法具備必定的迷惑性。咱們大多都喜歡把項目提早完成的團隊，但項目完成時間一般是由項目執行者來決定的。若是用項目完成時間來考覈你們，咱們必定會使用保守估計時間的方式，爲本身留一段時間緩衝。

四、潛力>產出

2018 年我加入 TGO 鯤鵬會時，在一次分享中，搜狐的高琦老師（高琦，搜狐高級技術經理 & TGO 鯤鵬會會員）講解燃盡圖時，從敏捷的角度看，燃盡圖是一條傾向於直線的角度，若是咱們傾向於把項目的預估時間和實際預估時間趨於此，用它們做爲考覈也會頗有問題。

總結來看，咱們但願考覈是激發你們更大的工做潛力，而不是引導你們迴歸工做或者是逃避問題。

關於這些年我在馬蜂窩技術工做的績效考覈思考

明白了難度和誤區，那麼這些年裏我又產生哪些思考呢？

一、關注目標，而不是任務

我曾經工做的第一家公司也實施過 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 系統變得不是重點了，而變成咱們要去切換某個系統，推動第三方研發，這樣的轉化使得咱們的工做成果變得更有實際意義。

馬蜂窩對於團隊的要求是，不光要求你會寫代碼，還須要具有溝通協調的能力，以及規範的能力。咱們能夠看看業務團隊，或者支持業務團隊的研發團隊，他們的指標須要去肯定，業務團隊的目標就是整個團隊的目標，業務團隊的目標就應該成爲支撐這個業務團隊和研發團隊的主要目標。

有一種聲音會說業務團隊的目標完成好或者很差，有些時候跟研發一點關係都沒有，這會讓咱們造成階段性的短視現象，咱們更應該從長期來看它是否有更公平和有效的方法。但短時間誤判也是倒逼咱們審視業務團隊和目標很重要的方法，由於團隊是須要長期投資才能看到價值。好比說管理團隊，咱們也須要幫助他們找到一些可量化的目標，這個可量化的目標包括系統的穩定性標準、性能維持標準，員工滿意度標準等。

二、平衡

主要的方法肯定了咱們也須要加入一些平衡的因素來解決咱們實際操做中的困難，那麼咱們該如何平衡呢？

只關注業務的目標確實會造成短時間的現象，如團隊貢獻、考勤，但這兩個目標都具有一個特色，它是一種階段性的狀態，它會階段性的好或者是很差。

如團隊貢獻，你這個月在團隊內部作了一個分享，你可能就拿到團隊貢獻；你幫助這個團隊組織了一次團建，你也具有這樣的團隊貢獻。再好比，考勤並非讓你們給本身的兄弟們上下班打卡，它能夠帶着主觀的因素，你能夠觀察誰常常遲到早退，這是你能感覺到的主觀印象，你也會感覺到有些人每天爲了項目加班到很晚。這個過程你還須要識別有一些同窗他是每天加班的，是爲了混一個晚餐或者是打車費，這個鑑別仍是比較容易的。

找平衡的過程也是把咱們管理者的主觀判斷落實在客觀標準的過程，團隊中咱們都會喜歡在羣裏積極回答別人的問題，樂於給你們作分享的同窗，他們對團隊的氛圍貢獻是很是有幫助的，所以更應該在團隊貢獻上拿到更多的分數。

有的同窗會說把我的成長、學習能力、解決問題的能力這樣的因素歸入到績效考覈的指標上來，可是我認爲這是不妥的。我的成長這個事情很難衡量，這個月我看了一本書叫《成長》，在書中做者提到，他將能力範疇指標，與成績晉升和基礎薪資掛鉤會顯得更有效一些。

三、層級區分

當你跟團隊成員設計目標的時候，必定要關注他當前所在的層級。

初級工程師，按時完成工做、寫好代碼、完成測試，以及作好文檔的編撰就是他的目標，那你要從這個方向上想好怎麼給他量化；

稍微有一些年限的工程師，須要作好架構設計、規避項目的風險，那麼你可能須要從這些方面給他作好設計；

更資深的工程師或者是技術經理位，他須要作到判斷需求的輕重緩急，作好項目的安排，以及項目上線後的跟蹤和整個狀態的反饋。

總之，對於越是高級的人員，他的績效考覈越是要跟業務 KPI 關聯起來，當給他設計目標的時，必定要想他的目標對他的上級、部門、公司、用戶和社會的意義和價值所在。

如今咱們能看見有不少工程師，他的專業技能已經達到了高級的水平，可是在理解上級目標，肯定本身的目標或者是行動還沒跟上。「巨嬰」就是指，須要哄着才能幹活的程序員。好比咱們上線一個新的功能，你們在上線前也都很努力，爲了完成任務，加班熬夜終於在深夜把這個項目推上線，但上線後不少工程師沒有對新的數據表現和用戶行爲作跟蹤。如今你們的分工愈來愈細，不少這樣的活都是產品經理或者是公司幫助你，那麼這樣的工程師必然淪爲螺絲釘。

咱們只有不斷拓寬本身的眼界，提高本身的視野，才能使咱們不斷從初級向高級進化。

四、評估週期

最後一點思考就是對於評估週期的思考。咱們都很但願上級能告訴我，將來一個季度該作些什麼工做。舉個例子，好比某個團隊會支持不少客戶的工做，可是他只知道我當前有這樣的事，這個月差很少能幹完，接下來兩個月該幹什麼還不太肯定。這時，我給你們的建議是不妨把考覈的週期縮短，按月來考覈。考覈的內容包括這個月實際作的工做，實際支持的客戶的成果等。或者，你也能夠對下個月的挖掘做爲考覈指標，不超過三個月進行一次考覈。在互聯網領域裏，三個月一次考覈我認爲也是上限，當你對將來不是那麼肯定時，不妨縮短考覈週期。

整體來看，想要經過業務量化研發人員的工做，咱們首先是完成思惟轉化，這樣的轉化對那些具備綜合能力的研發人員，或綜合能力比較強的研發人員更有利的；對於管理者來講，你要思考如何用其餘的方法來確保搞鑽研的科學家們不會被虧待，以此確保你的長期利益和短時間利益的平衡，最終才能達到長期利益的最大化。

最後，咱們再回到關注目標這個詞，若是你們在關注目標，實踐關注目標這個事情碰到一些困難時，我也給你們提一個建議，你能夠多想一想老闆都在想什麼，謝謝你們。

（本文轉載自公衆微信號：TGO）

關注馬蜂窩技術公衆號，查看演講視頻 + PPT