熊志男：研發效能提升這場仗，怎麼化被動為主動？

責編 | 韓楠

約  4698  字 | 9 分鐘閱讀

今天，我們一同來聊聊研發效能相關的話題吧。

我想可能有很多人和我一樣，最初對於研發效能的理解就是等同於研發效率，認為只要從技術和工具層面持續改進，把原來需要人工執行的操作變為可以自動化執行的，就可以實現研發效能的提升。

當我抱著這個理念在工作中頻頻碰壁時，我才重新思考它的價值， 而我現在常常拿軍隊的工程能力和組織效能來類比研發效能，不知道你對於研發效能這件事又有什麼樣的認知、想法呢？

可以說，研發效能，絕對是2022年軟體研發領域最熱的詞之一。不過你有沒有發現，針對研發效能的看法，出現了兩極分化？

一些人極度重視研發效能提升，他們投入時間學習相關知識、搭建工具鏈和度量體系；而另外一些人卻是持有負面的看法，認為研發效能是個噱頭，終有一天會搞垮團隊。

研發效能＝工作時間？

研發效能＝個體的效率？

之所以出現這樣的分歧，在我看來是由於不同人的視角不同，進而出現了不同的觀點。就如凱撒大帝的名言裡說的：“人們只會看到自己想看的東西”。

比如有些管理者甚至錯誤地把研發效能和工作時間等同起來了，只要團隊投入足夠多的工作時長就能夠得到研發效能的提升。

這種認為加班能帶來效能提升的想法，是存在明顯邏輯錯誤的，效能是對效率和效果的綜合評價，這種思路明顯是隻考慮效果而忽略了效率的做法。

另外有些工程師把研發效能等同於個體的效率，認為只要從個人角度幹活兒爽了就能帶來研發效能提升，而不需要再透過度量給自己戴上緊箍咒，覺得研發效能就是管理者為了壓榨員工而編造的謊言。

管理者VS員工

整體VS區域性

其實這種情況，應該是管理者只關注效能的結果資料，而忽略了團隊成員的感受，由於管理者關注的效能代表了整體，而員工個體代表了區域性，往往整體和區域性存在關聯性的同時，又存在一定的差異性。

而 研發效能 ， 恰恰是從提升個體效率和整體協同兩個層面著手，從而才能夠使一個團隊組織在一起達到一加一大於二的效果。

實質上，之所以產生這些對於研發效能的負面的看法，就是由於從管理者角度和從一線工程師角度，對其理解存在不一致。而在如火如荼的研發效能提升運動中，一線工程師往往處於被動位置，即使對於一些研發效能提升的做法和度量指標並不一定完全認同，也不得不去努力適應。

下面我就分別從兩種視角，來分別梳理下對於研發效能的理解。

其中包含 管理者視角對於研發效能提升做的不到位的地方， 以及 工程師視角如何正確理解和應對研發效能提升這件事情。

管理者視角的研發效能

理論上來說，管理者視角對於研發效能的理解，應該是更接近其真實意義的，因為效能的本意就是強調工作成果的最終有效性。

從整個企業組織來說，其工作成果的最終有效性是讓企業的業務達成目標，獲得成功，而企業的管理者是更關注和理解業務成功這件事的。

業務結果固然重要，

管理不到位卻暗藏隱患

但實際情況是，有些管理者在關注最終結果的同時，卻在一些細節方面做的並不到位。

舉個例子，就拿最常見的做法來說吧，他們簡單粗暴地用研發效能度量結果資料，在不同團隊或是不同個體之間橫向對比，這就會導致研發團隊和工程師之間的過度內卷。

那怎麼做才能夠少走彎路，改善或改變這樣不良的業務現狀等？下面我將結合過往的一些實踐中總結、歸納沉澱下來的經驗，以及一些切身心得，與你進一步討論交流下。

我主要將圍繞目標的一致性、關注團隊和個體的差異性、關注基礎設施和工程師文化建設這四個方面，分別闡述下建議管理者著重關注的地方。

Get這四招，助你破局

1）目標的一致性：在很多企業內部，不難發現，往往主要是由管理層負責整體目標的制定、大方向的決策，而下面的團隊則逐級實現目標的拆解並負責具體任務的執行。

而目標和方向的正確性，是業務是否能夠獲得成功的一個關鍵條件。

那麼當有些組織由於層級過多或者其他原因，造成了上級管理者制定的目標和方向，並沒有很好地傳達下去，導致下級團隊沒有獲取足夠的資訊，就會使執行者之間形成各自的理解，當彼此之間朝向相反的方向產生反向作用力時，就會形成內耗從而降低整體的組織效能。

總結一句就是： 上 傳下達多把關，層層目標拆解好，不然，內耗低效跑不了。

2）關注團隊和個體的差異性：由於制定度量標準和流程機制是需要成本的，那麼有些管理者常常為了節省成本，而採用統一的度量標準和流程機制，來衡量和約束不同的團隊和個體。

拿這樣一個 例子來說：

中後臺研發團隊和前臺業務研發團隊的效能指標，理應是存在一些差異性的。

