2011年，马克·安德列森(Marc Andreessen)写了一篇文章，预言“软件吞噬世界”。观念主要有两个：第一，许多传统业务正在被软件公司所取代；第二，一切其他公司都发现，他们所提供的价值越来越多地来自软件系统。

在安德森撰写这篇文章时，市值最大的10家公司中，没有一家是从事软件驱动业务的。往常，10家最大的公司中有6家主要由软件驱动，而其他4家也曾经准备好了转型。

Stack Overflow和LinkedIn列出非技术公司的软件工程招聘广告超越了科技行业自身。这是经济开展中的一个严重转变，标明公司正在增强他们的软件工程理论。

会计和软件，哪一个对公司更重要？本文没有答案。但是如今许多不以为本人是软件公司的公司也开端发现：软件系统是他们运营的一个关键组成局部。

假如CEO和各级管理人员不理解软件，那么他们将是可有可无的。这要么会限制他们的职业开展，要么会对公司业绩产生负面影响。不论怎样，不理解软件都必定要失败。(据Gartner预测，到2020年，有50%的首席信息官(CIO)将被取代，由于他们没有革新公司的才能。)

本文列出了管理者应该晓得的10个常识：

1、软件不是魔术

2、软件永远不会“完成”

3、软件开发是团队作战，没有人能做一切事情

4、设计不是外观，而是工作原理

5、平安是每个人的义务

6、feature大小并不能预测开发时间

7、巨大来自于成千上万的小进步

8、技术债很厌恶，但不可防止

9、软件不会本人运转（软件需求运维）

10、复杂的系统需求DevOps才干良好运转

01

软件不是魔术

软件不是魔术。固然它看起来像魔术，或者是魔法，但它不是魔法。每一个元素都是由人设计的，都有其数学根底，或者是能够用人类言语解释的过程。

与魔术不同，软件不是凭空变出来的。它需求设计、构建和维护。就像房子有多种系统一同工作(地基、构造、管道、房间、家具等等)那样，软件系统也需求许多层和子系统来创立整个系统。它能够设计得很好，也能够设计得很差，而且快速的设计很少能耐久。

假如人们不能用言语来描绘它会做什么（包括想要的结果和如何完成），那么计算机也无法做到。“how”被称为算法，这并不神奇。

机器学习和其别人工智能技术也并不神奇。机器学习是基于数据的预测，而不是显式的规则或指令。它普通是用线性代数来做的。假如有100万张已知的香蕉照片和100万张没有香蕉的照片，一个锻炼有素的机器学习系统看一张新照片，会依据它从之前的照片中学到的学问通知你它看起来像第一组还是第二组，这不是魔术。运用机器学习依据过去的招聘决议对简历停止排序，即便没有任何成心的成见，也可能会放大经历主义的招聘历史。

02

软件永远不会“完成”

软件永远不会“完成”，软件是一个迭代的过程，在其生命周期中包含许多修订和更新。我们的工作是发明一个能认识到这一点的环境。

同样，我们历来没有希冀市场营销和客户获取是“完成的”，它们也是迭代过程。在每个迭代中，随着我们不时地为业务托付价值，我们也不时地学习和生长。即便曾经做了一些胜利的发布，我们历来没有打算“中止”做这些事情。

假如软件能够在一个版本中完成就好了，但这不是理想。需求文档充溢了含糊性，软件的第一个版本充溢了“哦，那是我写的，但不是我的意义”的场景。最好的软件能激起新的想法和功用需求，看到新的销售管理系统愈加高效，就会激起出更高的效率。世界在变化，竞争对手提供了新的功用，人们就有了新的想法。另外，总是有一些bug需求修复：可能是在代码中，也可能是在构建代码的底层软件框架和系统中。某些软件可能是圆满的，但能够确信的是，随着时间的推移，人们会发现它所构建的平台存在各种破绽。

我们的工作就是让一个组织可以认识到这一点。

认识到这一点的办法是树立一个有自信心定期发布新版本的组织。当完整自动化测试和其他工程标准就位时，我们就树立了自信心。这种自信心发明了一种才能，能够防止过长的发布周期，而是每季度、每月以至每周发布高质量的软件。特定的频率并不重要，但是自信心很重要，自信可以带来更快的创新。

03

软件开发是团队作战，没有人能做一切事情

软件开发是团队作战，开发人员既不是产品经理，也不是UX(用户体验)设计师，也不是质量工程师、剖析师、平安专家、技术作家或运营工程师。组织需求一切角色。

没有哪个管理者会倡议每个销售（sale）人员都做营销（marketing）及PR，否则就辞退销售团队（由于营销人员理解产品，也能做销售）。营销和销售是相关的，但又是不同的。因而，两者之间存在着分工。

同样，开发团队需求独立的人员来搜集需求、质量保证和测试、代码编写等等。

一个开发人员能够“做一切事情”的神话，称为“全栈开发人员”或“10x工程师”，这普通只存在于小公司。是的，一个十分小的公司可能一个人同时做营销和销售，但你可能不会参加这样的小公司。

