0
2019年5月16日，美國正式將華為列入“實體清單”，在未獲得美國商務部許可的情況下，所有美國企業禁止向華為供應產品。
禁令發布后不久，來自華為研發的各團隊開始緊鑼密鼓盤點梳理，識別出了當時華為在軟件開發工具組件和單品上的涉美國技術。
很快，研發團隊發現，在這批涉及美國技術的產品和工具里，有的已被美國直接斷供，有的已被停止維保，還有的隨時可能會出現在下一次斷供名單上。如何盡快替換掉受制裁工具，上線自研，實現自主創新，成了當務之急。
“不僅要保障業務連續性不中斷，邊開飛機邊換輪子，還要讓整個軟件開發系統能在華為云上跑起來，實現從底層芯片到上層應用全棧的自主可控。”一位當時的參會專家對雷峰網回憶道。而這一切都要爭分奪秒，在2021年年初完成驗收。
短短一年半的時間就要完成替換，可能實現嗎？這群人為何敢立下如此軍令狀？
上述專家告訴雷峰網，決心和底氣來自于華為此前在軟件自研領域長達十多年的持續投入。早在2011年，華為就開始針對外購軟件，從表層的界面作業流，到下層的數據流，逐步進行自研替換，到2019年時已有不少積累和準備，因此在516禁令發生后，才敢、也才能做出快速替換的承諾。
凡事預則立，不預則廢。事實上，很早之前，華為就將軟件開發工具看作是一項“根技術”。作為連續20年穩居中國軟件百強榜榜首的企業，近10年華為研發費用高達8450億，其中很大一部分都投在了軟件研發上。而這種“重兵投入”背后，離不開華為對中國軟件開發長期以來的行業洞察，以及在此基礎上未雨綢繆、先行起步的自研嘗試。
軟件開發工具到底屬不屬于根技術？據華為云PaaS服務產品部部長徐峰稱，華為內部在這個問題上，此前也曾有過一段時間的爭論。
所謂“根技術”，是指能衍生出并支撐著一個或多個技術簇，并持續為整個技術樹提供滋養的技術。比如操作系統、數據庫、中間件和編程語言等，都是業內熟知的根技術。與這些技術相比，軟件開發工具的“根”屬性似乎并不那么直觀、迫切。
但事實上，如果從軟件生態的角度看就會發現，就算研制出了操作系統，但如果上面沒有繁茂的各類應用、開發工具和開發者社區，操作系統的構建最后也無法真正成功。
鑒于此，華為內部在該問題上很早便取得了一致共識：要想在軟件領域實現整體跨越式發展，不受制于人，軟件開發工具這個根就一定要扎得深、扎得牢。
尤其516禁令事件，更讓華為對此有了切身體會。
“516后，大家深刻體會到了在軟件開發工具上被‘卡脖子’的感覺。”不少華為人對此記憶猶新。
軟件開發工具之于軟件，猶如光刻機之于芯片，都是不可或缺的關鍵生產工具。這一基礎軟件如果受制裁，就如同軟件之根被限制把控，整個軟件產業的生存基礎也會受到沖擊。
有了這個意識后，再回過頭看國內軟件開發工具現狀，會發現情況令人堪憂。
目前，軟件開發工具在海外和國內兩個市場里正在呈現出一種冰火兩重天的局面。一邊是全球尤其歐美市場的如火如荼。
首先是總體市場規模上，據一項國外行業分析報告顯示，2022年，全球軟件開發工具市場規模約為51億美元，預計到2028年將增長至約115億美元，年復合增長率高達14.5%。
其次在份額分布上，北美地區占有市場份額超過50%，歐洲地區緊隨其后，市占率超20%，而中國和其他地區國家加起來市占率不足30%。
再拉近看，以美國為例，在2020年全球操作系統、基礎軟件（含桌面、數據庫、云操作系統、工具軟件等）領域，僅美國一國的業務收入就高達0.81萬億美元，占到全球比例的4/5。而全球頭號玩家微軟，目前在軟件開發工具、生態及其相關衍生品上的營收也早已超過了Windows產品線，支撐起了微軟目前的大部分市值。
但反觀國內，在軟件開發這個千帆競發的賽道里，我國的市占率目前還非常有限。
不僅全球，就算在本土市場里，我國基礎軟件的份額也非常少。據來自中國軟件協會的調研數據顯示，目前國產軟件的國內市場份額僅為5%，國產操作系統的國內市場占有率僅4%，國產化替代空間可謂巨大。
盡管近年來國內也在奮力追趕，從2000年至2020年，中國軟件市場整體規模實現了135倍增長，看似呈現百花齊放的趨勢，但實際上，核心應用少、技術底座難以自主可控，軟件產業整體發展仍然是空中樓閣、無根之木。
尤其在軟件開發工具上，大量軟件企業直接購買美國商用工具，國產軟件工具鏈大量依靠開源技術包裝而成，一旦受到國外制裁，開源技術平臺被禁用，將會直接危及到國內整個軟件產業鏈。
而類似的制裁已然發生。
從2019年至今，已有超過600家中國企業、機構等被列入美國“實體清單”，相關商品和技術的制裁管控，已經成為導致企業生產停滯，威脅生存安全的重大隱患。這讓越來越多的企業意識到，只有將軟件開發工具的自主可控掌握在自己手中，才能保障企業的命脈。
與此同時，近年來現代軟件開發已越來越多采用云上開發模式。在敏感與核心的軟件中，如果使用開源代碼托管平臺如Github、Gitlab等，開發代碼則需要傳遞到美國公司的服務器，數據生產、存儲、傳輸、訪問、使用、銷毀等過程是否安全，都會變得不可控，在極端情況下，相關的敏感數據甚至有可能會被查看和利用，帶來難以想象的未知風險。
形勢不可謂不嚴峻。所以近年來國家也在不斷提升軟件信息產業自主創新的優先級，讓其成為科技強國戰略的重要支撐。
《中華人民共和國科學技術進步法》中就指出：要全面推進產業化、規模化應用，重點突破關鍵軟件，推動軟件產業做大做強，提升關鍵軟件技術創新和供給能力。“推動軟件產業鏈升級，聚力攻堅基礎軟件”也被列為“十四五”軟件和信息技術服務發展規劃中的五大主要任務之首。
政策向好，但國產軟件工具想要崛起突圍，還需要邁過一道道歷史溝壑。
眾所周知，歐美信息化產業起步早，經過幾十年的先行發展，從底層芯片到操作系統、開發工具和各類應用軟件服務，整個數字化生態體系已經“枝繁葉茂”，比如在軟件生產工具方面，美國的Microsoft、GitHub、Java等公司和平臺已十分強大。
這些都讓中國信息產業一出生就處于后發劣勢：對外，不得不在逼仄的競爭空間里，從老牌外商嘴里搶肉吃；對內，由于投入周期長、冷板凳難坐，國產軟件企業長期面臨招人難、盈利難的困境。
所以盡管中國的軟件產業經過多年追趕，已基本構建了相對完整的結構脈絡，但總體仍十分孱弱。如何加速趕上，盡快擺脫卡脖子危機，實現自主可控，成為國內產業各界共同面對的關鍵課題。
據華為云的多位產品經理介紹，在華為多年的發展過程中，也曾陸續引入多種軟件開發工具，逐漸形成了外購軟件、軟件包定制、自研軟件多種工具“混搭”應用的局面。
彼時在快魚吃慢魚的時代，效率就是企業的生命線，“用歐美的磚建中國的長城”，盡快把業務發展起來，是優先選項。但隨著業務體量成長，新設立的產線、新增加的業務場景、持續積累的海量數據、招納的研發人數，以及大規模的跨部門協作場景不斷增多，原有的“混搭”軟件越來越難跟上華為的發展節奏。
以需求管理環節為例。
早期，多種工具并存導致華為內部沒有一個統一的需求管理工具，各個產品線在研發上只能“各自為戰”，面對單個項目內部的小需求時尚可應對，一旦遇上大的產品級、解決方案級需求時，難免就會出現需求傳遞失真、需求管理混亂、協作低效、驗收時間不齊等問題。
與此同時，隨著涉及的跨部門、跨業務協作范圍越來越廣，需求管理也不再止步于信息傳遞，還需要將整個項目的過程數據不斷拉通，如此才能把控總體研發風險。但想要穿透各種型號不一、接口參差的工具將底座打通談何容易，其中涉及的二次開發工作量非常大，成本也高企不下。
再加上，云計算時代的到來讓軟件創新正在迎來顛覆。云計算不僅增強了軟件開發的底層基礎架構、提升了算力，還在云上改變了很多軟件的形態。將軟件開發從之前的單體、低效模式轉變為如今的分布式、高效率、大規模協作的云端開發模式。這對中國軟件產業來說，是一次不可多得的“彎道超車”機會。
針對這些已有的業務痛點和未來的業務發展考慮，從2011年起，華為開始著手對軟件開發工具進行自研替代。
據華為云的產品經理回憶，當時有兩個方案：一個是部分替換，即只改造外購軟件的桌面作業流，不動底層的數據流；另一個是全面替換，將上層界面和下層數據系統全部換成華為自研。兩套方案根據不同業務上線時間的先后和實際需要，分別用在不同的業務上。
仍以需求管理工具為例。2014年，華為開始考慮做一款公司級的需求系統CloudALM。
需求，作為研發鏈條上的第一環節，是產品開發的“發動機”。一個成功產品往往需要花費40%的時間來管理需求，而一個失敗的產品，需求管理脫靶也往往是其失敗的主因。有分析師報告指出，在研發界，需求管理不善導致項目流產的比率高達71%。
而現實中的無數個事故現場也都見證了，準確理解并實現需求是件非常有挑戰的事，產品的最終實現和客戶真實需求間經常存在“南轅北轍”的現象。
因此如何管好需求、打磨出一款高質高效的需求管理工具，就成了華為軟件開發工具自研項目中的一大“重頭戲”。
據華為云產品專家介紹，CloudALM的核心優勢之一是以一套云化系統，代替了此前的一堆繁雜工具，統一的底座便于將不同產品和場景下的研發數據、過程數據進行匯聚、連接、打通，從而能夠支撐起大型的千人、萬人級別的跨部門協作。
“從表面上看它是一個需求系統，但從數據拉通的底座上講，它更是一個關系平臺。”關系平臺就如同大海中的縱橫交錯的航線和指南針，能讓海量的過程數據以及隱藏在背后的質量風險變得一目了然，不至于在問題發生后迷失方向、無從下手。
同時，這套統一工具，也突破了此前需求分段管理的局限，覆蓋到全生命周期，讓預警和干預方式從之前的“哪里出問題修哪里”的打補丁式救火，變成了如今“一切盡在掌握”的全流程服務。
諸如此類的改善還有很多。在2019年前，華為在軟件開發的自研道路上已經上下探索，積累了一系列成熟經驗，穩步前進著，直到516禁令的出現。
516發生后，華為發現不少非自研工具的獲得性上都出了問題。緊急應對下，華為迅速調整了早期的方案一，加快了全自研替代步伐，同時也開始對自研系統進行效率改革和品牌升級。
在需求管理環節，從2019到2020兩年內，華為陸續將包括終端、芯、云、車，以及嵌入式設備等在內的需求管理，進一步承載到一個全新升級的華為云CodeArts Req平臺上。
Req只是華為云上軟件研發工具鏈CodeArts上的一環，CodeArts整個研發產線涉及需求管理、代碼托管、代碼檢查、編譯構建、部署、測試、發布等多個環節，凝聚了華為多年沉淀來的經驗、流程和方法，并且還在不斷迭代。
從2018年開始，華為公司啟動軟件能力提升變革，其中就包括對Req環節的端到端需求追溯的優化。
“以前手提肩扛的時代，不同產線、團隊之間的需求協同主要靠Excel和郵件，做鏈條追溯時需要人工去手動翻閱、整理一個個碎片化文檔，費時費力，效率不高。但有了Req平臺，這一切都大有改觀。”
以電信運營商項目為例。
鑒于電信行業關系到國計民生，運營商每年在與華為等服務廠商簽訂大型合作前，都要對這些廠商的產品開發過程做專項審計，這就要求廠商們能夠提供可供追溯的研發素材，但由于涉及到的數據海量、部門眾多，在Req自動化系統推出前的人力手工時期，該項工作長期被視為繁重不已。
“如果該產品涉及到5個團隊的協作，那么每個團隊通常都要出2個人，一共是10個人來準備材料；如果審計時間是一兩周，那么準備材料大概要一兩個月之久。”
“有了Req平臺后，現在幾乎不用再派專人來準備材料了，只需要花幾分鐘打開系統就能讓客戶直接查看。”這位產品經理告訴雷峰網(公眾號：雷峰網)，底座的自主創新疊加效率的不斷優化，目前Req平臺支持全流程實時查看，能做到雙向、可信、智能的追溯。
近期，華為又將IPD需求管理模板內置進了Req系統，提供IPD系統設備類、IPD獨立軟件類，以及IPD自運營軟件和云服務類3大模板，以腦圖、甘特圖形式對戰略進行逐層分解，確保組織戰略落地，并進一步增強了全方面的追溯以及自定義能力。
事實上，經過多年的自研沉淀，目前CodeArts Req已全面覆蓋華為各類業務研發，高效支撐華為13萬研發人員的需求協作 、月API調用量超過15億次，累計管理5000多萬需求，正在持續推動著華為內部的高效協作和業務發展。
從CloudALM，到CodeArts Req，需求管理工具的演進只是華為在軟件開發上持續自研、迭代的一個縮影。
過去十多年，華為在自研軟件開發工具上一步步走過了自動化、云化、可視化、效率改革、流程優化等歷程，在把自己的根扎深、扎牢的同時，也在眾多國外品牌工具中，為中國企業提供了一個滿足自主可控需求的新選擇。
軟件工具的自研、落地、成長從來都不是一蹴而就的事，而是一個需要不斷在實際業務中淬煉的過程。談及參與其中的感受時，幾位華為專家都感慨，“說起來云淡風輕，但實際上磨練重重。但也正是這些攻堅克難的點滴積累，才有了華為在軟件工具上的底氣。”
其中，讓他們印象深刻的一個案例是CodeArts Req在華為內部的車BU業務應用。
車BU業務在需求管理上的一大特色是：卷積過程和協作模塊多，復雜度高。
“車BU剛成立時，本部門研發人員眾多，是一個典型的跨部門、大規模協同研發模式。”
據介紹，傳統ICT業務的需求模型是“樹狀”結構，可以一層一層向下分解，較為有序和簡單，但車的需求模型卻是縱橫交錯的“網狀”結構，其需求管理會橫跨網絡、無線、芯片，以及多種終端產品線的協同，若是某一環節出了偏差，有可能導致整個解決方案或產品胎死腹中。
不僅如此，車還面臨著一系列外部認證，其整個需求管理過程需要經過外部審計，尤其車載業務，需要拉通的對象多，要以需求為源頭，將設計、仿真、測試、制造各個環節去打通，每逢審計時整個需求追溯過程非常繁瑣。
鑒于車BU業務的復雜性，為了更好貼合研發，當時項目集齊了華為內部的三方團隊，包括華為云PaaS平臺工具開發團隊、車BU業務團隊，以及裝備工具團隊，眾人經過了多次重點攻關，在原有工具的基礎上結合車企在IPD流程、雙向追溯、會簽基線等環節完成了一系列增強。
“需求管理工具的一大核心特質是能夠承載具體業務、解決企業實際問題，這需要經過豐富實戰場景的打磨。而華為內部豐富的業務產線正是天然的試驗場，能讓自研工具在大量復雜場景里反復淬煉，這是一種天生優勢。”該產品經理補充道。
“很多企業可能難以想象上千人、上萬人的協同開發怎么做，但對華為來說，這類研發已是家常便飯。”
車BU只是CodeArts在華為內部諸多應用案例中的一個。據了解，目前華為集團各產線均已上線了這套自研工具。不僅如此，隨著打磨成熟，CodeArts系列產品也在陸續賦能物流、汽車、油氣等外部行業。
以德邦物流為例。眾所周知，物流是一個軟硬件結合、涉及運、儲、裝、卸、配、信息處理等多個環節的重型行業，對應的需求模式也呈現出一種“既要保障敏捷開發，又非常強調管理精細化”的特征。
在與華為的合作中，德邦提出了十分詳細的全線管理要求，比如將管理的維度細化到每一環節、每一個人的權限，同時由于物流協同過程復雜，又需要將很多項目歸集到一個項目集里，以項目集的方式進行管理……“當時前前后后部門派了十多位工程師駐扎上海德邦現場，用了大概半年時間，幫助客戶實現了需求管理全流程線上化、數據化，在數智融合上邁出了重要一步。”相關專家表示。
在諸如此類的一個個外部落地案例中，來自各行各業客戶的需求也在不斷催生華為CodeArts Req長出更多承載多元化業務場景的新能力。“這是一個雙向進化的過程。”
在不少交流場合，很多與華為關系密切的企業都曾問過類似的問題：“為什么市面上很多需求管理工具在應對一些小場景上還能滿足，但一遇到大規模協作的情況就有些力不從心？華為的研發規模更大，華為是怎么搞定的，能不能讓我們也學一學、用一用？”
類似的詢問讓華為看到了外部市場的需要。于是，華為將自研自用的工具，加上與之配套的一系列專業咨詢服務，以云服務的方式開放給外部其他企業，這也正是如今華為云CodeArts系列產品的推出背景。
據悉，除了業已開放的需求管理工具Req外，接下來華為還將圍繞CodeArts工具鏈陸續開放其他環節的產品和能力。明年上半年，華為將發布基于混合云的版本，支持企業的私有部署，下半年，更多內嵌IPD需求管理能力和行業需求模型的研發工具也將陸續推出。
回想2020年9月的初秋，任正非在訪問北京大學、清華大學、中國科學院等學校時曾表發過一篇題為《向上捅破天，向下扎到根》的演講。
在向下扎根方面他表示，中國的經濟總量這么大，這么大的一棵樹，根不強是不行的，不扎到根，樹是不穩的，萬一刮臺風呢？我們擰開水龍頭就出水的短、平、快的經濟發展模式是不可持續的。
這種理念下，近年來，華為在軟件開發工具上去美國化的深度、廣度都在不斷擴大。
從硬件（X86->ARM）、到操作系統（Linux/Windows->歐拉）、到數據庫（Oracle->GaussDB）、中間件，再到應用軟件，面對幾百個組件的替換和千萬行代碼測試驗證的工程量，華為在內部平穩堅定地推進著全棧自研替換。
如今CodeArts系列產品的推出，也讓華為打響了能力外溢的第一槍，讓30多年在研發上走過的路、看過的風景、學到的經驗，不再只是一家公司的資產，而是能分享、服務給其他企業，成為支撐中國軟件底座和數字化轉型的有益實踐。雷峰網雷峰網
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
