業務背景

和訊網是一家成立于 1996 年，集資訊、金融數據工具、知識社群等功能于一體的財經服務網站。作為一家核心業務較平穩且傳統的企業，和訊網的研發一直處于足夠支持業務需求的狀態。

 

 

效能挑戰

前期基礎建設

研發數字化工作從DevOps建設開始。

和訊團隊首先將不同職能的責任解耦，明確定義研發、測試、運維三者的邊界，使測試承擔起全局的質量控制工作。

其次，搭建起包含 SonarQube、Git、Jenkins、TAPD、Cat、Yapi，Zabbix 等工具的 DevOps 工具鏈，借助工具自動執行規范，同時保障研發過程數據的留存。

 

度量效能，以量化管理守住下限

 

為了客觀回顧研發過程及成果，和訊團隊引入了思碼逸研發效能分析平臺，對研發效能進行度量。

思碼逸平臺能夠從代碼庫中提取量化指標，從組織、團隊、項目、個人不同層級，提供開發效率、軟件工程質量、組織人才發展等多維度洞見，使研發管理不再處于黑盒狀態。

建立研發效能度量體系

微軟 Velocity Lab 這篇講解 SPACE 生產力度量框架的論文中提到，如果不顧業務階段、團隊特征等上下文，一刀切地使用單一指標，甚至進行橫向對比，就落入了過度簡化的陷阱。不僅會給團隊帶來錯誤信號，引發質疑，更可能誤導一線開發者造數據搞面子工程，效果適得其反。

效能包含了研發工作的多個維度，其度量并不存在銀彈。度量本身已經是對軟件研發這一復雜系統工程的抽象，必然存在片面性。因此需要通過精細設計，來避免系統性的誤差和盲區。

和訊網引入了效能分析工具后，初步建立起了度量體系，便于研發團隊基于自身情況靈活選定關鍵指標：

在交付效率方面，基于代碼分析能力，代碼當量、代碼影響力等創新效率指標與需求交付周期、需求交付數量、按期交付率等常見指標形成互補，幫助團隊從資源效率+流動效率兩個視角進行度量復盤。除了產能指標以外，產出穩定性、貢獻分布、工時投入、工作飽和度等數據也幫助團隊更全面地理解效率表現。

 

在交付質量方面，函數復雜度、模塊性、代碼復用度、測試覆蓋度、注釋覆蓋度、代碼問題積壓等側重軟件工程質量的指標，能夠作為測試環節質量指標的補充，引導開發人員主動分擔質量優化工作，不僅能在開發階段就避免一大部分基礎錯誤，也能提升代碼的可讀性與可維護性，避免技術債堆積。

在交付價值方面，首先通過投入工時與代碼當量/需求交付數量的交叉分析，量化研發環節的投入產出，合理調配研發人力資源；其次，通過將產品團隊與需求環節納入量化考核，需求與業務戰略目標直接掛鉤，帶動產研與戰略對齊，這部分實踐在后文還會提及。

 

交付成本與交付能力的度量模型還在持續細化與推行落地中。

 

由點及面逐步推進，尋求團隊共識

考慮到量化管理是由研發管理者引進，而勢必對團隊原有思維和行為習慣帶來沖擊，研發效能度量不能一蹴而就。和訊從流程、規范、方法改善起步，不斷爭取團隊共識，培養團隊使用數字化度量指標進行復盤的習慣。

 

強化激勵，提高主觀能動性

考慮到自身人才資源較薄弱，技術能力、工程實踐與一線互聯網企業的研發團隊存在差距，和訊網研發團隊決定將效能度量納入考核與排行，強化激勵效果，縮短獎勵周期，提高研發團隊主觀能動性。目的是為了守住下限，減少由主觀因素引起的低效能問題。

應用到考核排行，就難免收到對量化模型可信度的質疑。和訊網團隊的做法是保證模型的公開透明，廣泛征求反饋與建議，達成共識以后不輕易改動。即使出現有爭議的案例，則共同討論模型有無需要查缺補漏之處，而不做特例調整。

 

激勵帶來了良性競爭。研發團隊不僅向內看自身效能變化趨勢，也向外看和近似業務性質、近似項目階段的其他團隊的橫向對比。直觀對比打破了部門間的壁壘，推動部門間自發交流、學習優秀研發實踐，使知識能夠沉淀下來，并在組織內高效流轉。

 

承認管理手段的客觀局限

自上而下的量化管理并設置考核目標，是為了守住下限。那么是否可以繼續使用管理手段，不斷提高要求，達到提升效能的目標呢？

 

和訊網的答案是否定的。

 

前面也提到，守住下限是為了減少由主觀因素引起的低效能問題，但仍有很大一部分低效能問題是由系統性的客觀因素引起的，管理手段與制度無法解決這部分問題。如果不能意識到管理手段存在客觀局限，無限制地要求以主觀能動性提升效能，實質上就是“內卷”，即使以開發者的超負荷工作取得了一時提效成果，也是不可持續的。量化管理不應濫用而淪為“卡里斯馬型組織”的加持。

 

在和訊網的實踐中，以產能指標為例，將行業基線的上四分位線（前25%）設置為考核滿分標準。在組織的平均生產率達到行業上四分位線后，CTO 角色不再密切關注這一指標，使其作為日常管理機制繼續運行；而個人開發者生產率達到這一標準后，也不再有額外激勵。

 

