TGO 鯤鵬會發起全新的雲上私享會，聚焦垂直話題，以 Zoom 視頻的方式，通過 3 小時的討論，結交朋友、分享經驗、收穫真知。2020 年 2 月 15 日 19:30-22:30，雲上私享會之《百人規模研發團隊的績效管理》順利舉行，本文為討論內容摘要。
本期雲上私享會討論了百人規模研發團隊的績效管理，共有 5 位 TGO 鯤鵬會會員參與。他們結合自己的管理經驗，交流了技術團隊的個人和小組分別如何管理績效、強制 271 分佈比例的利弊、公司層面如何定義技術團隊的”成功“等話題，希望幫助技術管理者及團隊成員更好地進行績效管理。
劉松是本話題的發起人，同時擔任討論的主持人。
話題一：技術團隊的個人績效如何考核？績效考核和晉升如何關聯？
TGO 北京會員、DataPipeLine CTO 陳肅：
剛才討論中有人提到，績效考核與晉升可以部分分開，我對這個觀點也是支持的。績效體現的應該是一些容易量化的部分，一些不易量化但是也比較重要的，例如團隊協調、對他人成長的幫助、對外技術影響力等，可以在晉升時候加以考慮或者用其它形式進行鼓勵。我們公司對技術人員的評價有兩種形式，包括常規的績效考核和季度之星的評選。季度之星有提名環節，會綜合考慮一個人的團隊貢獻度，並且獲得季度之星會對年底總體績效評價有積極影響。
我們的研發採用 Sprint 的方式進行組織管理。基於管理工具，從 Sprint 的執行情況中可以直接獲得量化考核所需的數字。但這有兩個前提：
其一就是 Leader 必須敦促大家按照要求更新進度信息，這需要投入前期的培訓成本。在初期養成使用習慣前，每個 Leader 每天例行的工作都要包含這一部分；
其二是任務工作量估算的合理性十分重要。完全客觀的估算是不存在的，但要做到相對合理，例如引入雙向的評估機制。在我們的評價體系裡，研發守時性和質量大概佔到權重的 60%。
TGO 深圳會員、開思時代合夥人劉松：
績效本質是為達成戰略服務的，要看結果。而研發的工作是很難量化的，它的維度很多，沒辦法用單獨的維度衡量。有可能 A 做出來的功能點比 B 差一點，但是他在協調團隊、增加凝聚力上發揮了更重要的價值。再比如有些同學，他可能在業務代碼上的貢獻不見得比別人多，但在評審代碼、重構代碼上做出了較好的貢獻。
TGO 上海會員、永輝超市開發中心負責人阮俊彥：針對量化，跟肅哥（陳肅）提到的有點不一樣。規範性的東西可以通過工具來實現，每次提交代碼，我們都通過代碼檢查的插件給他提示，並且我們要求整體覆蓋。這等於做了一個硬性的約定。
對於代碼質量的評估，是通過 PR 跟 CR 進行評分。評分會作為主要代碼質量的一個考核，這是第一個。
第二個是 Bug 率。大家會經常提出說，“我的模塊比較複雜，所以 Bug 數量多；他做的模塊比較簡單，所以 Bug 數量少。”我們是依據實際承擔的工作量來進行評估的。現在針對工作任務的拆解，最大顆粒度不能超過兩天，最好是一天以內可以進行代碼提交的。我們用 Bug 和“工作量”得到一個比例，雖然不是很科學，但是 Bug 比例跟實際工作量應該是有一個平衡點的。
第三個就是上線後的問題。線上 Bug 的問題是整個團隊都會背，肯定有一個團隊主要負責，是研發的問題，測試的問題，規範性問題，還是產品邏輯上就已經缺失的問題？
TGO 北京會員、方雲研發績效創始人於人：
在績效考評上，我這裡做的主要是二級控制，也就是把控住經理這一級。如果組長的考核評分有問題，那麼經理就會直接去找組長。
再一個，我有一些客觀的數據在那裡擺著，如果能力也不行，並且有客觀數據擺著，你還連分數都打不明白的話，這就一線管理者能力的問題了——這是另外一個話題。
劉松：如果是管理者的主觀決定績效，如何給同學們明確的導向呢？同學們怎麼才能知道自己怎麼做才能取得好的績效？
於人：我一開始創業搞研發績效項目時，就想弄一套最佳實踐，讓大家都這麼用。現在我發現，想一招鮮吃遍天是完全不對的——當時，我的思路是錯誤的。現在是標準化產品 + 個性化配置。也就是說，每一家公司就會按照 CTO 的理解、按照 CTO 的意志給他進行設計。CTO 是對整個研發體系負責的。你要投產快還是效率高？要哪個，就把哪個權重設置得更高，然後這方面做得好的人排名就會靠前，這就有導向了。
問題二：績效考核要不要強制 271 比例？績效考核是不是應該變成數學題？
陳肅：
我不太同意這種觀點，我覺得績效絕對不能變成一個數學問題。數學問題涉及到制定全面的指標，這就一定會產生某些方面的偏差。我聽過最誇張的笑話是，公司以代碼行數作為衡量指標，半年以後基本上所有開源項目的源代碼都出現在公司代碼庫裡面了——大家不是用組件的方式，而是用代碼拷貝的方式去解決問題。
我自己比較困惑的，也是我覺得最重要的一點是，做任何量化的時候，最終被量化的基礎單元的合理性決定了你最終結果的合理性。大家都提到，無論是算工作量還算 Bug 率，測試出多少個問題，或者說做了多少個 Feature，這是很容易的。
但是，你的分母是什麼？我問過一些朋友，當然無非就兩種方式，
- 一種是非常簡單的用人天。所有東西都用人天來估算。高級人員和初級人員的人天生產率肯定是不一樣的，這會帶來問題。
- 大一點的互聯公司會涉及到很多的產品線，人員結構也比較複雜，他們更多是用像 Story Point 進行工作量的估算。 Story Point 的評估涉及方面比較多，是要大家坐下來討論的。
我們之前也嘗試過 Story Point 估算工作量，但最終又回到了人天。先是 Team Leader 估算說，我覺得這個東西大概需要多長時間完成。過後，如果他覺得這個東西難度比較高的話，可能傾向於讓團隊裡經驗豐富的人去做，以承擔者的能力作為人天估算的基礎。
我自己的觀點比較簡單。對於開發一個功能的工作量估算，只要是經過充分的討論，其實都還好——不是說上面直接壓下去的，而是有雙向 Review，最終它一定開放透明地體現在我們整個版本迭代計劃裡，大家都能夠看到。大家都知道每個人能力有差別，為什麼給他分到 10 人天，其他人卻是 15 人天？特別不合理的東西，大家都能看到，也會提出一些異議。增加透明性之後，它的客觀性就能得到一定的保證了。
我從來不相信說，你直接導出一個報表，然後可以給研發人員進行一個打分——他確實還要去綜合一些因素。這也是為什麼現在做的績效計劃裡量化的部分通常也就是 50-60 %。這是我的觀點。
於人：
老陳，你的 Story Point 用得怎麼樣？我對這個比較感興趣。
陳肅：
其實，我們最終又回到人天了，因為無法特別科學地定義 Story Point 是什麼。
於人：
有一次，我們全公司級別做集體打分，結果排名跟我心目中的排名一樣——我覺得這是挺可怕的。在這之前，我一直覺得我的判斷比別人更公正一些，更準確一些。最後發現大家集體打出來的結果和我的判斷是一樣的，也就是說，誰也不比誰高明。這個事對我有很深的教育，之後我就比較相信，只要這幫人是有一定水平的，他們打出來的分數就是差不多的。 但是需要注意的是，評價人群要有一定水平。
TGO 廣州會員、亞美信息 CTO 馮智泉：
我們現在的規模，我覺得一定是要強制分佈的。強制分佈也是一個公平的手段，否則出現一些問題。比如人比較好的 Leader 評出來高績效的人會比較多、低績效的人比較少；狠心一點的 Leader 評出來低績效的人會多。
回到本質，我同意績效本質上是個數學問題，只是說在此階段這個數學問題還沒有太好的解。 任總（任晶磊，Merico 思碼逸 CEO & TGO 鯤鵬會會員）在分享中提到的觀點，我覺得真的挺好，所有的程序員做的主要是在兩個端，一端是 Activity 活躍度，一端 Achievement 成果，要往這兩個方向去做，因為這些都是可以有數據的。如果這種數據能度量出來，並且和主觀判斷非常接近的話，那麼它會解決公平性的問題——達到這個階段的話，我覺得強制不強制就不是問題。
來自 TGO 鯤鵬會公眾號文章《我是怎麼用數學方法，統計分析遠程研發團隊效能的？》
總結一下，強制不強制在沒辦法解決度量的問題時，是有意義的，特別是在大一點的團隊裡面。 如果度量能解決公平性的問題，度量的評價跟主觀評價非常接近，那就不需要去強制了。
劉松：
我對這個問題也是蠻困擾的，特別是在 AB 的結合部、BC 的結合部——誰比誰差多少嗎？沒有差得那麼明顯。但是你一定要有個排序，對吧？你也一定要有一個比例，這部分人還是挺受打擊的。這當然是個問題，我想把這個問題拆解來看，分成兩個問題：
- 一是要不要分級。我覺得分級是必要的。 你得有最突出的同學，得有比較不錯的同學，也要識別幹得不怎麼樣的、達不到要求的同學。
- 二是要不要有強制的比例。這個我還沒有太想好。我瞭解到華為有的部門在嘗試放大 A 和 B+ 的比例，讓部門有比較大的自主權，決定這些做得還比較良好的同學到底佔多少。不那麼嚴格地一刀切，這可能更適合研發同學。當然，這比較要考驗主管的水平了，主管不能不按實際情況亂來。
要分級，分級比例是不是一定要強制，比如 271？我覺得這個可以放開一點。就像剛才智泉說的，如果結合了更多的數據指標的參考，讓他沒辦法亂來，就可以有更大幅度的浮動。我是這樣考慮的。
阮俊彥：
我也贊同智泉（馮智泉）的說法，就是小團隊沒有明確的 271，每個人的任務和結果都看得很清晰，我們整個團隊在剛開始的穩定性也不錯。
為什麼後面開始強制 271？原因有兩個：
- 團隊大了，我們要有指標性跟結果導向。
- 團隊大了，要有淘汰機制，讓團隊活力更強。如果沒有績效跟 271 的強制約定，可能就會存在有些人吃大鍋飯。271 的比例激活整個團隊的競爭意識，也讓突出的人更快地顯現出來。
於人：
強制分佈到底是解決什麼問題？或者是解決誰的問題？
我理解強制分佈解決的是中層管理者評績效標準問題。這幫哥們評績效可能能力不夠，可能傾向於當老好人。不拿這個東西卡一下，他的主觀評分肯定是問題。
這是一個保底線的問題，防止中層的老好人把績效體系徹底破壞掉。如果是你用量化的方式能解決這個問題，強不強制是無所謂了。客觀的標準上去了，能解決甚至能替代掉中層評價的話，完全就按照客觀的結果走。就是這麼一個話題。 這是第一個，關於強制分佈。第二，我是看重排名的。強制分佈出來以後，怎麼處理？我設計的邏輯是，最後 10% 默認強制淘汰。 有些中層是知道有的人該淘汰，他開不了口，老好人。我用這個機制就幫他開口，就是說最後 10% 默認淘汰狀態——但是，你的 Leader 有權利說我不淘汰，Leader 如果要救你，我允許他再給你一條命，你還繼續在這幹。我這裡放了這麼一個口子。
核心就是說，這是一種簡單的規則，體現 CTO 的意志。
阮俊彥：
剛才於人提的一點，我覺得比較贊同，就是在機制上讓 Leader 更容易地去施行淘汰的事情。有些人非常不情願去做淘汰，他覺得雖然說你產出不夠高，但是一起工作這麼久了，我不願意去做這件事情……這點我還是蠻贊同。
劉松：
微軟轉向雲計算的過程中重拾工程師文化，其中重要的一點就是取消排名。對於創造性工作，員工需要安全感，而強制 271 也給員工帶來的壞處，這個怎麼理解？
於人：
這是個高檔問題。日本還有企業提倡終身僱傭制。這個和每個公司的階段情況是相關的。我的團隊很強調 Team 考核，輕個人考核。
為什麼微軟可以這麼做？一是他的工資高於平均工資，二是招聘的都是高級人才。如果追求的是高性價比的人才，這樣的方式就不適用。
問題三：公司如何看待研發團隊的績效？
陳肅：
我們是業務結果驅動的，就是看什麼時候完成、上線後是不是會出現問題、客戶問題是不是及時解決了。我們現在客戶續費情況很好，公司對研發團隊的服務滿意度是沒問題的。績效方面公司最看中的，是量化研發團隊的延期率和客戶生產環境的 Bug 率。
馮智泉：
我覺得兩方面。一方面，“老闆如何看”這是老闆的事兒，比如老闆不懂技術，他就不知道什麼對於技術團隊是真的好，他知道的是研發有沒有支撐好業務。另一方面是看長期、短期兩個維度做的事情。長期上，我們要做制度建設比如 CI/CD、自動化平臺來提升效率；短期上我們就是根據戰略，用最優方法支撐業務。
還有就是，公司覺得你好，這個問題很複雜，需要多和老闆談，做向上管理，知道老闆的要求。
劉松：
這個問題我也有困惑。我認為這個問題的前提是，技術要保證業務成功。戰略目標對應的是戰略項目，在戰略項目上必須不能掉鏈子。沒有業務成功，什麼都沒有用。第二是一些量化指標，比如研發效能、需求的產出率，這是保證底線的。第三是向上管理和溝通，和業務部門和老闆都要有比較好的溝通。
阮俊彥：
我理解的跟松哥（劉松）比較像。我主要是負責技術指標和項目達成這兩個事情。在拆分下一年度 OKR 指標的時候，花了一個月的時間，從這個角度，我這裡的風險比較小了，項目很明確。我們要做好的就是項目交付，這是第一。
第二是研發質量，這是老闆看得到的。我們今年的大投入是質量控制。上線後的質量是業務和老闆能直接看到的。今年的質量指標會比較高。
第三個是向上管理和橫向管理。我們都是有機會接觸到業務，這時必須提供高響應的服務，要有雙向的交流，業務提問題，我這裡提出解決方案和時間。研發團隊的人比較多、工資比較高，用前面這三點可以保證研發團隊在公司的定位和在業務部門心中的定位。
於人：
我的一個總結是，數字化勢在必行。我本身是提倡考核績效要有主觀因素的。但是現在我看數字化這個趨勢是不以人的意志為轉移。迴歸本質，CTO 的價值就是研發團隊的整體經營績效。
閱讀更多 InfoQ 的文章
