作者 | 齊淩遠
1
業務背景
和訊網是一家成立于 1996 年，集資訊、金融資料工具、知識社群等功能于一體的财經服務網站。作為一家核心業務較平穩且傳統的企業，和訊網的研發一直處于足夠支援業務需求的狀态。
在數字化趨勢下，和訊網研發團隊看到了傳統業務轉型及加速的需求，而研發團隊高效高質的傳遞能力，正是業務轉型、快速響應市場需求變化的基石。
“我們的思考應該基于怎麼做是對的、是有利于将來發展的；而不是自我設限，隻着眼于當下能做什麼。”基于這樣的理念，和訊網研發團隊開啟了研發數字化轉型之路，并以此為支點撬動了組織的業務數字化轉型。
本文将介紹和訊網自 2019 年至今的數字化實踐。持續的探索和學習也帶來了成果：以 2021 年為例，效率方面，各部門人均生産率同比提升 194%，五個部門周人均生産率高于行業上四分位（前 25%），産能穩定性同比提升 36%；品質方面，阻塞、嚴重問題類型實作清零。
▲代碼當量名額來自思碼逸深度代碼分析系統
2
效能挑戰
2019 年和訊開始推行研發數字化管理體系的建設之時，面臨内外部多重效能挑戰：
管理與改進缺乏量化抓手：難以從軟體研發過程及成果中沉澱資料，導緻研發團隊能力與産出效能無法被數字化評估，管理與改進實質上依賴管理者的主觀判斷
人才資源相對薄弱：與網際網路企業相比，研發團隊的技術能力存在差距，展現在産出效率、品質、抗壓能力、進取動力等方面。
研發内部工作流待改善：産品發版前的趕工現象仍相當常見，一旦研發環節用時超過預期，測試人員就很被動，大量等待造成了瓶頸和浪費；測試不通過打回版本時，往往已接近發版，大機率造成延期。
受限于上遊産品團隊：研發團隊所創造的業務價值受限上遊需求數量與品質不足，造成研發進取動力下降。
3
前期基礎建設
研發數字化工作從 DevOps 建設開始。
和訊團隊首先将不同職能的責任解耦，明确定義研發、測試、運維三者的邊界，使測試承擔起全局的品質控制工作。
其次，搭建起包含 SonarQube、Git、Jenkins、TAPD、Cat、Yapi，Zabbix 等工具的 DevOps 工具鍊，借助工具自動執行規範，同時保障研發過程資料的留存。
4
度量效能，以量化管理守住下限
為了客觀回顧研發過程及成果，和訊團隊引入了思碼逸研發效能分析平台，對研發效能進行度量。
思碼逸平台能夠從代碼庫中提取量化名額，從組織、團隊、項目、個人不同層級，提供開發效率、軟體工程品質、組織人才發展等多元度洞見，使研發管理不再處于黑盒狀态。
建立研發效能度量體系
微軟 Velocity Lab 這篇講解 SPACE 生産力度量架構的論文中提到，如果不顧業務階段、團隊特征等上下文，一刀切地使用單一名額，甚至進行橫向對比，就落入了過度簡化的陷阱。不僅會給團隊帶來錯誤信号，引發質疑，更可能誤導一線開發者造資料搞面子工程，效果适得其反。
效能包含了研發工作的多個次元，其度量并不存在銀彈。度量本身已經是對軟體研發這一複雜系統工程的抽象，必然存在片面性。是以需要通過精細設計，來避免系統性的誤差和盲區。
和訊網引入了效能分析工具後，初步建立起了度量體系，便于研發團隊基于自身情況靈活標明關鍵名額：
傳遞效率
在傳遞效率方面，基于代碼分析能力，代碼當量、代碼影響力等創新效率名額與需求傳遞周期、需求傳遞數量、按期傳遞率等常見名額形成互補，幫助團隊從資源效率 + 流動效率兩個視角進行度量複盤。除了産能名額以外，産出穩定性、貢獻分布、工時投入、工作飽和度等資料也幫助團隊更全面地了解效率表現。
相比代碼行數等名額，代碼當量能夠有效統計代碼所包含的邏輯工作量，排除代碼風格、換行習慣、注釋、格式化操作等因素幹擾。
傳遞品質
在傳遞品質方面，函數複雜度、子產品性、代碼複用度、測試覆寫度、注釋覆寫度、代碼問題積壓等側重軟體工程品質的名額，能夠作為測試環節品質名額的補充，引導開發人員主動分擔品質優化工作，不僅能在開發階段就避免一大部分基礎錯誤，也能提升代碼的可讀性與可維護性，避免技術債堆積。
傳遞價值
在傳遞價值方面，首先通過投入工時與代碼當量 / 需求傳遞數量的交叉分析，量化研發環節的投入産出，合理調配研發人力資源；其次，通過将産品團隊與需求環節納入量化考核，需求與業務戰略目标直接挂鈎，帶動産研與戰略對齊，這部分實踐在後文還會提及。
傳遞成本與傳遞能力的度量模型還在持續細化與推行落地中。
由點及面逐漸推進，尋求團隊共識
考慮到量化管理是由研發管理者引進，而勢必對團隊原有思維和行為習慣帶來沖擊，研發效能度量不能一蹴而就。和訊從流程、規範、方法改善起步，不斷争取團隊共識，培養團隊使用數字化度量名額進行複盤的習慣。
第一階段 選取關鍵試點，建立感覺
對項目效率與品質進行度量回報，建立團隊對量化回報的感覺。
首先在表現較優的部門進行試點，因為數字化度量排除了人際關系等因素，從客觀上佐證其優秀，這些部門的心态會更加開放。
要求研發團隊先導入活躍項目。這些項目的關注度和更新頻率相對較高，也有發版壓力，是以效能優先級較高，研發團隊也有動力主動去做分析。由于這些項目本身品質問題較少，人手也較充足，軟體工程品質将被納入研發環節傳遞品質的名額中，受到硬性要求。
第二階段 面向場景建立模型，尋求共識
基于自身情況，設計不同名額權重，建立起面向項目、團隊及個人的效能度量模型，洞察研發效能問題并針對性改進，使量化管理的效果在團隊内獲得認同。
在工作量度量的激勵下，團隊自發導入低活躍度項目。這些項目的問題積壓較多且時間較長，優化成本高，不對這些項目的工程品質做硬性要求。
客觀資料提高了研發流程與成果的可見性，不僅向一線研發團隊驗證了研發管理更新帶來的提升，也向非技術部門提供了解研發動向的視窗，為數字化管理的繼續推進争取到多方的支援。
強化激勵，提高主觀能動性
考慮到自身人才資源較薄弱，技術能力、工程實踐與一線網際網路企業的研發團隊存在差距，和訊網研發團隊決定将效能度量納入考核與排行，強化激勵效果，縮短獎勵周期，提高研發團隊主觀能動性。目的是為了守住下限，減少由主觀因素引起的低效能問題。
第三階段 引入良性競争，用資料驅動提升
基于自身需求，和訊網将度量納入考核與排行，逐漸引入良性競争機制，強化量化名額對研發團隊的激勵效果。
随着公司内部對數字化管理的接納度提高，逐漸提升量化名額所占考核比重。2020 年年中，量化名額占和訊網研發部門考核比重為 30%，年末提升至 50%，部門級與個人級的年度評優則完全依照量化考核。
在量化名額中，基于代碼分析的産能與效率名額占比 30%，軟體工程品質名額占比 20%；研發過程型名額占比 50%。
應用到考核排行，就難免收到對量化模型可信度的質疑。和訊網團隊的做法是保證模型的公開透明，廣泛征求回報與建議，達成共識以後不輕易改動。即使出現有争議的案例，則共同讨論模型有無需要查缺補漏之處，而不做特例調整。
激勵帶來了良性競争。研發團隊不僅向内看自身效能變化趨勢，也向外看和近似業務性質、近似項目階段的其他團隊的橫向對比。直覺對比打破了部門間的壁壘，推動部門間自發交流、學習優秀研發實踐，使知識能夠沉澱下來，并在組織内高效流轉。
承認管理手段的客觀局限
自上而下的量化管理并設定考核目标，是為了守住下限。那麼是否可以繼續使用管理手段，不斷提高要求，達到提升效能的目标呢？
和訊網的答案是否定的。
前面也提到，守住下限是為了減少由主觀因素引起的低效能問題，但仍有很大一部分低效能問題是由系統性的客觀因素引起的，管理手段與制度無法解決這部分問題。如果不能意識到管理手段存在客觀局限，無限制地要求以主觀能動性提升效能，實質上就是“内卷”，即使以開發者的超負荷工作取得了一時提效成果，也是不可持續的。量化管理不應濫用而淪為“卡裡斯馬型組織”的加持。
在和訊網的實踐中，以産能名額為例，将行業基線的上四分位線（前 25%）設定為考核滿分标準。在組織的平均生産率達到行業上四分位線後，CTO 角色不再密切關注這一名額，使其作為日常管理機制繼續運作；而個人開發者生産率達到這一标準後，也不再有額外激勵。
更進一步的提升，需要将效能問題層層拆解，洞察根因，将責任與權限分發到研發團隊，以日常的流程體系、軟體工具、組織治理、人才培養機制、工程師文化等方面的改進，開啟研發提效的第二曲線。
5
層層拆解追問根因，在日常中落實工程改進
三種分析方法，定位效能改進關鍵環節
在研發效能的相關讨論中，經常能看到著名的豐田生産方式創始人大野耐一的這句話：那些不懂資料的人是糟糕的，而最最糟糕的人是那些隻看資料的人。度量不能停留在資料，重要的是從資料裡洞察問題并指導改進。
以下是三種常用的分析方法：
趨勢分析
展現度量名額随時間推移的變化趨勢，根據走向做出是否需要繼續分析的初步結論。
如果已經采取措施，可用來驗證改善措施有效性；需要注意這裡未必選擇均值來觀察趨勢走向，80 分位值可能能夠更好地排除異常值，反映普遍情況。
下鑽分析
從宏觀到微觀，從表象到根因逐層排查問題，幫助團隊找到關鍵瓶頸。由于北極星名額往往是一個頂層聚合名額，可能有多種拆分下鑽的路徑。
關聯分析
從曆史資料中辨識相關性，進而尋找效能瓶頸的關鍵因素。此外，關聯分析也有助于避免單一名額的負向牽引作用，洞察效能全局。
度量工具化、常态化，根據業務特征針對性改進
在開發向測試流轉的環節，和訊網要求開發者在提測前，基于自動生成的軟體工程品質報告完成自測；測試部門也将度量結果納入定期高頻的報告中，監督品質控制的全流程。
需要注意的是，度量與改進都有成本，難以面面俱到。是以，建議基于項目階段與業務特性，有側重地選取品質名額。例如：
當項目處于高活躍度的增長期，建議關注重點問題率及代碼複用度，以便及時解決關鍵風險，并預防增長期的風險蔓延
當項目業務邏輯複雜時，建議關注測試覆寫度與子產品性，合理拆分解耦子產品将有助于複雜項目的維護
當項目進入維護或重構階段，建議以遺留代碼的圈複雜度名額作為品質提升的切入點，同時也通過子產品性名額評估架構合理性
人員流動性較大，或需要被其他團隊使用的項目，則需要額外留意代碼的注釋覆寫度
開發人員應在提測前，應掃清本次合并中靜态掃描所發現的阻塞與嚴重級代碼問題，這一規範适用于全部項目，在速度與品質間維持平衡；對于處于平穩維護期的項目，則進一步要求掃清既往的阻塞與嚴重級問題
量化管理，帶動工作流優化
以往，和訊研發團隊需要等待多個業務部門彙總需求後才能開始開發，時間緊張；在發版前幾日批量提測，也給測試環節帶來壓力；來不及完成開發或被測試打回，就隻能延期或砍需求。工作流中大量等待造成浪費，業務方滿意度下降。
和訊網以需求傳遞周期、任務按期完成率與工時投入為抓手，鼓勵研發團隊拆解細化任務，保障任務顆粒度适中、範圍明确。任務拆解減少了子任務間的耦合和依賴，提高了并行度，使工時預估準确性大幅提升至 80% 以上。
在量化管理延伸至上遊的産品部門後（下文會進一步介紹），産品經理為了保障需求能夠快速傳遞，也更有動力對需求進行拆解和及時澄清，使複雜需求更早進入開發環節。
在需求與任務的粒度減小、分批次進入開發後，開發進度更加可控。開發人員在傳遞周期名額的驅動下，更早地将任務流轉到測試階段，給測試環節留下更多時間，測試人員在發版前還有餘裕進行随機測試。小批量送出代碼變更 + 頻繁進行測試與建構，也降低了軟體的品質風險，為團隊進一步建設工程能力，試點持續傳遞打下了基礎。
6
向上遊輸出影響力，撬動業務數字化
串聯産品與研發角色，強調價值傳遞
始于一線的産研協同
許多企業的研發數字化轉型是由業務需求觸發。相比之下，和訊網的情況則有些非典型：由于核心業務較平穩且傳統，研發團隊并未受到來自業務的太多壓力。
相反，在推行研發數字化轉型後，需求數量不足、需求變更頻繁且随意、需求未能帶來業務價值等等，反而成為研發團隊的瓶頸，研發團隊開始推動上遊的效率與品質提升。
這一現象首先在産研一線呈現：研發團隊開始主動向上遊要需求，并希望産品部門盡早澄清需求、避免不必要的變更。除此之外，研發團隊主動承擔了更多測試工作，以主動開啟系統需求、性能優化、技術重構等任務，以填補上遊需求數量的不足。
逐漸推進，将産品部門納入量化管理
在這個背景下，和訊網将産品需求環節也納入量化回報中，對産品經理的行為進行資料留痕，并進行內建、清洗、分析和模組化。
具體來說，在需求環節，不僅關注數量、類型分布和變更頻率，也結合研發團隊的相應工作量，評估需求拆分粒度；更進一步，通過追蹤需求對應的業務目标達成情況，評估需求品質。
和訊網希望依托資料，引導作為收入中心（業務部門）與成本中心（技術部門）之間的産品經理更加關注和平衡投入産出比。
在推廣思路上，則沿用了研發數字化的“逐漸推進”原則，前期不對産品部門做任何要求，而是先建立資料留存機制和習慣，加強産品部門對量化回報的感覺與共識。這也一定程度上保障了資料的真實性和可用性。
通過将産品與研發的效能資料沉澱于同一平台，和訊網将兩個角色串聯起來，在原先職能型組織基礎上，強調面向價值傳遞的業務線組織概念，使數字化管理的影響力跨過部門牆向上遊延伸。
這樣的組織治理強化了一線産研人員對業務價值的感覺，使其目标能夠與組織戰略目标保持對齊，邊界更加清晰，是更加強有力的激勵機制。
業務全流程數字化，産品開發更精益
和訊網規劃将産品開發、傳遞、營運的全生命周期納入數字化管理。由 2022 年開始，和訊網對研發流程進行調整，在項目管理系統中填寫業務線戰略目标，需求全部與戰略目标挂鈎，并統計能夠直接帶來業務成效的增值類需求比例，帶動産研全流程直接與戰略目标對齊。
一方面，在全局視角下對各個單點的效能進行更深入的評估，避免局部最優反而對全局優化造成負面影響。
另一方面，着眼于端到端的價值傳遞，避免“效率豎井”，使各産品、項目、部門效能提升能夠與組織級的業務價值、降本增效、客戶滿意度等業務成果關聯起來，用精益思想驅動傳統業務的加速更新。