比如这几年流行“微服务”的概念，这个技术术语代表的是一种软件架构的风格，有很多的厂家会在自己的方案里面写：我们采用了微服务架构，所以我们这个软件很先进。但是绝大部分的项目里面，甲方没有能力对架构进行验收，他根本没法知道这个软件到底是不是采用了微服务架构。

我觉得这是一个很严重的问题。几年前某外企曾经采购过一家中国软件公司开发的软件，乙方也号称是微服务架构，结果甲方有一位从美国来的架构师在会议现场打开系统源代码来检验，指出乙方并没有采用微服务架构。像这样的技术能力，我国大部分非IT行业的甲方是不具备的，因此就留下了更大的“忽悠”的空间。

在具体的项目开发过程中，还有一些其他的问题，比如说企业间的层层转包，企业内部的层层下发，任务最后可能下发到技术能力有限的一些年轻程序员手中，甚至还可能是根本不具备相应能力的“无证程序员”手中，而经验丰富的程序员大部分都是在忙售前阶段的工作，逐渐远离软件开发第一线。这可能就把一些潜在的性能隐患和安全隐患埋到系统里面，再加上前面我们说的甲方的验收质量把控又没做到位，那么这些隐患可能就一直埋下去，最终在正式使用时爆雷。

观察者网：从这些案例出发，您能否为我们总结一下数字化新基建给传统的项目采购和管理机制带来了哪些新的挑战？

熊节：软件项目的招标一般来说是百万千万这样的规模，相对于建筑工程来说，金额没那么大，但是水很深。刚才我们也提到了一点，数字化新基建的软件项目往往有很大的依赖性和绑定性，一个厂商做了一个系统以后，其他的厂家很难在它的基础上去加强完善。

于是，我们就会看到一个现象：一些厂商的系统价格很便宜，甚至是不要钱，它们去投标政府采购的项目，凭借价格优势中标之后就可以长期拿项目。因为只要它们的系统打进去之后，在这上面需要做增强、扩展的时候，政府没办法找别家公司。

因为政府作为甲方，也没有能力掌握源代码，所以二期、三期工程就必须得找同一家来干，你找其他家干不了。于是很多厂商找到了一种绕开公开招投标的方法：一期工程以很低的价格进入，价格低到可以不用公开招投标，然后在二期三期不断做增强，把真正想做的功能放进去，整个工程的金额变得越来越大。由于厂商很容易在软件里设置技术门槛，后面二期三期工程其他厂家很难接手，往往就会变成定向采购。这种现象确实可能会带来更多的不透明的操作，甚至更多的腐败空间。

新基建 资料图

另外一些挑战就是我刚聊到过的，甲方在技术能力上面的缺失。当然甲方不必是技术专家，传统的基建项目也是这样。但是我们要看到这里面有一个相对性，传统的基建项目里，甲方就算不是专家，他对基建的了解程度也是相当深的。可我们看到不少数字化新基建的软件项目，问题严重到可以说是乙方想怎么做就怎么做，最后乙方很简单地跑一下基本功能就完成验收，性能、压力、安全性等非功能需求和软件架构设计质量、研发过程质量、代码质量等内部质量都无法验收。

这是一个很严重的问题，它会造成大量表面光鲜的“豆腐渣”工程在数字化建设中被验收、被使用，对于我们打牢数字化新基建的基础是非常不利的。