核心觀點
- 單點工具的串聯無法有效解決研效痛點問題，企業需要通過一體化協同平臺提高端到端價值流動效率。
- 一體化協同平臺的價值是軟件工程理念最大化落地、數字化研發管理、沉浸式研發體驗。
- 一體化協同平臺集成需要評估閉環效率槓桿，確定集成邊界和集成深度。
- BizOps 和 FinOps 的出現，代表一體化協同趨勢正在迴歸“生產本質”，創造價值。
一體化協同平臺概述
“妥協式”研效治理
目前，越來越多的企業選擇通過數字化轉型應對市場的不確定性。軟件作爲數字化的直接載體，軟件研發效能治理（簡稱爲研效治理）成爲企業數字化轉型的關鍵，企業期望通過引進優秀的研效文化、方法論、技術，重塑組織職能邊界，優化分工效率；通過創新軟件研發流程，面向“價值”協同；通過引進自動化工具鏈，優化價值流轉效率。
然而，市場競爭是殘酷的，軟件研效治理也一直在進行，開展新的軟件研效治理不得不向“業務連續性”和“IT 固有資產妥協”，研效治理變爲“妥協式”研效治理，落地效果大打折扣，如圖 10.7.1 所示。
業務連續性妥協
大多數企業都缺乏漸進式研效治理的經驗，如何小規模試點，從邊緣業務向核心業務推進，是擺在企業面前的難題。爲了保障業務的連續性，不對現有組織結構和業務流程造成影響，在軟件研效治理的過程中，往往會犧牲“組織變革”和“流程創新”。
圖 10.7.1 “妥協式”研發效能治理
IT 固有資產妥協
研效治理對企業來說是貫穿“整個生命週期”的使命，爲了保障自動化需求，需要購買和維護大量的自動化工具。在新一輪研效治理中，爲了不造成IT固有資產的浪費，企業常常選擇補齊面向職能單點的自動化工具，提升單一職能的工作效率。如圖 10.7.2 所示，企業已經存在客戶管理、項目協同、代碼倉庫等工具，痛點在代碼的集成和應用發佈上，考慮到已經發生的工具採購成本，企業通過引入 Jenkins 和 ArgoCD 提高 CI/CD 單點效率，這種情況即爲 IT 固有資產妥協。
圖 10.7.2 IT 固有資產妥協
“妥協式”研效治理的痛點
“妥協式”研效治理僅引入新單點工具，通過自動化手段提高單一職能工作效率，而單點工具之間的串聯大多是通過 Webhook 機制在 backend 級別打通的，而賬號、權限、交互沒有被打通，如圖 10.7.3 所示。基於這個客觀事實，單點工具在研效治理中存在職能內工具使用不標準、跨職能協同效率低、跨工具切換成本高和維護成本高等痛點，如圖 10.7.4 所示。
圖 10.7.3 單點工具
職能內工具使用不標準
單點工具解決單一職能內的工作效率問題，不解決單一職能內標準化作業問題，如果工具不能被標準化使用，則意味着團隊與團隊之間、員工與員工之間存在使用效率和交付質量的高低問題。
圖 10.7.4 單點工具痛點
跨職能協同效率低
單點工具之間的信息傳遞是不標準的，但跨職能之間的協同依賴於上游信息傳遞的標準化，比如信息的有效性、完整性、及時性，否則就可能存在需求已確認，但研發人員、測試人員、設計人員、運維人員都不知道，無法開展自己的工作，研發工序與工序之間存在大量的前置等待時間，這些時間最終會變爲工作流中一個又一個的效率“窪地”。
跨工具切換成本高
在研發工作流中，單一職能的生產者需要橫跨多個工序完成工作，比如研發人員需要從項目協同（Jira）領取需求、代碼倉庫（GitLab）完成編碼、持續集成（Jenkins）查看構建結果、持續部署（ArgoCD）確認發佈物料、發佈之後需更改項目協同（Jira）的需求狀態，完成一個需求需要跨多個工具，切換成本非常高，這使研發人員無法專注於價值創造，單一工具的引入從研發賦能變成了研發“負”能。
維護成本高，管理難度大，無法有效度量
維護成本高：在單點工具自研或採購後，企業需要安排 IT 資源運行和運維，而穩定性的保障工作成本較高。
管理難度大：單點工具之間是有限串聯的，這也就意味着企業需要在不同工具之間維持賬號和權限的一致性，一旦出現不一致，其影響可能是災難性的，比如項目協同工具中不屬於某項目的成員，可以在發佈工具中執行該項目的發佈。
無法有效度量：單一工具的數據是相對完整的，但由於工具使用的不標準、跨職能協同等待時間無法度量、工具切換消耗了大量時間等因素，因此度量失去了參考意義，企業無法有效地洞察效能瓶頸、持續改進研效治理。
組織職能僵化，無法應對軟件複雜性的挑戰（圖 10.7.5）
圖 10.7.5 應用複雜性對軟件工程的挑戰
軟件的微服務化大大增加了運維人員的工作量，如果還只是依靠運維來負責整個軟件的發佈，則運維人員的規模無法匹配軟件微服務的規模，於是軟件發佈這一工序會成爲效率卡點。然而軟件的微服務規模通常和研發人員的規模成正比，如果能重塑研發和運維之間的職能邊界，將軟件發佈左移至研發，則可大大緩解軟件微服務化對發佈的挑戰。
從製造業看生產理念和流程創新
製造業生產方式的演進，如圖 10.7.6 所示。
圖 10.7.6 製造業生產方式的演進
在製造業生產方式的演進歷史中，福特汽車的流水線和豐田汽車的精益生產理論分別代表了流程和生產理念創新，兩者爲提升企業生產效率、改善產品質量、降低製造成本做出了巨大貢獻。相比製造業數百年的歷史，軟件工程的發展還不到 60 年，如今的成熟度還遠遠不及製造業，從福特和豐田的創新帶來的巨大價值看，軟件研發流程重構和麪向價值協同的生產理念同樣非常重要。
基於對“妥協式”研效治理痛點的分析，企業需要的不是單點工具，而是能閉環研發活動的一體化協同平臺。一體化協同的本質是企業面向價值的協同文化統一、優化價值流轉效率的軟件研發流程重構、提升資源效率的自動化工具鏈建設，其中任何一項都是不小的投入。那麼，一體化協同平臺到底能爲企業帶來什麼價值呢？
一體化協同平臺的價值
圖 10.7.7 所示爲一體化協同平臺的整體價值圖。
最大化落地軟件工程認知
“鍋碗瓢盆的拼湊，不會解決做飯的問題”，同樣的，單點工具的串聯也不能解決軟件研效治理的問題。一般企業是先通過對精益、敏捷、DevOps 等卓越工程理念的學習；然後結合對企業研效痛點及內部業務模型、組織模型、應用模型的思考，完成企業組織自上而下的軟件工程認知升級；最後通過工具落地企業對軟件工程的全新認知，包括軟件研發統一管理、端到端的協同方式、質量內建、度量、合規生產、雙態多端治理等問題，這些問題絕不是開源單點工具能夠落地的。很難想象，ArgoCD 面向單一場景的工具會考慮企業的軟件工程認知如何沉澱、如何落地。比如，發佈之後自動修改項目協同的需求狀態、自動歸檔代碼倉庫的發佈分支、修改製品的元數據、記錄發佈信息。
圖 10.7.7 一體化協同平臺的整體價值圖
不同於單點工具，一體化協同平臺的核心價值是最大化落地企業的軟件工程認知，無論是質量內建，還是重構端到端的協同方式，都不會受限於單點工具的能力，並且企業可通過一體化協同平臺產生的全鏈路軟件研發數據，持續升級軟件工程認知，持續改進軟件研發效能。
數字化研效管理
一體化協同平臺需要實現研發流水線的工業化，其特徵是信息化、自動化、標準化、流程化，信息化保障了全鏈路數據的完整性；自動化和標準化拉平了因人而異的效率差異，保證了數據的客觀可信；流程化則抹去了單點工具切換引發的前置等待時間，保障了數據的有效性。這些工業化特徵數據，使企業軟件研發的價值、過程、成本變得可被度量，企業研發管理人員可依據這些度量結果展開數字化研效管理活動。
沉浸式研發體驗
一體化協同平臺通過重構軟件研發流程，實現了統一編排和配套工具鏈的深度整合，研發流水線協助研發人員實現了自動化的上下游協同，使研發人員專注於應用編碼，無須在多個系統之間切換，真正實現了沉浸式研發體驗，提高了研發效率。
舉一個研發上下游協同的例子，在產品經理將某個需求分配給研發人員後，一體化協同平臺會根據需求名稱自動創建特性分支，分支被創建後會自動通知該研發人員，其僅需要本地 checkout 該分支即可開始編碼。代碼一旦提交，持續集成的測試環境流水線會自動觸發執行代碼 clone、構建和運行單元測試、代碼掃描、製品推送、測試環境部署。流水線運行成功後，需求狀態自動修改爲「待測試」，這時平臺會自動通知需求的關注人，測試人員收到通知開始測試工作。整個流程中如果沒有質量門禁不通過或者測試失敗的情況，研發人員僅需要關注應用編碼和代碼提交，真正做到了工具服務於人，而不是人服務於工具。
一體化協同平臺的實現
設計思路
端到端閉環
端到端閉環是指一體化協同平臺重構軟件研發流程，集成軟件交付過程中的主要活動和工具，統一單點工具的賬號和權限，解決研發過程中工具頻繁切換和工具之間信息割裂的問題。爲提高軟件交付端到端流動效率和軟件交付質量，企業需明確集成邊界和集成深度，以及工具分工邊界。
（1）集成邊界和集成深度：評估閉環效率槓桿，確定集成邊界和集成深度。
一體化協同平臺對單點工具的集成並不是越多、越深就越好，需要拉通軟件交付整條鏈路，評估集成對閉環效率高低的影響，確定是否集成和如何集成。如果我們把一次端到端軟件交付當作一次交付閉環的話，則閉環效率槓桿是指集成工具對閉環效率影響的大小。下面以設計工具、CMDB、項目管理爲例，通過對集成效率槓桿高低的分析，分別採用不集成、部分集成和完整集成的方案。
首先是不集成，以設計師常用的設計工具 Figma 爲例，設計活動主要由產品經理、設計師、前端工程師、測試工程師參與，Figma 本身已經爲跨職能場景提供了協同能力，因此設計活動能夠在 Figma 中完成閉環，這時一體化協同平臺無須集成 Figma，因爲集成的核心價值在於完成全鏈路的協同閉環，而現在這個閉環已經實現，任何投入只有成本而沒有收益。因此，一體化協同平臺僅需要在需求中關聯 Figma 的設計稿即可，以保障需求信息的完整性。
接下來是部分集成，以運維人員維護IT資源信息的 CMDB 爲例。在軟件研發過程中，存在大量的機器資源依賴場景，比如持續構建機器資源、代碼掃描機器資源、製品掃描機器資源、自動化測試機器資源、發佈機器資源等。運維人員一般會先在 CMDB 中維護這些資源，比如資源規格、資源業務歸屬、資源應用歸屬、供應商、採購成本等，然後按資源使用權限（業務和應用隔離）交付給對應的研發人員。在這種場景下，由於 CMDB 影響閉環效率的是資源交付活動，因此 CMDB 的集成僅需完成資源交付的集成即可，資源維護的功能還是在 CMDB 中完成。資源交付會通過一體化協同平臺的 OPEN API 和 CMDB 完成集成，提高資源交付效率。
最後是完整集成，以項目管理工具 OmniPlan 爲例。OmniPlan 可以幫助項目管理人員完成任務劃分、里程碑制定、項目排期等工作，在可視化和信息結構化上做得不錯，但是由於 OmniPlan 和研發活動中其他工具之間的割裂，直接降低了閉環效率，比如和代碼倉庫與測試管理工具的割裂，導致研發人員和測試人員不得不通過在多個系統中切換來完成任務狀態修改，這種情況就需要考慮完整集成，提高閉環效率。
（2）工具分工邊界：標準的交給工具，不標準的交給人。
其是指把重複的、標準的活動交給工具，如需求狀態流轉、上下游信息協同、單元測試執行；把非標準的、具有價值創造性的活動交給人，如代碼編寫、任務拆分、測試用例編寫，以最大化價值流動效率和資源轉換效率。要做到這一點，就需要一條工業化研發流水線引擎，其需要串聯軟件研發所有活動及其配套工具，併爲每一個活動設置活動標準執行規範、活動狀態上下游流轉規則、活動上下游信息同步規範，如圖 10.7.8 所示。
圖 10.7.8 工業化流水線
質量內建
豐田的流水線相比福特的一個重要創新，就是加入了質量檢查和快速止損的環節。福特的流水線一旦運行，質量問題只能在最後被發現，造成流水線的良品率較低。而豐田的流水線，加入了質量檢測環節，並配有“安燈”按鈕，一旦流水線上發現質量問題，即可通過“安燈”按鈕中斷生產，修復產品質量後再運行流水線生產，大大提高了良品率。
而在軟件研發流水線中，也需要將代碼掃描、單元測試、接口自動化測試、製品掃描、製品依賴分析等質量檢測能力有機地整合在流水線中，並且將這些質量檢測的結果標準化，再配合質量門禁配置規則實現質量問題的快速攔截，早發現，早修復。
擴展性
平臺的集成是有邊界的，往大了看，研發一體化協同平臺也只是企業數字化轉型中的一環，因此在企業數字化業務場景中，一體化協同平臺會存在大量集成、被集成、定製化的需求。我們可以從 webhook、OPEN API、UIKit 三個維度建設系統的擴展性，以應對擴展性的挑戰，比如不同部門希望有不同的度量大盤，而依靠平臺統一建設會非常緩慢，此時平臺只需要提供統一的UIKit和數據拉取 OPEN API，最後的度量大盤可交由部門內部閉環建設。
可度量
德魯克說：“如果不能度量，就不能有效管理”，可見度量的重要性。基於閉環工作流引擎產生的完整數據，企業可從價值流動分佈、價值流動效率、資源消耗三個維度，對軟件價值交付、過程管理、研發成本進行度量，達到資源優化配置、研效持續治理、持續優化軟件研發成本的目的。
高可用
一體化協同平臺直接影響企業的 SLA 和產品交付效率，如果平臺不穩定，則會對企業的市場造成非常惡劣的影響。比如，金融公司受股市週期影響，一般發版時間都會在週末，週一到週四爲研發時間，週五下午休市後爲集成時間。如果週五平臺的持續集成模塊出現故障，導致無法構建，將會直接影響週末兩天的產品發佈。最惡劣的情況是，線上有故障需要 hotfix，但是平臺停止運轉，這時靠手工幾乎無法快速恢復生產。以持續部署爲例，現在很多企業都是混合雲部署，即一次發佈可能要跨多個雲廠商、可用區和集羣，爲了保障交付的可靠性，中間可能還要執行各種發佈策略，這絕不是靠人工可以完成的動作。那麼，如何保障平臺的 SLA 呢？
首先，建議把 IaaS、PaaS 的穩定性交給雲，專業的“人”做專業的事。
其次，控制軟件複雜性，尤其是微服務的規模和中間件的技術選型。微服務的出現對平臺型產品的演進速度有較大幫助，因爲平臺的功能模塊多，微服務可以幫助模塊獨立演進和獨立交付，但是一旦出現微服務規模爆炸，其本身對架構的挑戰將會非常大，故障排查和發佈物料組織都會非常慢。另外是中間件的選型，筆者曾經看到過一款 B 端軟件的數據存儲方案就有 MariaDB、MySQL、PGSQL、MongoDB、Redis5 種，這些中間件的功能存在大量的重複建設，且最終運行的穩定性缺乏兜底策略，直接影響平臺的穩定性。
最後，建立完整的可觀測性和災備。沒有故障的平臺是不存在的，出現故障快速恢復纔是王道，因此建議除考慮平臺功能外，也需要考慮監控、日誌、告警、調用鏈追蹤等可觀測工具的建設，優化故障排查效率，早發現，早恢復。如果實在不能恢復，則建議爲平臺建設災備能力，如跨雲、跨區準備災備實例，一旦出現問題可以快速切換災備系統，恢復生產。
實現方式
一體化協同平臺的功能全景如圖 10.7.9 所示，提供從項目協同、開發、構建、測試、製品、部署的全流程協同及研發工具支撐。
圖 10.7.9 一體化協同平臺功能全景
目前，搭建一體化協同平臺的主要方式有采購商業方案和自建平臺。這裏以騰訊雲 CODING 的商業方案爲例，從投入產出、回報週期、維護成本等多個維度與自建平臺做差異對比，如圖 10.7.10 所示。
兩個方案的差異非常明顯，相對於自建，商業方案的投入產出比更加清晰可控、回報週期更短、後期維護成本更低。企業在兩個方案之間的選擇本質上是研效治理預算，即在商業方案的“確定性”和自建方案的“不確定性”上進行選擇。
圖 10.7.10 商業方案VS自建方案
商業方案一般都會積累很多企業研效治理的經驗，產品形態更加成熟，一般都會提供 SaaS 和私有化交付兩種方式。企業可根據自身需求進行交付方式選擇，如無數據隔離和行業合規強制要求，建議選擇 SaaS，其交付週期更短，後續維護成本更低。另外，商業方案也可以對企業的特殊場景提供定製化服務。對於企業而言，標準需求通過標準功能匹配，非標準需求通過定製需求匹配，最終投入產出比“確定性”是比較高的，且交付週期更短，維護成本更低。對於 SaaS 形態的交付，企業幾乎沒有維護成本。
而自建方案受限於企業的研效認知和團隊成熟度，企業需經歷一個較長的心智爬坡和試錯週期，才能找到正確的研效治理路徑，資源投入和試錯成本都比較高，投入產出比的“不確定性”也較高，短時間內無法預估一體化協同平臺生產可用的時間。筆者曾經見過企業投入 100 多人的團隊自研一體化平臺，每年的投入在 1 億元以上，而受疫情影響，核心業務收縮，平臺建設叫停，期間高昂的投入沒有產生任何收益。在頭部公司都在講“聚焦”的時代，如果把這些預算投入到核心業務上，則更能幫助企業提高市場的競爭力。
最後，如果企業的研效治理需求大部分可通過商業方案匹配，建議選擇商業化方案，其投入產出比會更加“確定”；如果需求匹配度不高，且企業有充足的研效治理預算，對研效治理的失敗有足夠的包容預期，也可以嘗試自建。
一體化協同平臺發展方向
近兩年，BizOps 和 FinOps 的出現代表一體化協同平臺正在從關注軟件研發內部的流程化、自動化、標準化，向打通業務和優化雲成本方向發展。如果從經濟學“生產”的定義來看，一體化協同正在從軟件研發內部（生產過程），向整合市場需求及生產要素的方向發展。可以說，一體化協同平臺的發展趨勢正在迴歸“生產本質”，即生產創造價值。
BizOps
一體化協同平臺通過打破“組織牆”和“工具牆”，使軟件研發變得高效有序，但高效並不解決有效的問題，企業期望能將軟件研發和組織戰略、市場需求、用戶反饋打通，使軟件研發不僅高效而且有效。
2020 年，BizOps 宣言提出了業務驅動研發、研發價值數字化、數字化驅動業務增長的核心理念，打破了業務與軟件研發之間的隔離，使軟件研發過程中的業務價值流動變得清晰透明。企業可以通過洞察業務價值流動速率和業務價值流動分佈，提高戰略業務的資源投入，降低無效業務的資源投入，實現資源優化配置；通過研發價值的數字化，評估軟件研發對業務價值的貢獻，比如業務策劃的“拉新”活動上線後，通過運營系統和一體化協同系統的打通，企業可根據新增用戶的規模變化，直觀評估軟件研發對業務的貢獻，軟件研發人員的價值舉證也將變得簡單可信；通過業務和軟件研發的全流程數字化，企業提高了業務全流程“生產數字”的能力，再配合大數據及人工智能技術，提高“消費數字”的能力，最終實現數字驅動業務增長和數字驅動軟件研發效能升級的目的。
FinOps
今天，雲計算的趨勢已勢不可擋。Gartner 的調研報告顯示，2022 年年底，全球企業的雲計算支出將約爲 3300 億美金，但受限於企業對雲計算本身的認知及自身應用模型的特徵，大量企業存在雲計算預算超支和資源利用率嚴重不足的情況。
FinOps 打通軟件研發、財務和業務，使企業的雲計算成本分佈變得清晰透明，並可藉助軟件線上運行歷史數據，自動預測負載波峯和波谷，實現雲計算資源的彈性擴縮容，將雲計算使用方式從“按使用量付費”變爲“按業務需求量付費”，優化企業雲計算成本。
2021 年，騰訊雲推出的雲原生成本管理產品“成本大師”正是 FinOps 的典型代表。“成本大師”從成本洞察、成本優化、成本運營三個層面來協助企業做更好的成本管理，具有全鏈路的成本優化能力，能夠精確、智能地進行成本洞察，一分鐘發現資源浪費並提供 8 種彈性策略組合，滿足任意場景的彈性需求。其核心能力 qGPU 是強隔離的 GPU 虛擬化技術，該技術在業內首次實現了 GPU 算力、顯存和故障的強隔離，支持算力精細切分共享和多優先級混部，GPU 利用率最高可提升 230%。
作者：吳海黎
本文章節選自 QECon 出品《軟件研發效能權威指南》一書，《一體化協同平臺》章節。