更進一步的提升，需要將效能問題層層拆解，洞察根因，將責任與權限分發到研發團隊，以日常的流程體系、軟件工具、組織治理、人才培養機制、工程師文化等方面的改進，開啟研發提效的第二曲線。

 

層層拆解追問根因，在日常中落實工程改進

三種分析方法，定位效能改進關鍵環節

在研發效能的相關討論中，經常能看到著名的豐田生產方式創始人大野耐一的這句話：那些不懂數據的人是糟糕的，而最最糟糕的人是那些只看數據的人。度量不能停留在數據，重要的是從數據里洞察問題并指導改進。

以下是三種常用的分析方法：

 

度量工具化、常態化，根據業務特征針對性改進

在開發向測試流轉的環節，和訊網要求開發者在提測前，基于自動生成的軟件工程質量報告完成自測；測試部門也將度量結果納入定期高頻的報告中，監督質量控制的全流程。

 

需要注意的是，度量與改進都有成本，難以面面俱到。因此，建議基于項目階段與業務特性，有側重地選取質量指標。例如：

 

量化管理，帶動工作流優化

以往，和訊研發團隊需要等待多個業務部門匯總需求后才能開始開發，時間緊張；在發版前幾日批量提測，也給測試環節帶來壓力；來不及完成開發或被測試打回，就只能延期或砍需求。工作流中大量等待造成浪費，業務方滿意度下降。

 

和訊網以需求交付周期、任務按期完成率與工時投入為抓手，鼓勵研發團隊拆解細化任務，保障任務顆粒度適中、范圍明確。任務拆解減少了子任務間的耦合和依賴，提高了并行度，使工時預估準確性大幅提升至80%以上。

 

在量化管理延伸至上游的產品部門后（下文會進一步介紹），產品經理為了保障需求能夠快速交付，也更有動力對需求進行拆解和及時澄清，使復雜需求更早進入開發環節。

 

在需求與任務的粒度減小、分批次進入開發后，開發進度更加可控。開發人員在交付周期指標的驅動下，更早地將任務流轉到測試階段，給測試環節留下更多時間，測試人員在發版前還有余裕進行隨機測試。小批量提交代碼變更 + 頻繁進行測試與構建，也降低了軟件的質量風險，為團隊進一步建設工程能力，試點持續交付打下了基礎。

 

向上游輸出影響力，撬動業務數字化

串聯產品與研發角色，強調價值交付

許多企業的研發數字化轉型是由業務需求觸發。相比之下，和訊網的情況則有些非典型：由于核心業務較平穩且傳統，研發團隊并未受到來自業務的太多壓力。

 

相反，在推行研發數字化轉型后，需求數量不足、需求變更頻繁且隨意、需求未能帶來業務價值等等，反而成為研發團隊的瓶頸，研發團隊開始推動上游的效率與質量提升。

 

這一現象首先在產研一線呈現：研發團隊開始主動向上游要需求，并希望產品部門盡早澄清需求、避免不必要的變更。除此之外，研發團隊主動承擔了更多測試工作，以主動開啟系統需求、性能優化、技術重構等任務，以填補上游需求數量的不足。

在這個背景下，和訊網將產品需求環節也納入量化反饋中，對產品經理的行為進行數據留痕，并進行集成、清洗、分析和建模。

 

具體來說，在需求環節，不僅關注數量、類型分布和變更頻率，也結合研發團隊的相應工作量，評估需求拆分粒度；更進一步，通過追蹤需求對應的業務目標達成情況，評估需求質量。

 

和訊網希望依托數據，引導作為收入中心（業務部門）與成本中心（技術部門）之間的產品經理更加關注和平衡投入產出比。

 

在推廣思路上，則沿用了研發數字化的“逐步推進”原則，前期不對產品部門做任何要求，而是先建立數據留存機制和習慣，加強產品部門對量化反饋的感知與共識。這也一定程度上保障了數據的真實性和可用性。

 

通過將產品與研發的效能數據沉淀于同一平臺，和訊網將兩個角色串聯起來，在原先職能型組織基礎上，強調面向價值交付的業務線組織概念，使數字化管理的影響力跨過部門墻向上游延伸。

 

這樣的組織治理強化了一線產研人員對業務價值的感知，使其目標能夠與組織戰略目標保持對齊，邊界更加清晰，是更加強有力的激勵機制。

 

業務全流程數字化，產品開發更精益

和訊網規劃將產品開發、交付、運營的全生命周期納入數字化管理。由 2022 年開始，和訊網對研發流程進行調整，在項目管理系統中填寫業務線戰略目標，需求全部與戰略目標掛鉤，并統計能夠直接帶來業務成效的增值類需求比例，帶動產研全流程直接與戰略目標對齊。

一方面，在全局視角下對各個單點的效能進行更深入的評估，避免局部最優反而對全局優化造成負面影響。

 

另一方面，著眼于端到端的價值交付，避免“效率豎井”，使各產品、項目、部門效能提升能夠與組織級的業務價值、降本增效、客戶滿意度等業務成果關聯起來，用精益思想驅動傳統業務的加速升級。