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 多年在研发上走过的路、看过的风景、学到的经验，不再只是一家公司的资产，而是能分享、服务给其他企业，成为支撑中国软件底座和数字化转型的有益实践。
