这篇文章说的是什么？希望解决的问题是什么呢？
纵观“管理学历史”，从1905年到现在，无论是传统还是IT行业；根本上都是希望通过管理来提升“生产率”（1）。即：使用更少的能量，产生出更多的价值。
在文章的开篇，Brooks就阐明了，对于软件工程，没有“简单易行”的“银弹”——可以使软件的“生产率”有显著的提升。在1995年，他又写了一篇《再论“没有银弹”》，依然是这个观点。
中文世界里，这个此可能比“银弹”更好懂
此后多年，世界范围的软件从业者一直在试图发明银弹。国内一些厂商，不约而同地想到了一个解决方案：低代码、无代码的平台。2021年伊始，这股风潮终于热了起来，引起了不少争论。
我重读了Brooks的这两篇文章，结合自己的经验，谈一下思考。
软件的根本任务是什么？
Brooks在文章中阐明了自己的论据——软件工程的根本任务是什么？
软件的根本任务是构建概念模型——能够解决客户（用户）真实需求的，“映射”在数字环境中的概念模型。次要任务才是用编程语言来开发、实现这个模型。
而这个根本任务，本质上是不能通过“技术”的发展而提升效率。
在中国软件行业里，有一个比“银弹”更知名的梗，那就是：这不是我想要的。
这句话，普遍的场景是——软件厂商的售前天花乱坠，销售大包大揽，客户签约付款；然后，厂商的程序员996了xx月，实施顾问通宵安装调试xx天后，在给客户做上线前的最后演示时，关键客户如此评价。
故事的结局1：乙方忽悠甲方验收；然后，实施顾问一撤，软件无人问津。
故事的结局2：甲方不验收，乙方无休无止的改程序。
我从事软件行业多年后，一直在想这个问题：为什么所谓的“信息化、数字化”项目的失败率那么高？
看了《没有银弹》之后，感悟到：软件的本质是要建立“概念模型”。如果这个“根本”都错了，那么后续再怎么高手如云，再怎么996，再怎么CMMI、敏捷、持续交付以及Devops等等，都于事无补。
客户的需求一直没有发生本质的变化——抽象的来讲——那就是对于信息的存储、处理与传播。（2）
这个需求可谓是整个智人科技文明史的主要线索之一；可考证的历史至少已经有4万年。
根本任务难在哪里？
在国内，我一般是用拿建筑工程，来“对比”软件工程。
建筑领域的从业者，其学历、收入的平均数以及中位数，都要比软件行业低。但是他们的“交付物”很少出现“不能用”的情况。
那么软件工程比起建筑工程，到底难在哪里？
Brooks以及另一个专家Booch等，写过很多文章，讨论了软件概念模型的搭建为什么困难。其中，最主要的根本原因就是——“复杂性”。
Brooks拿物理学来做“类比”，过去的300年是物理学的黄金时代，物理学家为自然现象搭建了简化的模型；并在模型中忽略了复杂性，取得了瞩目的成功。但是软件工程的本质特点就是复杂性，是不能被忽略的。
为什么说概念模型是复杂的呢？
专家们总结了很多，其中最重要的一条是“问题域的复杂”。也就是说，有可能客户自己都不知道需要解决的“问题”是什么；对自己的需求不了解。
我遇到过一个典型故事：
“售前小姐”很骄傲地传给了我一堆excel 表，说：这是客户的原表，我好不容易才搞到，你们就按照这个做就行了。
我看这个所谓的“大表”，有横有纵，数据交织且凌乱。就与售前人员沟通，她只是一再的强调，客户现在的 表就是这样的！客户现在就是这么干的呀！你们不用问，照做就可以了。
后来，我是借助其他的理由与客户沟通上，旁敲侧击的问道：你们现在的 表很乱，我们是否可以简化一下？
客户回答：可以呀，我早就想优化了，一直不知道怎么做。
银弹在哪里？——低代码/无代码
在《没有银弹》里，Brooks给出了几个有前途的“银弹”建议，例如：精炼需求、快速原型、增量开发等；多年以后业界搞出的“需求工程”、“商业分析知识体系”、“敏捷”以及“Devops”等等，也都与之有点“所见略同”。
他给出了最关键的建议，还是要培养人，尤其是卓越（Great）的设计人员。为此，他在2009年，又专门出了一本书《设计原本》。
我最近几年的思考——软件的“设计”，更多是一种艺术，而不是技术；需要有天赋，也需要刻意地培养与训练。这一点，可以与建筑业继续类比。
目前，国内很多厂商推出的低代码（无代码）平台。是否能够达到终极目的——提升“生产率”？这个工具是否能够解决软件工程的“根本问题”。
从1985年到现在，软件的开发语言可谓是大浪淘沙。但这些专业的语言，都没有解决根本问题，都不是“银弹”。
低代码/无代码的解题思路是——把构建软件的工具门槛彻底降低，人人都是软件工程师。这项技术，是否成为“银弹”呢？
软件工程的终极解决方案（银弹），还是卓越的设计（Great Design）。
目前的软件工程，从“设计”到“构建”，这个期间需要投入大量的工作量。很多的情况是，构建完了，才发现当初的设计有问题。当然，有时候设计也会认为是构建环节出了问题。
如果做到了“设计”即“构建”，减少了中间环节，的确是可以提升生产率。
这项技术的发展，如果真的产生了“突破”，可能会引发有两个方面的变化。
其一：真正拥有、产生、处理信息的客户，会“摆脱”对传统的软件开发组织（码农们）的依赖。类似于：PC以及个人文档处理工具的普及，使得原来专业的“打字员”迅速消失。
其二：有想法、专业的设计师，可以方便地搭建自己的方案。那么就像现在的“ 络文学”或者“零工经济”，软件的消费市场会开辟出一个全新的领域。
番外篇——什么是生产率？
中国IT行业有著名的996、007，表面上，行业的管理者混淆了“工作时长”与“工作产出”这两个概念；本质上，则是对“生产率”概念的曲解。
我是做软件度量咨询的，对这个领域的“生产率”稍微有点认识。
目前，国内很多人对软件“规模”的概念还很模糊；所以对软件的“生产率”以及“工作量”的本质缺乏认 识。更不要提“数字化”管理了。
这是一个有点尴尬的现象，整天在向其他客户忽悠“信息化、数字化”的软件组织，对于自身的“数字化”还懵懵懂懂。
（1）参考陈春花2019年的《协同》
（2）参考吴军2020年的《信息传》
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！