不要用本人的兴味去应战他人吃饭的专业。一个小孩“擅长Facebook”并不意味着他或她会成为下一个扎克伯格；一个小孩对工程学很感兴味并不意味着他或她能够可以运用微积分；一个小孩可以本人做了一个网站并不意味着这个网站每小时能够处置数十亿的金融买卖。

04

设计不是外观，而是工作原理

史蒂夫·乔布斯有句名言：”设计不只是表面和觉得。设计就是工作原理。“ UX设计师不会坐下来决议菜单的颜色，或者决议按钮是圆形还是方形，他们决议工作流和交互是什么。

用户会看到一个有三个选项的屏幕，还是一个屏幕只显现一个选项？这个设计决议需求心理学、对用户的同理心，以及测试、测试、再测试。

UX设计的最大应战之一是，一旦你熟习了系统，就失去了预测新用户的才能。设计该系统的人在预测新用户的需求时将自动被取消资历。UX可能很漂亮、文雅，能够与一件艺术品相媲美，但是请UX设计师将背景更改为帆船的图片是没有协助的。

我们的工作是信任测试数据而不是客观臆测，创立一个环境，在产品发布之前方案停止屡次修订，并希冀在产品发布之后停止进一步的改良。不要将UX设计人员与图形设计人员混杂。让UX计师设计公司节日贺卡和让技术作家写公司通讯是一样的失礼行为，这些是不同的技艺。

05

平安是每个人的义务

不论知不晓得，无论愿不愿意，我们都是从事平安行业的。一切软件都有平安需求和潜在的平安破绽。开发软件所触及的系统也有平安需求和破绽。固然防火墙和入侵检测等平安的根底设备组件是必要的，但它们还不够：还必需运用内置的平安控制来设计、完成和维护软件平台。平安既是好的技术，也是好的流程。

假如以为我们不是被攻击的目的，那就错了。一切的计算机系统都是被攻击的目的，由于攻击不只是为了其中的信息，而仅仅是它是一台计算机这样的一个事实。例如，一个没有价值信息的系统是网络攻击目的，由于它能够被用来转发对其他计算机的攻击，或发掘比特币，或存储别人的盗版视频。

平安不是翻开/关闭这样按钮，有许多灰色地带。平安性最好从一开端思索。事后的亡羊补牢是昂贵的，而且常常是无效的。我们不会先造一艘船，然后再“添加”一种让它漂浮的功用。同样，也无法先构建一个系统，然后按下“具有平安性”按钮就平安了。

平安是关于风险和对风险的容忍度。对两个节点之间的通讯停止加密并不能保证它的平安性，但它进步了平安性，只要超级算力才有可能破解密码。在一个范畴降低风险对其他范畴没有协助。维护网络并不能避免物理平安问题。一个人撑开一扇门，其别人就能偷走你的备份磁带。

正如吉恩·斯帕福德(Gene Spafford)的一句名言：”独一真正平安的系统，是一个关了电、浇铸在混凝土里、由全部武装的警卫扼守在绝缘房间里的系统——即使如此，我还是心存疑虑。“

恪守NIST CSF(国度规范与技术网络平安框架学会)、PCI DSS(支付卡行业数据平安规范)和SOC 2(效劳组织控制报告)等平安规范能够量化风险，假如做得适宜，还能够降低风险。这些规范并不能保证绝对平安，绝对平安是不存在的。更重要的是，它们为如何担任任地应对和报告不可防止的平安破绽提供了指导。老实、直率、公开是良好的倡议。

软件，假如不论它，就像面包一样变得陈旧。我们的工作是均衡平安妄想与理想，并恰当预算时间和资源。

06

feature大小并不能预测开发时间

feature大小(用户感知到的)与创立feature所需的时间完整无关。小feature可能需求几天或几年的时间，大feature(用户感知到的)也可能需求几天或几年的时间。

我们的工作是创立并支持一个软件开发过程，该过程承受这个事实，并且不是拍脑袋评价工程量。工作量评价自身可能需求令人诧异的很长时间。

鼓舞经过沟通来处理工作量评价的问题。工程师可能会给出一个令人诧异的很长时间的工作预算，但是也会提出对需求停止更改，从而大大缩短时间。记住工作量评价要包括测试、培训、部署和不测的假期（例如病假）。

在没有与工程部门协商工作量的状况下，永远不要承诺某个feature。这并不是我们在公司的权利标志，这需求的是一个专业流程，在这个流程中，开发人员的恳求得到认真看待，评价工作量，并按时托付(或出于老实的缘由延期)。

07

巨大来自于成千上万的小进步

巨大来自于在很长一段时间内所做的成千上万，或许是数百万的小进步（变卦）。假如变卦的效果都被丈量是负面的，那么变卦将被回滚。

谷歌也不是一天建成的。谷歌的搜索引擎是数百万个人改良的结果。搜索质量小组每周开会一次，工程师们走上讲台，提出他们的修正倡议。他们展现了在模仿的环境中会有多大的改良，委员会停止争辩并投票表决。几周后，将对丈量结果停止评审，并决议保存或回滚更改。

