近日，ONES 受邀參加 2023 QECon 全球軟體質量&效能大會（深圳站）。在會上，ONES 研發效能改進諮詢顧問陳儀，發表了主題為《如何為研發團隊打造專屬的效能提升路徑》的演講。
陳儀有著豐富的諮詢經驗，曾帶領團隊深度、完整地參與過全球化的敏捷轉型，並幫助客戶完成敏捷轉型的實踐及效能提升。本次演講，他主要從諮詢視角出發，分享自己總結的一套幫助團隊提升效能的方法論，同時也會提煉研發效能實踐中的常見誤區。
效能提升的上限與下限
研發效能是近十年軟體研發領域的熱門話題。很多軟體研發企業或部門，在這個領域投入了大量的人力資源，並設立專職的崗位。
那麼，為什麼研發效能會得到企業的高度關注呢？
根據持續改進的理念，團隊需要被允許停下手頭的一些工作，定期回顧團隊裡存在的問題，思考如何改進。可以說，持續改進是為了讓團隊變得更好、更有競爭力，防止現存問題拖累團隊。研發效能提升也是如此，其目標是讓團隊更好更快地交付客戶想要的產品。
在我看來，提升研發效能是持續改進思想的一種具體表現形式，研發效能的範圍也應該是廣泛且全面的，不應該將研發效能的理解只限定在某一個或某幾個特殊領域。
研發團隊所面臨的常見問題，主要分為四類：
- 研發側的響應能力跟不上業務創新；
- 研發協作效率低；
- 系統穩定性難以保障；
- 缺乏統一的一體化平臺。
這些問題凸顯了提升研發效能的緊迫性和必要性。經過這些思考，我們再定義一下什麼是研發效能。我比較認可的一個觀點是：研發效能是順暢、高質量、持續地交付有效價值的閉環。這個定義裡一共包含了五個要點，這裡重點解讀其中兩個要點：
順暢，代表整個研發團隊工作流順暢，沒有浪費，或者說盡量少的浪費、儘量少的等待、儘量少地出現瓶頸。所以，在研發效能實踐中，不光要考慮工程側的實踐，還要考慮研發過程側的實踐，比如工作流的最佳化、研發管理流程的規範。
有效價值，代表交付物是不是客戶真正想要的。有時候團隊非常努力，但客戶並不滿意最終的交付物。所以在做效能度量時，需要包含客戶價值這個維度。
透過定義，我們可以認為，研發效能是廣泛且全面的。然而，我們往往追求研發效能工程側的實踐，比如 DevOps 平臺建設、DevOps 工具的使用，而忽略了研發管理過程側的實踐。但後者正是整個研發專案的基礎，所以我想提出一個觀點：研發協作管理的成熟度，決定了效能提升的下限，同時直接影響了效能提升的上限。
如果把研發效能比作成正在建設的摩天大廈，那麼不斷提升大廈的層數，從 10 層、20 層到 50 層、100 層，意味著研發效能水平的不斷攀升。研發協作管理就是大廈的地基，沒有穩定地基的保證，整個研發效能大廈就沒辦法一直向上建設。
效能提升的必要路徑
在我看來，每一個企業、組織、團隊都是獨一無二的，因此在探索研發效能提升路徑時，也要根據團隊特性來定製策略。如果將一套普適性的工具推廣到所有團隊，實際效果一般會低於團隊預期，因為普適性的工具與方法，往往不會解決團隊的某些具體問題，反而可能帶來新的問題。
我把方法論一共歸納為六點，也叫「打造團隊專屬研發效能提升路徑六個實踐」：
評估團隊現狀。只有瞭解了團隊現狀，才能量身制定下一步計劃；
- 從痛點、問題出發。優先解決最要緊的痛點和問題，會最大化短期收益；
- 最佳化工作流程規範。簡化流程、簡化浪費，從底層最佳化效能管理的根基；
- 逐步工具線上化。從提升區域性垂直能力出發，逐步實現全域性最佳化和拉通；
- 建立度量指標庫。度量指標庫並不是一次性就能完整建立，因此我們可以從先解決最緊急的問題，之後再不斷維護指標庫，保證指標庫的持續更新，為效能全面度量做基本準備；
- 持續驗證度量收益，打造效能管理閉環，迭代式探尋自身組織最需要的度量指標及工。
透過這六個實踐，可以打造一套比較適合自身組織的效能提升路徑。接下來我們透過一個客戶例項，詳細看看每一個實踐的具體應用。
研發效能諮詢客戶案例
這是一家世界 500 強國有獨資企業，業務領域涵蓋金融、地產、供應鏈、創新等。它的組織架構為：集團下有科技公司及各個行業板塊子公司，比如金融行業、地產行業、供應鏈行業，部分子公司下設有自己的 IT 部門。我們此次對接的是集團下的科技子公司。
第一步，從規範化、線上化、數字化和智慧化四個維度，評估客戶團隊的現狀。具體評估時，每一個大的維度下面也會細分出很多子方向，每一個子方向也會有很多具體的條目。透過和團隊一起對每個具體條目的打分（0～5分），最終以雷達圖的形式展現全面評估結果，視覺化地評估團隊在每個維度的現狀。
- 規範化評估，主要針對團隊的交付模式規範化的程度；
- 線上化評估，主要針對研發管理過程側、工程側的工具平臺化程度；
- 數字化評估，主要針對效能指標管理體系的成熟度；智慧化評估，主要針對資料驅動戰略決策的能力。
透過評估，我們認為案例中客戶團隊的現狀是，在規範化、線上化和數字化上都有初步進展，但是在智慧化上相對薄弱。
第二步，我們基於客戶現狀開始梳理痛點。
比較常見的梳理方式是跟不同關鍵角色進行訪談，組織群體性工作坊、敏捷回顧會等，儘可能讓研發團隊高度參與。一方面可以更全面地收集痛點和問題，另一方面團隊從問題梳理上就高度參與，之後在推行任何改進措施時，會有更高的主觀能動性。
透過痛點收集，我們將客戶遇到的問題歸納為三類：
業務數字化轉型，急需 IT 專案管理的提升；團隊、不同角色間的協同效率較低；缺乏統一的研發協作平臺。
梳理完之後，我們會形成一個痛點的待辦事項，從多個維度去區分問題的緊急性，從而打造下一步的實施策略。
第三步，用價值流圖分析（VSM）最佳化研發流程。透過視覺化團隊中的工作流程，讓團隊有更好的視角對目前的工作流進行審視，識別其中的浪費，從而最佳化整體工作流。
在該客戶案例中，我們透過最佳化組織級的管理規範、專案管理規範，以及一些專門痛點，比如需求管理、測試管理、運維管理等，進行重點最佳化。當我們把團隊的基礎性問題解決掉，再去構建效能平臺時，就會有一個很好的根基。
第四步，從全域性為客戶規劃效能提升藍圖，按階段逐步實施。
基於痛點梳理及流程最佳化，我們為客戶團隊整體規劃了以最佳化流程規範、整合平臺工具、提升持續整合測試能力等為主要方向的效能提升體系藍圖。整個方案實施分為兩個階段：
在第一階段，從最佳化現有團隊研發規範開始，結合客戶現有工具的使用情況，按照最小 MVP 的原則，打造了以 ONES 研發管理平臺為中心的初始版研發效能平臺，打通企業內部的工具鏈，實現從業務需求提出到需求實現、釋出上線的端到端的整合。此外，在持續整合階段，我們也將靜態程式碼掃描和安全程式碼審計作為質量保障的手段。
第二階段，在持續整合和持續交付能力上，除了靜態程式碼掃描外，我們也整合了更多的質量保障體系，包括介面自動化測試、安全靜態掃描、安全動態掃描等一系列功能側的實踐，逐漸提升整個效能體系的質量保證。同時，繼續深化效能研發一體化平臺，讓工具更加整合，為效能度量體系做準備。將優秀實踐推廣到其他子公司，形成集團級知識財富。
第五步，建立效能指標庫。我們透過定義指標體系，包括了指標定義、計算公式、指標意義、資料來源以及面向角色等因素的考量，從不同角度來定義指標、維護指標。比如從管理層、專案管理層、業務視角，我們更關注資源投入、專案質量、專案成本，更關注專案週期、交付週期等指標。但是從運維角度來看，他可能更關心故障響應的時效、故障處理的時效等指標。
與此同時，在驗證效能指標時，也要先驗證緊迫性較高的指標，解決緊迫性較高的痛點。
最後一步，打造效能指標的管理閉環。
透過 MVP 的模式，我們以敏捷迭代的方式，在每個迭代中選取少量指標，結合痛點，優先選取緊迫性較高的痛點，然後以相關指標作為前幾個迭代的實施物件，定期分析，形成改進行動項，最終形成閉環。
在每一個迭代中，我們都會按照分析問題、選取目標、選取指標、獲取資料、分析反饋、改進落地的順序去實施。
有了改進指標後，接下來是打造效能指標的管理閉環。
最終極的目標，就是結合我們構建的研發效能一體化平臺，實現效能管理的閉環，打造出一個資料驅動的效能度量視覺化平臺。
透過這樣一個平臺，我們可以自動化地產出各種視角的效能指標以及結果分析，對整個企業未來的規劃產生積極的影響作用。
最後總結一下，透過打造效能提升路徑的六個實踐，我們為客戶打造了一個效能提升藍圖。其中實現路徑可以歸納為三個環節：
搭建組織級的流程規範，引入敏捷及工程的相關實踐，完成效能提升的基礎性準備工作。以 ONES 研發管理平臺為中心，打通上下游的釋出平臺，形成一體化平臺；同時支援穩敏雙態的專案管理，也就是敏捷和瀑布雙模式的專案管理能力。利用資料驅動效能改進閉環，打造出一個比較成熟的效能管理平臺。
透過這三個環節，我們幫助客戶在不到一年的時間裡就打造出了效能平臺的雛形，幫助客戶的研發管理規範得到了進一步提升，同時也提升了研發管理體系的成熟度。未來，我們也會繼續幫助客戶進行研發管理工程側的工具平臺及度量體系建設。
研發效能實踐中的常見誤區
第一個誤區是期望「快餐式」的「拿來主義」。
很多客戶期望透過直接引進其他廠商在效能提升上的優秀實踐，在短時間內複製出類似的效能收益。這樣做，往往會忽視瞭解和最佳化自身研發管理規範的重要性，也低估了新工具在團隊內部推行的阻力及學習成本。
一般來講，將普適性的工具引用到團隊中，最後往往只是接入了工具，並沒有真正使用起來。所以透過合理的方法完善研發管理流程規範，逐步透過一些試驗性實踐，摸索出最適合自身組織的效能提升路徑才是正解。
第二個誤區是迷信單點區域性工具能力。
單點區域性的工具，在研發初期往往很有收益，因為它可以幫助我們解決很多具體問題，尤其是那些優先順序較高的問題。但是隨著研發效能程式的不斷深入，單點工具的收益會隨著時間逐漸遞減，因此企業需要從更高的視角出發，對研發效能的一體化平臺進行整體規劃。
第三個誤區是偽工程實踐，為了做而做。
很多團隊裡充斥著偽工程實踐，為了做度量而做度量，為了做公司的實踐而去做實踐，然而團隊可能沒有真正瞭解這些實踐應用的真實意義。一個原因是團隊的思維還沒有跟上效能工具和實踐的升級，導致很多工程實踐在團隊中的應用是被動的，而不是主動的。
另一個原因是，某些團隊的效能指標直接與績效指標掛鉤，導致成員為了提高績效而做一些假資料。
很多團隊缺的不是工程實踐的數量，而是工程實踐執行的深度和態度。所以我也建議，在梳理痛點的時候，最好是由團隊整體來參與。從一開始就培養團隊的參與感，避免偽實踐情況的發生。
第四個誤區是試圖提升研發效能的絕對值。
提升研發效能的絕對值，在現實發展的趨勢下，這是一個不合理的現象。因為隨著企業規模的壯大，研發團隊的規模也在不斷擴張，由此帶來的團隊內部溝通成本、協作複雜度，也會成倍增長。加上軟體架構的複雜度也在不斷攀升，最終研發效能的效果很難保證一直是上升趨勢的，它在某一個階段肯定會有所下降，或者產生波動。在這種情況下，我們能做的，就是儘可能地減緩研發效能惡化的速率。
總結
首先，提升研發效能是持續改進思想的一種具體形式，因此我們對研發效能的理解應該是廣泛的、全面的，而不能只針對某些具體的、垂直能力的實踐。
其次，研發協作管理的成熟度是持續提升研發效能的基石，它保證了研發效能的下限，同時會直接影響到研發效能的上限。
再次，我們需要利用一些方法論，去探索提升效能的專屬路徑，儘量避免採用一刀切或者一般普適性的工具流程。
最後，團隊需要提前充分了解效能建設的誤區，提前規避，少走彎路。
以上就是我今天的分享內容，希望能給大家帶來一些思考或啟發，幫助我們所有研發團隊找到最適合自身的研發效能提升路徑。
