在互聯網軟件企業，今年是一個大家都在非常努力降本增效的年份，包括且不限于人員優化、人員結構優化、技術成本優化，提高人效，提升研發效能等等。
這篇文章我們從研發效能出發，嘗試梳理一下打造高效能研發團隊的 5 個關鍵步驟：目標、流程、團隊、個人、度量。

1. 找到正確的目標

技術最終都是通過業務產生價值，就算是技術類的產品，最終產生價值也是業務，只是這個業務是一個強技術屬性的業務。

一個高效能的研發團隊管理者，其首要任務是為團隊找到正確的方向和目標。這里正確的目標可以分為業務目標和技術目標。

業務目標的設定可以分為兩步：

和業務方、上級溝通，弄清楚他們的目標是什么，以及明確他們對于研發團隊的預期是什么；

在業務方目標和上級預期目標的基礎上，分解目標，內化為帶有一定進取的團隊目標。

技術目標的設定可以分為兩類：

解決過去留下來的問題，歷史的問題我們通常稱之為技術債，技術債分為主動債務和被動任務，主動債務大多數是在業務發展過程中為了追求速度而做的一種技術妥協，而被動債務大多數是團隊能力或水平不足、業務的演化或技術的發展導致的代碼或架構劣化任務，或者不再適用于當下的環境。技術債不一定是一個壞事，一個產品進化到要償還技術債時，說明業務應該還不錯了，在這個當下，找準時機，有計劃的償還一些技術債務是非常有必要的事情。

解決將來可能出現的問題，將來的問題我們一般稱為技術前瞻性，即對即將出現或已經出現但不是很成熟的技術做一些預研和準備，居安思危，提前布局技術投資。

2. 優化流程，做到極致

所謂流程，是基于時間線做一件事的過程，是指一系列的、連續的、有規律的活動，而這些活動以特定的方式進行，并導致特定的結果的產生。其關注的是過程，我們希望通過優化和設計過程來最終達到一個更好的結果。我們做任何一件事情時，都會有流程，只不過有些流程是自發的，有些是被設計出來的，或者說是優化后的。在團隊演化的過程中，流程優化和流程管理經常會提出，這些操作都是為了提煉流程或優化流程，讓效率更高，讓質量更有保障。

流程最終目的在于創造價值，也就是增值，這里價值在研發過程中更多的是質量提高、效率提升等。

研發流程要重點關注兩個問題：

流程對于做正確的事的輔助作用，是否能通過「過程正義」得到「結果正義」；

流程本身的效率，是否整個流程是順暢且高效的。

在具體實施時我們可以考慮如下一些方式：

提高流程的自動化水平或者說工程化水平，如快速的本地構建速度、完善的自測環境、自動化測試、持續集成、流程的系統化等等；

減少流程的溝通成本，比如說 DevOps 減少的是研發和運維的溝通成本，又或者全棧，減少的是前后端的溝通成本；

流程分層：針對不同的級別將流程描述清楚，高層次流程較為粗略，中層流程和操作級流程會非常詳細，以方便項目各級管理者和基層員工按照相應的流程開展工作；

大處著眼，小處著手：先全局出發找問題，再深入細節解決問題，比如我們希望提升研發流程的交付速度，可以收集產品周期中每一個階段所占用的時間，包括計劃的時間和最后實際花費的時間，然后通過對比尋找問題最嚴重的環節，再去解決這個環節。在具體落地時可以考慮流程的可視化。

3. 提升團隊效能

我們是要打造一個高效能的研發團隊，團隊是作為一個整體存在，在團隊之間有分工，團隊成員之間有協同，溝通等等，如何讓 1 + 1 > 2 是在團隊層面要解決的問題。以下有一些方法可以提升團隊的研發效能：

減少團隊認知成本：如統一開發 IDE；提供完善且性能強勁的統一開發環境和聯調環境；團隊分工以模塊負責人為核心，一個小團隊一直聚集于一個模塊，不經常輪換；

增加知識流通，促進知識共享：如知識庫的建設、好用的文檔系統、代碼審查、機制化的分享會等；

團隊的技術債會慢慢累積，在盡量減少債務的前提下把業務跑出來后，在適當的時候償還部分債務，出來混遲早都是要還的，技術債也一樣。

快速開發模式，嘗試測試左移或測試右移。

• 測試左移是指在研發流程中，把測試的覆蓋范圍從傳統的測試節點中釋放出來，將其向左擴展，介入代碼提測之前的部分，如開發階段階段，需求評審階段，讓研發人員在架構設計時就考慮產品的可測試性，并盡量進行開發自測，同時評估需求的質量，比如分析需求的合理性以及完整性等。
• 測試右移是指把測試的覆蓋范圍從傳統的測試環節中切出來，將其向右擴展，更多地融入代碼部署、發布，甚至上線之后的步驟中。

灰度發布，監控，A/B測試，混沌工程

專業的項目管理，研發人數達到 30 人以上時，由于缺乏項目過程中的溝通、控制能力，是造成開發項目混亂，需求返工，研發效率低下的重要原因。如果能夠在產品規劃時提前發現新產品的技術難點，就可以提前進行相關的技術研究和技術開發工作，減少產品開發項目實施過程中的技術風險。在項目過程中，加強溝通、協調，及時發現各種風險因素和意外情況并采取應對措施，有助于項目計劃的順利實施，從而提高研發的效率。

