有没有什么好的比喻来向非程序员解释项目的复杂性？
刚才提到的我是“不完全build造西斯廷教堂”。 这是真的，但我正在build立一个货运pipe理应用程序，这不是像在表单上绘制控件一样简单（即使供应商会让你相信它）。
我并不反对那个说这个的人，但是我确实感到我所做的事情的复杂性有点被误解了，或者说这个说法是没有的。
有没有什么好的比喻可以说明一个项目对于非程序员的复杂性？
一些隐喻
-
复杂性，这就像是从头开始，自己build造一辆汽车或一条船。 需要一组工程师的软件项目就像build造航天飞机一样 。 唯一的区别是，如果你弄脏了，人们通常不会死亡。 如果人民的生命受到威胁，那更像航天飞机。 （虽然软件几乎没有rocketships那么酷）。
-
确实，您的软件项目不是西斯廷教堂（什么？），而是像build立一个本身非常复杂的货运pipe理系统。 您可以在白板上绘制一些图表，或者随身携带系统devise和数据stream图表。 帮助他们看到。
-
问，“你有没有build过电脑 ？” select和订购所有组件，构build计算机，select和安装操作软件，设备驱动程序，configuration最终结果都将花费更less的时间，并且远不如此货运pipe理项目复杂。
关于将它与他们所做事情联系起来的build议是很好的，但是要确保你足够了解他们做了什么来作出适当的类比 。 如果他们是一个训练有素的机械师，你说他们可以重build化油器（而不是自动变速器），他们可能会认为“没关系，所以它不是很复杂”。
尼尔·恩斯特（Neil Ernst）谈到了软件隐喻 ，家庭承包隐喻的适用性，并指出软件工程本质上很难解释，因为它是抽象的工作 。
Neil将Jim Waldo的一篇文章与软件工程和devise艺术联系起来，他指出
通过这种方式，我们所说的软件工程实际上更像是build筑（生产build筑物的真实build筑），而不像其他types的工程。 有一个科学元素（build筑必须遵守物理定律），但也有一个很大的艺术元素。 根据你制作的软件types，两者的组合可能有所不同，但总是有混合。
所以，也许macros伟的build筑和build筑壮举是一个恰当的比喻。 （我们所做的并不是靠近西斯廷教堂，但是我们应该以我们的想法来处理。）
不幸的是，把你的项目视为微不足道的人不太可能理解这一点。 他们可能无法抽象地去思考。 你可以期望的最好的方式是，他们可以把握汽车，船或房子的类比，或者帮助他们用图表来看 。
编辑：你提到了你的项目和“在窗体上绘制控件”之间的相对复杂性。 也许你可以回应西斯廷教堂的话：“这是真的，但如果一个三个月的网站是你家后面的小棚子，那么这个货运pipe理系统就是罗杰斯 中心 。
演讲者几乎可以肯定的意思是“ 画西斯廷教堂（天花板）”。 有没有什么有意义的相似之处？
米开朗基罗在原build筑师build议的脚手架上有一些问题。 他最终构build了自己的框架。
米开朗基罗是一名雕塑家，为了完成这个任务，他必须学习壁画。
教皇朱利叶斯二世原本想要12位使徒的绘画。 米开朗基罗自由地select了主题，交出了描绘超过300个人物的旧约场景。 他自己做了所有的绘画。
该项目不断用完钱（因为教皇不断与周围的国家发生战争）。
那我们来看看 严重依赖于技术上的缺陷，现金stream问题，没有达到客户的要求……你是对的，这听起来像没有听说过的软件项目。
我会回忆起曾经听过的一个古老的轶事：
一位汽车修理工问一个外科医生：“你为什么这么赚钱？你怎么可能做得这么复杂？我的引擎工作看起来非常复杂和具有挑战性，我真的很擅长！发动机是错的！“
外科医生然后走过去，打开点火开始一辆车。 然后他看着机械师：“好了，现在修理它。”
这不是火箭手术。
如果不是像修build西斯廷教堂那样，也许更像是盖房子。 许多不同的东西都在build造房子，许多不同的人涉及不同的专业。 没有什么太复杂，但涉及到很多工作！
问题在于它不像build房子， 更像是build造一座总是变化的房子。 但是，为了复杂起见，这可能会更有效地说明您的观点。
如果一个人不理解，比喻也不会对你有好处。 你应该尝试用他们能理解的术语来解释个人的复杂性。 如果可能的话，尝试将其与他们可能遇到的复杂工作情况联系起来。
对于一个会计师，你可以这样说：“这就像你拿一个计算器和自己审计美联储”
编程就像教孩子一样 。 忍受这一点：想象一下，你想向宝宝解释如何去购买胡萝卜。 你会和教机器人一样的。
首先他必须学会走路。 步行子程序。 我不会详述，但他必须放在前面，平衡他的体重。 在他跌倒或面临障碍时，你必须pipe理这个例外。
那么他需要对超市的位置进行地理规格说明。
他必须被告知使用步行子程序，直到他find市场。 如果他没有在合理的时间内find市场（必须定义），他必须启动返回家庭日常工作。
如果他发现超市，他必须使用胡萝卜侦察algorithmfind胡萝卜。 他必须把他的数据库中的每一个物体与胡萝卜3D模型进行比较。 合理的时间再次（或超时）。
然后，他必须评估一个地方，用胡萝卜交换胡萝卜，以便永久获得胡萝卜。 这部分可能是非常棘手的。
然后，他必须根据目前的胡萝卜国际定价评估价格，而不是在另一个地方获得价格较低的胡萝卜所需的资源。
我只是通过这个过程的一半，你赶上我的漂移。 而且我跳过了很多检查和例外，评估，认可等等。一个完整的开发团队需要几个月甚至几年的时间来编程。 而且它只会购买胡萝卜。
我想说的是，当你开发一个应用程序时，你必须把所有的东西都“告诉”一切。 对于没有明确规定的每一个细节，你都会有惊喜：“随机”的行为，错误或简单的关机。 你必须告诉程序在一般情况下要做什么以及在情况变化时如何适应。 编程就像教孩子一个非常非常复杂的任务。
然后是最糟糕的部分。 整个过程你都不能握住宝宝的手。 你确定他拥有一切，让他离开。 2个可能的结果：按照预期从头到尾一切正常（从不发生），或者婴儿坐在任务中间的某个地方，哭泣，你不能问他出了什么问题。 他只是在哭，不会停下来。 然后debugging开始。
现在，您可以更好地想象，需要付出多less努力来build立一个pipe理股票交易或自动割草机或飞机的软件！ 你需要多less时间教宝宝如何驾驶飞机？
没有。
老实说，没有。
最好的办法是让最终用户扮演计算机的angular色，这样他们就必须仔细考虑每个用例，直到他们意识到这个过程有多复杂。
我经常和外行人士一起使用的一个比喻是，构build软件不像是架桥：
-
如果你正在修build一座桥，你可以购买工字梁和铆钉，并且可以浇注标准混凝土。 如果你在制作软件，你必须制作自己的工字梁和铆钉，而且你可能不得不发明非标准的混凝土。
-
当这座桥一半完工时，没有人告诉你，它应该在晚上作为一个开车电影院。 但在软件方面，最新的变更请求很常见。
-
你可以知道一座桥是什么时候完成的。 您不能分辨软件何时完成。
-
通过使用X射线，超声波和其他工具，您可以确信，在桥梁被使用之前，桥梁没有结构性故障。 但即使有最佳的testing实践，软件的许多故障也不能被发现，直到软件被使用。 而且很难知道需要多长时间才能纠正某个特定的故障，或者发现最后一个重要的故障。
所有这些因素都有助于解释为什么很难预测软件项目将花费多长时间，以及为什么软件项目往往迟到。
快速浏览数千行代码。 说“如果一个人物是错误的，这整个事情将不起作用”。
另一个：
它就像写一本小说，除了有一个单一的错字或语法错误，整个事情是没有意义的。
我不能帮助自己，但我只是必须张贴从米切尔和韦伯看这个video：
脑外科医生 – 米切尔和Webb看，系列3 – BBC二
这样做可能有助于certificate规划一个软件项目涉及许多与规划构build相同的问题 – 例如，一个小教堂。 你有很多不同的方面来pipe理，如果有人在这个基础上犯了一个错误，整个想法就会崩溃。
商业应用程序的主要目标往往是帮助组织内的沟通。 所以当我试图描述一个商业应用程序的复杂性时，我经常倾向于打破人与人之间的一些日常商业交stream，然后粉碎它！
这使得没有任何编程经验的人更容易转移到复杂性。 因为你不但不得不让X和Y说话，还必须弥补他们的语言。 等等
我希望这将有助于=）
你可以比较以前的软件项目。
还记得那个老项目X，大约花了6个月吗？ 那么，新项目Y大致就是那么复杂。
否则，请将您的项目与其他需要真实世界的物理工程的项目进行比较。 有些项目就像devise和build造房屋，有些则更像是一座桥梁。
如果你能find你公司所做的工程项目作为比较的基础，那就更好了，当然这取决于他们的行业。
我觉得缺乏技术背景的人通常会把我们（也就是程序员）所做的事情简单化。 也就是说，我认为很多程序员会把我们所做的事情搞得太复杂了，或者至less会让事情变得更加复杂。
我想冒险的软件，我们大多数人写的是没有真正做任何复杂的事情（在你一片哗然，我坦率地承认有这么多的许多消息）。 我们喜欢用隐喻来build立一个房子或办公室，在那里客户不断地改变自己的要求，或者有一些完全不同的东西，就好像我们的学科是独一无二的。 那么，如果你把这个故事告诉大多数承包商，我怀疑他们会笑你的脸。 它们不能抵抗矛盾的要求，非感性的要求，以及不断变化的要求。 一个纯粹的“瀑布”方法对他们来说，比起我们来说，已经不是什么问题了。
所以呢，那么最好的办法就是帮助一个非程序员明白为什么一个特定的任务或项目是困难的，而我认为呢，并不是想出一个比喻。 这是涉及他们。 向他们展示一些微不足道的事例，并让他们了解实际上进行这种“微不足道的”改变需要多less工作。
如果你有unit testing，也许做一个单行testing，然后向他们展示你的testing结果（ 应该都是通过的），之后再用红色的红色条表示。 “在那里，你可以指出，看看一行代码打破的一切，我必须在那里修复。 当然，这是一个炮制的例子。
我不认为这样的比喻会给非程序员真正的赞赏，因为我们所做的事情是复杂的（事实上并不那么复杂）。 你必须真正地让他们洞察你正在做的实际工作，实际上需要更多的批判性思维，一个简单的，聪明的类比。
这是描述软件工程的我最喜欢的隐喻之一：
-
想象一下，你正在build一座房子。 你必须有房子的计划，并决定要build造什么材料，以及如何组织build设过程。 （大多数人已经在他们的房子上完成了工作，所以他们对此有一些粗略的概念。）
-
现在想象一下，你不是在盖房子，而是在build造一个有100层办公室的摩天大楼。 计划如何与房子的计划不同？ 材料将如何不同？ 需要认真考虑哪些因素？
-
现在想象一下，你自己并没有build造摩天大楼，你正在build造一个飞向月球的机器人，并在那里build造摩天大楼。 现在计划怎么样呢？ 材料将如何不同？ 你明白为什么每一个决定的后果都需要仔细考虑？
如果你愿意，你可以用“货运pipe理系统”代替“摩天大楼”，我认为这个比喻仍然有用。
如果由于项目pipe理不善而导致项目pipe理迟缓，那么提交项目的时间就会不切实际
“如果我们增加几个程序员到项目中，你认为我们会及时完成它？”
你可以回复
“我的妻子有一个孩子，医生说需要9个月，我问我们是否用另外两个女人，我们可以完成3？
丰富
让另一个人发言，提出困难的问题。 也可能是一个有效的策略。 他的意见基于哪个数字？
数字更容易理解。
你有多less个
- 项目清单
- 用例
- 要求
- 涉及类似项目的开发者
- 公司或所需的第三方产品
- 用户
- 网站
- …
你需要同步吗？ 寻找metaphers的好点。
有没有风险pipe理？ 什么是失败的影响。 一个标准的PC程序并不重要，但如果你的程序计算错误的值或不再工作，会发生什么？
什么是难以编程的操作系统 – 我知道如何使用它:)不是一个有效的答案，对不对？
祝你好运
每个人都明白麦当劳。 如果你有大量的现金，你会得到一个特许经营权，然后有人进来为你整理所有东西。 软件就像获得特许经营权，然后自己做一切事情…
- 查找属性
- 投标财产
- 买房子
- 让一个施工人员去build造一个和其他McD's一样的贝壳build筑
- find并购买必要的设备
- 安装设备
- 获取电脑
- 编写销售点软件
- 把计算机放在驱动器窗口，并写代码xmit订单汉堡脚蹼
- 写时间卡软件
- 编写薪资软件
- 安装和计算机化安全系统
- 租用有能力的船员
- 列车员
- 买股票
- 编写软件来跟踪股票
- 编写软件以预测库存订单
- 等等。
你明白了。 一般Joe没有意识到有很多东西进入开发阶段。 麦当劳看起来很神奇。 但是有很多东西需要（保持）运行。
早在1982年，我就在为英特尔devise一些新的testing机器核心电子设备。 它是用于testing微控制器芯片（8X4X系列微控制器）的。 有人问我为什么在产品工程方面花了这么长时间（我在做testing工程）。 但这个问题背后有一种态度。 那时我只有大学一年的时间。
我问他：“你有没有devise过testing机器？”
他很快就意识到了他的问题。
希望这可以帮助。
JR
只是更厚的皮肤。 除非是老板，否则你不需要解释任何事情。 而且，顺便说一句，你永远不会把它传递给那些认为你整天在互联网上度过的人（如何，讽刺）。 这适用于程序员，服务器人员等等。
你不知道你为什么没有生活吗？
编辑：我得到了没有理由的反对票…
编写一个软件系统就像写一个故事。 这是一个创造性的努力，其连贯性直接依赖于作家。 随着故事的进展，绘图点（需求）会改变，字符被引入，塑造，并根据需要剪切（重构）。 对故事（领域）的理解是不断发展的，只有在故事的相关部分实际写出之前，才能知道某些细节。
代码是思想的expression; 与开发人员相比，开发人员更像是作者。 正如其他答案中提到的那样，build造房屋（或汽车或桥梁）的类比不能胜任。 几百年来，我们作为一个民族一直在挖掘这些模式; 我们只开发了约60年的软件（作为25年的工业）。 如果机械工程是软件开发的可靠类比，那么我们就不会有估计的问题。
通过所有必须编程的逻辑来讨论边缘情况。
例如，他们认为包含已发货数量的报告非常简单，因为他们只是select一个date范围，然后出现一个数字。 告诉他们代码如何查找还没有到达目的地的容器，它必须检查容器是否没有退回给发件人，如果容器是由海关持有的，因为它看起来可疑，那么你必须连接到海关办事处的networking服务来检查集装箱的状态，你需要忽略被取消的集装箱，因为船只沉没的集装箱在海上丢失被视为运输，但只有当船沉没超过120航海在离美国，英国，法国，日本或中国海岸数英里之外，或离开任何其他国家的海岸30海里处，在交通事故期间被毁坏的集装箱被计数，只要卡车司机没有过错，失去了至less6个月的失踪人数，依此类推。
这给了人们一个程序员必须考虑的“次要细节”数量的想法，即使在看起来很简单的程序中也是如此。
我喜欢将编程项目与飞机进行比较。 飞机有很多复杂的情况。 一个低级的，简单但function强大的应用程序可能是一个二战的双翼飞机。 这是有限的使用，但在正确的情况下，这是正确的工具。 另一方面，当你开始寻找一个商业喷气式客轮，以及build立一个商业喷气式飞机的细节/复杂程度时，你会有一个完全不同的故事。 它不仅必须能够飞行使用它的人需要安全和舒适的使用它。 如果飞机（应用程序）崩溃或过度延误，乘客（用户）会感到沮丧/不满意。 如果发生的话，他们会find一家新的航空公司。 你可以沿着你所需要的任何path与飞机的错综复杂的运行。
飞机上的其他巨大差异是飞行/维护飞机所需的技能水平和人数。 一个人可以飞/维持一架双翼飞机，但是你需要一个更大的机组人员来训练和工作时间更长的时间来处理一架商用客机。
也许你不能说出为什么它很复杂，但你可能会参考劳动的复杂性。
你可以说这个项目非常复杂，10个人应该在这个项目上工作2年？
build筑车比喻几乎总是工作。 知道你的观众，因为它可能不是一个女士（尝试build立一套服装，协调类比相反）。
我可以避开房子的比喻。 当我们三年前build造房屋时，我们感到非常惊讶的是，它不像一个工程项目。 我发誓，水pipe工和其中一个修剪木匠一定是醉了。
显示这个家伙你的function规格。 他将开始了解构build应用程序涉及多less细节。
编程涉及在彼此之上分布的过多的条件和行为。 如果一个条件不是100％正确的，那么程序可能会执行错误的操作。 而电脑是不宽容的。
就像一个高手下棋，预测对手的动作一样，程序员的工作就是预测每一个场景并在代码中进行解释。
随着项目的发展，国际象棋棋盘的增长以及对于单个程序员来说，完美的必要性成倍地增加。
在接受采访时，我记得莫比说了一些事情的效果…
有时候我觉得应该把“一切都错了”改成“一切都很复杂”。
那是软件。
或者他们实际上阅读 ，给他们：
我在“多媒体前沿”上与微软合作唱“身体电子：一年” ，这可能是我读过的最好的一本书，可以让外行人深入了解软件开发。 （事实上，作为一个非CS的专业，这是导致我留在软件的书籍之一）。
在一些项目上，我想尝试把一只章鱼装进一个小盒子里。 对于一些项目，我觉得我正在组装一部由跑步电影制作的拼图游戏。 可能不是向客户解释某事的隐喻，尽pipe:)
我会遇到的第一个问题是谁是你的观众？ 这是pipe理吗？ 这个人为什么理解复杂性呢？
假定这个人对于系统的复杂性有适度的把握是关键性的，那么你可以采取一些方法来显示系统的概况，进入一个方面的细节，然后询问他们对系统可以简化。 这个人对于理解你的复杂系统确实有着独特的才能，所以对他们来说，这也不是那么复杂。 无论如何，让他们参与并投入系统的发展，他们可能会从你最严厉的批评者转向你的冠军。
