至少有十五年，中国软件行业里就一直有人说着“没有银弹”，或者是说“发明银弹”。这个“典故”的来源，是国际软件工程专家Brooks在1986年发表的文章《没有银弹》。

   这篇文章说的是什么？希望解决的问题是什么呢？

   纵观“管理学历史”，从1905年到现在，无论是传统还是IT行业；根本上都是希望通过管理来提升“生产率”（1）。即：使用更少的能量，产生出更多的价值。

   在文章的开篇，Brooks就阐明了，对于软件工程，没有“简单易行”的“银弹”——可以使软件的“生产率”有显著的提升。在1995年，他又写了一篇《再论“没有银弹”》，依然是这个观点。

（在中文里，这个词也许比“银弹”更易懂）

   此后多年，世界范围的软件从业者一直在试图发明银弹。国内一些厂商，不约而同地想到了一个解决方案：低代码、无代码的平台。2021年伊始，这股风潮终于热了起来，引起了不少争论。

   我重读了Brooks的这两篇文章，结合自己的经验，谈一下思考。

   软件的根本任务是什么？

    Brooks在文章中阐明了自己的论据——软件工程的根本任务是什么？

   软件的根本任务是构建概念模型——能够解决客户（用户）真实需求的，“映射”在数字环境中的概念模型。次要任务才是用编程语言来开发、实现这个模型。

   而这个根本任务，本质上是不能通过“技术”的发展而提升效率。

   在中国软件行业里，有一个比“银弹”更知名的梗，那就是：这不是我想要的。

   这句话，普遍的场景是——软件厂商的售前天花乱坠，销售大包大揽，客户签约付款；然后，厂商的程序员996了xx月，实施顾问通宵安装调试xx天后，在给客户做上线前的最后演示时，关键客户如此评价。

   故事的结局1：乙方忽悠甲方验收；然后，实施顾问一撤，软件无人问津。

   故事的结局2：甲方不验收，乙方无休无止的改程序。

   我从事软件行业多年后，一直在想这个问题：为什么所谓的“信息化、数字化”项目的失败率那么高？

   看了《没有银弹》之后，感悟到：软件的本质是要建立“概念模型”。如果这个“根本”都错了，那么后续再怎么高手如云，再怎么996，再怎么CMMI、敏捷、持续交付以及Devops等等，都于事无补。

   软件是实现客户需求的一种工具（IT这个词的来源），而不是需求的本身。

   客户的需求一直没有发生本质的变化——抽象的来讲——那就是对于信息的存储、处理与传播。（2）

   这个需求可谓是整个智人科技文明史的主要线索之一；可考证的历史至少已经有4万年。

根本任务难在哪里？

   在国内，我一般是用拿建筑工程，来“对比”软件工程。

   建筑领域的从业者，其学历、收入的平均数以及中位数，都要比软件行业低。但是他们的“交付物”很少出现“不能用”的情况。

   那么软件工程比起建筑工程，到底难在哪里？

   Brooks以及另一个专家Booch等，写过很多文章，讨论了软件概念模型的搭建为什么困难。其中，最主要的根本原因就是——“复杂性”。

   Brooks拿物理学来做“类比”，过去的300年是物理学的黄金时代，物理学家为自然现象搭建了简化的模型；并在模型中忽略了复杂性，取得了瞩目的成功。但是软件工程的本质特点就是复杂性，是不能被忽略的。

   为什么说概念模型是复杂的呢？

   专家们总结了很多，其中最重要的一条是“问题域的复杂”。也就是说，有可能客户自己都不知道需要解决的“问题”是什么；对自己的需求不了解。

   我遇到过一个典型故事：

   “售前小姐”很骄傲地传给了我一堆excel报表，说：这是客户的原表，我好不容易才搞到，你们就按照这个做就行了。

   我看这个所谓的“大表”，有横有纵，数据交织且凌乱。就与售前人员沟通，她只是一再的强调，客户现在的报表就是这样的！客户现在就是这么干的呀！你们不用问，照做就可以了。

   后来，我是借助其他的理由与客户沟通上，旁敲侧击的问道：你们现在的报表很乱，我们是否可以简化一下？

   客户回答：可以呀，我早就想优化了，一直不知道怎么做。

银弹？——低代码/无代码   

   在《没有银弹》里，Brooks给出了几个有前途的“银弹”建议，例如：精炼需求、快速原型、增量开发等；多年以后业界搞出的“需求工程”、“商业分析知识体系”、“敏捷”以及“Devops”等等，也都与之有点“所见略同”。

   他给出了最关键的建议，还是要培养人，尤其是卓越（Great）的设计人员。为此，他在2009年，又专门出了一本书《设计原本》。

    我最近几年的思考——软件的“设计”，更多是一种艺术，而不是技术；需要有天赋，也需要刻意地培养与训练。这一点，可以与建筑业继续类比。

   目前，国内很多厂商推出的低代码（无代码）平台。是否能够达到终极目的——提升“生产率”？这个工具是否能够解决软件工程的“根本问题”。

   从1985年到现在，软件的开发语言可谓是大浪淘沙。但这些专业的语言，都没有解决根本问题，都不是“银弹”。

   低代码/无代码的解题思路是——把构建软件的工具门槛彻底降低，人人都是软件工程师。这项技术，是否成为“银弹”呢？

   软件工程的终极解决方案（银弹），还是卓越的设计（Great Design）。

     目前的软件工程，从“设计”到“构建”，这个期间需要投入大量的工作量。很多的情况是，构建完了，才发现当初的设计有问题。当然，有时候设计也会认为是构建环节出了问题。

   如果做到了“设计”即“构建”，减少了中间环节，的确是可以提升生产率。

   这项技术的发展，如果真的产生了“突破”，可能会引发有两个方面的变化。

   其一：真正拥有、产生、处理信息的客户，会“摆脱”对传统的软件开发组织（码农们）的依赖。类似于：PC以及个人文档处理工具的普及，使得原来专业的“打字员”迅速消失。

   其二：有想法、专业的设计师，可以方便地搭建自己的方案。那么就像现在的“网络文学”或者“零工经济”，软件的消费市场会开辟出一个全新的领域。       

  番外篇——什么是生产率？   

   中国IT行业有著名的996、007，表面上，行业的管理者混淆了“工作时长”与“工作产出”这两个概念；本质上，则是对“生产率”概念的曲解。

   我是做软件度量咨询的，对这个领域的“生产率”稍微有点认识。

   目前，国内很多人对软件“规模”的概念还很模糊；所以对软件的“生产率”以及“工作量”的本质缺乏认识。更不要提“数字化”管理了。

   这是一个有点尴尬的现象，整天在向其他客户忽悠“信息化、数字化”的软件组织，对于自身的“数字化”还懵懵懂懂。

（1）参考陈春花2019年的《协同》

（2）参考吴军2020年的《信息传》

版权声明：

凡本网内容请注明来源：T媒体（http://www.cniteyes.com）”的所有原创作品，版权均属于易信视界（北京）信息科技有限公司所有，未经本网书面授权，不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的，应在授权范围内使用，并按双方协议注明作品来源。违反上述声明者，易信视界（北京）信息科技有限公司将追究其相关法律责任。