谷歌搜索是迭代开发打败“数据大爆炸”思想的成功。谁都不可能在一开端做出一个好的搜索引擎。只要在好莱坞电影中，一个聪明的极客才会想出一个惊人的新点子，并且第一次就能圆满地完成它。在理想世界中，一夜成名需求数年的时间。

无论试图完成的目的是一个为客户提供更好效劳的系统，还是一个更高效、错误更少的系统，还是一个运转更顺畅的系统，都是如此。

我们的工作是请求系统的设计可以容易拥抱新的变化，并定义相关的KPI(关键性能指标)，这些KPI能够在更改之前和之前方便地停止度量。最重要的是，必需有一个流程来检查结果，并决议保存或回滚变卦。回滚不应被视为失败或遭到惩罚。从每次回滚中学到的与在每次保存的更改中学到的一样有价值。

托马斯·爱迪生宣称在创造灯泡的过程中测试了1000根灯丝。当一位记者问他：”失败1000次是什么感受？“他答复说：”我没有失败1000次。灯泡是一项有1000个步骤的创造。”

08

技术债很厌恶，但不可防止

技术债务是未来需求做的工作，由于我们如今选择了一个更简单的处理计划，而不是运用一个需求更长时间的更好处理计划。任何合理范围的软件项目都有技术债务。技术债务让一切的进步都变得更慢，越无视它，它就越像滚雪球一样越滚越大。

有金融背景的管理者听到“债务”时，会以为这是一种将来会有报答的投资。技术债务恰恰相反，它是有毒和痛苦的，并且是一个定时炸弹。

1972年，Fram为它的滤油器做了一个电视广告，在广告中，一位汽车机械师解释说，一位顾客为了俭省4美圆而不改换滤油器，后来，这位顾客不得不花200美圆改换一个昂贵的主轴承。汽车机械师总结说：“你能够如今付给我钱，也能够以后付。”

有一个软件项目，其中有一个子系统与供给商通讯。最初系统只与一个供给商通讯，所以十分简单。然后又接了一个，然后另一个。有些功用必需完成三次，每个供给商一次，这是不可持续的。当请求支持第四个供给商时，开发人员表示反对。是的，他们能够在大约一个月的时间里把它移植上去，但是软件架构开端吱吱作响，就像飓风中的老房子一样。这些权宜之计积聚了大量的技术债务。

开发人员的倡议是花两个月的时间重构供给商架构，使其成为一个插件系统。然后，新的供给商能够在一周内而不是一个月内支持接入。

管理者们并不快乐。为什么下一个供给商需求两个多月的时间来支持，而之前的供给商是在一个月内支持的呢?花两个月的时间来归还技术债务将使将来的支持更快，代码更稳定，并使添加新feature更容易。很难权衡确切的益处。

“你能够如今付给我，也能够以后再付给我"。

我们的工作是分期归还技术债务。失控的技术债务降低了添加其他feature的才能，并招致软件系统不稳定。归还技术债务应该与业务目的挂钩，相似于非功用需求。

09

软件不会本人运转（软件需求运维）

固然供给商和开发人员可能会试图通知你不同的状况，但是软件并不会本人运转。任何基于软件的系统（特别是网站和web应用程序）都需求运维人员和运维流程。否则，软件就像一本合上的书，必需有人翻开它，管理它，以及照顾它的需求。

运维比软件开发自身更重要。代码只写一次，但运转可能会是数百万次。因而，粗略地权衡一下，运维的重要性能否要高出几百万倍呢？

我们的工作就是希冀运维成为任何软件系统的一局部。它必需像其他任何项目一样被方案、预算、管理和有效地运转。

运维功用(通常称为非功用需求)对用户是不可见的，除非作为二级需求。数据备份是非功用需求中一个很好的例子。没有用户恳求数据备份，但是，用户的确请求恢复已删除的数据。遗憾的是，没有备份就没有恢复。恢复是功用需求，备份是一种运维（非功用）需求。

让软件效劳易于维护或高效运转的功用需求历来不会被用户提出来。但是，他们的确享用着一个低本钱、高牢靠的系统所带来的益处。客户会分开那些不靠谱的网站，再也不会回来。

持续改良的需求不只包括新功用需求，还应该包括新的非功用性需求。因而，我们的工作不只是为客户提出的功用需求分配资源，还要为运维需求分配资源。在两种互相竞争的需求之间获得均衡是艰难的。

但是，一个胜利的产品是业务需求和运维需求的权衡结果。

10

复杂的系统需求DevOps才干良好运转

复杂的系统最好经过DevOps停止改良。DevOps有很多定义，但是DevOps通常看作是经过快速迭代加速托付价值(feature、bug修复、流程改良等等)。要做到这一点，每个相关人员都必需参与。也就是说，他们必需跨职能团队停止协作。DevOps这个名字来自于移除开发人员和运维(IT)之间的隔膜，这关于完成快速的发布是绝对必要的。但是，优秀的DevOps环境将其扩展到跨一切职能团队的端到端工作。

DevOps被误解为开发人员来做运维。这种“构建它，运转它”的战略是跨职能团队工作（消弭隔膜）的一种办法，但它不是独一的办法。