中後臺研發團隊所開發的系統服務更關注穩定性，而前臺業務研發團隊，則更需要關注需求的快速響應，從而支援業務需求的不斷迭代。這時候如果採用同樣的效能指標，來橫向對比，則是不可取的，會造成團隊的真正目標和度量指標之間的脫離，從而對研發效能提升帶來負面效果。

總結一句， 效能指標需得有差異，管理也並非一錘定音，我們大可一試。我想，管理有方，同心協力，出不了奇蹟，也定能出個好成績。

3）關注基礎設施建設：一些研發管理者，喜歡重點關注團隊的開發模式和流程規範，比如敏捷開發和質量內嵌流程規範的推行，而對於研發的基礎設施關注不夠。這裡指的基礎設施包含高度自動化的效能工具、可擴充套件的系統架構設計，以及低技術債的程式碼。

而 如果沒有一定的基礎設施支撐，僅僅靠模式和流程的改善帶來的效能提升 ， 只是表面的 ， 無法持久。

4）關注工程師文化建設：工程師文化的建立不是一朝一夕的，研發團隊的核心骨幹和架構師的工作風格習慣，往往會極大地影響一個團隊的文化，還需要 管理者的關注和引領，才能夠使工程師文化固化 、強化 到團隊的行為 、 習慣中去。

比如對於效率和質量的極致追求，能夠激發團隊潛力持續追求較高的研發效能，而不是機械地去應付效能指標的要求。

前面提到的幾點不足，並不一定全面，只是 希望在研發效能提升的過程中，研發管理者作為團隊的重要角色，能夠 有 意地多一些思考和前瞻 性思維 ，從而起到正確 、有威信力 引領的作用。

工程師視角的研發效能

與管理者不同的是，一線工程師在工作中每天面對的，都是具體的工作和問題，比如架構設計、程式碼編寫和溝通協作等。

在很多研發團隊中都存在著這樣的現象，有些技術能力很強的工程師，具備優秀的技術功底和個人素質，卻沒有很好的績效，得不到領導的重視，沒法完全發揮自己的價值。

或許說到這，你也已經考慮到了。的確，這都是由於從工程師的視角，缺少了對全域性角度研發效能的關注，而過多關注個體的效率提升，因此需要培養換位思考的習慣。

研發效能提升這場仗，怎麼化被動為主動？

下面我帶你一起從提升個人工作的有效性、關注整體工作成果的有效性，和有效使用效能度量指標三個方面，分別梳理下如何一步步實現視角的轉變，從而在研發效能提升這場戰役中化被動為主動。

提升個人工作的有效性

個人工作有效性的提升，代表了戰爭中單兵的作戰能力，士兵需要透過不斷地刻意訓練來獲得提升。放到我們們這行，道理如出一轍，比如我們參與大規模分散式系統的設計與開發，或者應對電商系統的大促備戰活動等，都能夠在實踐過程中獲得能力的提升，並不斷驗證個人工作的有效性。

裝備齊全的古羅馬士兵

圖源：知乎專欄@冷兵器研究所

下面是工程師提升個人工作有效性，需要關注的三個核心要素：架構設計、程式碼質量和溝通協作。這裡就不一一展開說了，我分別梳理、歸納總結了幾點，具體內容大家可以結合下圖來看。

我們接著聊，不知你有發現、遇到過沒，現實中有一些個人能力很強的工程師，往往給人留下難以溝通的印象。如果看到這裡，溝通方面你也有些困惑，或是曾經抑或當下仍時不時或偶爾犯難。

我建議，我們倒不妨這裡就先停下來一會，再細看下這三點中的溝通協作部分，或許可以給你帶來或多或少的啟發、思考。當然，後續我們也仍需多加關注，持續精進。

當然，溝通的形式有多種。除了透過語言溝通以外，寫出好的文件、註釋和專案日報等，也都很好的，抑或特定、關鍵節點、階段，於你而言很重要。

當我們透過充分表達自己的程式碼設計意圖和工作進展，不但能夠讓其他團隊成員或者管理者，更好地瞭解自己的工作，而且還可以進一步幫助你提升自身工作的有效性。

如果你看過《三體》，應該會驚訝於三體人高效的溝通方式，他們透過腦電波溝通，每個三體人大腦的意圖都是完全透明的，這樣會極大提升溝通和協作的效率。

關注整體工作成果的有效性

能夠具備全域性思維是工程師成長為架構師的必備條件，從需求階段、到程式碼設計和編寫、再到測試和運維去關注整個研發生命週期，目的是為了消除從區域性視角對效能理解的不足。

如果把IT團隊和工程師比做古代軍隊中的工程兵，修橋鋪路的工程能力是能夠協助戰爭獲得勝利的重要條件，其前提也是能夠在合適的時間、地點構建有效的工程設施。

古羅馬軍隊的防禦工程設施

圖源：知乎@手望Sowarm  《七月的皇帝：凱撒大帝的傳奇人生》

因此工程師作為團隊的一員，除了關注個人工作有效性的同時，還需要更多的在需求和實現的一致性、進度和風險層面，給足夠的關注，才能更大程度上促進提升團隊整體工作的有效性。

有效使用效能度量指標