4. 強化單兵能力

研發最終是要落在人身上，強化單兵能力，對于提升整個團隊的效能有極大的促進作用，單兵能力的高低能決定團隊總體效能的高低。

一個人的單兵能力可以從目標、效率和初心三個方面來分析：

4.1 目標

高效能人士的七個習慣的第 2、3 個習慣分別是以終為始和要事第一，當我們需要做一件事情的時候先明確本質的要解決的問題是什么，規避掉「XY Problem」，尋找到解決方案以及實現方案的過程中聚焦最重要的任務。

在個人的目標中，我們常見的目標包括業務成功、幫助團隊、個人成長。這三個目標是有遞進關系的。

• 業務成功是我們工作的最根本目標，也是基礎；
• 在業務成功的基礎上，下一步考慮幫助團隊成長；
• 在幫助團隊的同時，給自己帶來一些直接或間接的成長機會。

4.2 效率/速度

可以仔細評估個人研發過程中哪些部分可以提速，如在開發前、開發中和開發后：

開發前：完善而友好的開發環境，不要過度設計，在保證一定擴展性的夠用就行，鼓勵方案的討論，并將其機制化；

開發中：熟悉而高效的編輯工具和代碼管理工具（如 Vim、Git，需要有一些刻意練習）讓你能高效的編碼，個人技能的邊界擴展（如前端懂一些后端，在溝通交流中障礙就會很多；甚至全棧，溝通交流在自己腦袋里面完成）；

開發后：盡快讓代碼跑起來，快速的本地構建、完善而快速的聯調環境，使用單元測試和持續集成。

4.3 初心

對于業務，對于當下手上的事情能自驅的完成，最好是將目標和興趣結合起來，主動的提出自己的想法并推動實施。

5. 合理度量但不追逐度量

著名管理大師德魯克有句名言：“沒有度量就沒有管理”。

當我們開始想把研發過程的效能管理起來的時候，一定需要明確度量，即哪些指標可以表示效能的高低，并以此來判斷是否有改進。
我們可以從三個方面來度量：

研發效率/速度：開發的速度，構建的速度，需求的吞吐率，需求的周期，代碼行數，平均修復時間等；

研發質量：測試 BUG 數、新舊 BUG 比，缺陷率、缺陷修復率、線上 BUG 數、線上事故數，性能、安全等；

業務價值：營收、NPS、功能使用用戶數、客服反饋數等。

度量的大概過程是從研發過程中獲取數據，并用這些數據來評估過程的效率，質量和價值。
通過度量來評估研發團隊的表現，發現對研發工作效率有阻礙的地方，了解流程是否有待改進的關鍵點并尋求改進的方案。

在我們度量的過程中，度量指標盡量不要與績效掛鉤，而是應該作為參考和工具，幫助團隊提高效能。
不要過度追逐度量，不要讓度量最后變成一個「數字游戲」，避免只關注一些局部指標而導致局部優化和全局優化脫節的情況，對于過度的不顧大局的局部優化說 No，因為這種局部的優化可能導致整體效能的降低。

6. 小結

我們實現一個系統或一個需求，其實就是在生產一個產品，需要若干個「工序」，從產品需求出發，經過開發、測試、發布、運維等環節，從一種工種流轉到另一個工種，最后交付給用戶。
在整個研發過程中，把每道工序定義清楚，明確輸入和輸出的標準，保證每個工序產出的質量，提升每個工序的速度，銜接好工序與工序，就能讓整個過程更高效能的流轉。

從這里可以看出一個高效能的過程包括如下三個方面：

清晰的「工序」定義、每個工序有標準的輸入和輸出；

保證每個「工序」的質量和速度，做到極致；

保障「工序」之間連接的有序；

轉化成研發過程，一個高效能的開發過程包括如下四個方面：

清晰定義每個環節，明確每個環節的輸入和輸出的標準，做好自測；

保證每個環節的質量，產品需求有需求的質量要求，設計有設計的質量要求，研發有研發的質量要求；

強化每個環節中個體的單兵能力，提升每個環節的速度；

通過專業的項目管理，保障環節之間的有序進行，不快一步也不慢一步。

那么如何簡單評估一個研發團隊是否是高效能的呢？

看這個研發團隊的一個需求從想法到上線，全流程平均生命周期需要多久，上線后的質量如何。

你好，我是潘錦，超過 10 年的研發管理和技術架構經歷，出過書，創過業，帶過百人團隊，也在騰訊，A 股上市公司呆過一些年頭，現在在一家 C 輪的公司負責一些技術方面的管理工作。早年做過 NOI 和 ACM，對前端架構、跨端、后端架構、云原生、DevOps 等技術始終保持著濃厚的興趣，平時喜歡讀書、思考，終身學習實踐者，歡迎一起交流學習。微信公眾號：架構和遠方，博客： www.phppan.com

總結

以上是生活随笔為你收集整理的打造高效能研发团队的 5 个关键步骤的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。