研發效能度量的目標，是團隊而不是個人，但並不是說工程師就不用關注效能指標了，我們 可以 透過對齊團隊的效能指標，來審視自己的工作內容和產出。

隨著研發效能度量體系的日臻完善，相關指標資料也越來越多，常常使一線工程師有無從下手的感覺。那麼基於全域性優先的角度出發，我認為工程師視角應該 更加聚焦於外向型行為相關的效能指標，因為這些行為更能影響全域性的效能提升。

度量的目的是為了驅動改進，因此在重視全域性而且面向結果的度量指標基礎上，還需要透過層層拆解才能夠落實到具體的行動上。最常見的就是團隊需求交付週期的度量，需求交付週期是效率維度的全域性指標，其特點是鏈條比較長和參與角色較多。

研發工程師視角的工作產出，一般會影響到設計、編碼和測試這仨階段。因此就跟下面這圖中的一樣：

首先我們可以做的就是透過改進工作方法，或者利用一些效率工具，來降低研發測試周期，在整個需求交付週期中的佔比。

然後可以透過關注全域性效能，分別把影響範圍逐步擴充套件到整個需求交付週期，這是一個由內而外、層層遞進的順序。

在我看來，站在工程師的視角對待研發效能的正確態度，應該是把它作為一個方向指引，而不是作為標尺和模具來束縛自己，透過定期關注度量指標來改善自身的行為，持續提升個人有效產出並重點關注與外界發生互動的外向型行為。

總結起來就是 瞄準正確的方向，做好自己的事情並持續影響他人。

融合多視角的工程實踐

最後一部分，我還想給你介紹兩個融合多視角的研發效能領域的工程實踐，需要藉助工具來實現資訊的打通和多視角的融合。

拿現代化的城市舉例，比如地鐵線路和立體公路這樣四通八達的交通基礎設施，往往代表了其現代化程度，是因為這些設施能夠極大促進人員和物資的流動效率，從而促進整體的經濟發展。

圖源：天空之城 城市的動脈

而 在軟體開發生命週期過程中，也會涉及到不同階段和不同角色，會有不同的資料產出，如何實現資料和流程的打通，是研發效能領域需要關注的事情， 下面就分別介紹下。

0 1  建立需求與研發過程資產資料的對映關係

透過以不同層級的需求為主線，把執行具體技術任務所產生的研發過程資產串聯起來，這樣的好處一方面從管理者和業務方的角度，能夠更加清晰地瞭解一個需求在技術層面的投入和風險等資訊。另一方面作為工程師，在針對具體技術任務的事前準備、執行過程和事後覆盤等過程中，都能夠更加關注其所產生的需求價值。

0 2  建立全生命週期的研發流程自動化規則

保持專注和不受干擾，是能夠提高研發效能的重要因素。而如果能夠把管理者與工程師之間、團隊內部不同角色之間約定的一些規則，透過自動化的方式實現，就能借助自動化本身高效和客觀性的特性來消除干擾和提高效能。

這些規則是建立在打通研發流程工具鏈的基礎上實現的，可以包含需求任務的狀態自動變更、進入當前階段的標準閾值判定、對質量標準的自動結果檢查、效能度量資料的自動彙總分析和風險的自動預警等。

優秀的工程實踐的推行和實施，需要團隊的管理者和工程師都能夠參與進來。而 需要的工具支撐 ， 大多是由專職或者兼職的研發效能團隊來實現的，因此也可以說在這裡補充了研發效能團隊視角的效能提升。

結語

我的主要工作是從事研發效能平臺建設和具體實踐的推動，同時也分別從事過測試、開發和產品崗位，基於工作需要也與一些架構師、質量管理者和開發經理等角色，探討過研發效能的話題，因此本文我努力站在旁觀者的角度，帶你一起梳理了不同視角對於研發效能的理解。

其目的也在於想要幫助研發效能提升的關鍵角色——廣大的研發工程師，能夠從多角度、全方位，來看研發效能提升這件事情。在日常的研發工作中，能夠持續地關注價值、保持專注且目標明確。

全文思維導圖 （可點選圖片，放大檢視)

便於快速回顧、梳理全文，抓關鍵點

這裡再來思考下，之所以對同一件事情，管理者和工程師，分別有著不同的理解甚至衝突，有時候甚至都認為對方在拖後腿。到底為何才會如此？

我想，就是因為雙方的視角不一樣，管理者更關注全域性有時候忽略了細節，工程師專注於細節而常常缺乏全域性思維，這樣就會造成雙方努力方向有偏差、前進的步調不協同。

而反觀一些高效能的團隊和個人，往往都能實現個人和整體的良好協同，並能夠最大化利用先進的流程和工具。“道長且阻，行則將至”，無論你工作中是何種角色，讓我們一起探索研發效能提升之路。

今天的分享到這裡就結束了，希望今天你可以有一定收穫。如果對今天的內容有共鳴，也可以分享給你的朋友。我們可以留言區裡一起繼續交流、討論。

THE END 

轉載請聯絡ITPUB官方公眾號獲得授權

—————————————————————————————————

歡迎各領域技術人員投稿

投稿郵箱 |   hannan@it168.com