是否有任何好的比喻来解释非程序员的项目复杂性?

时间:2009-08-14 14:01:47

标签: project-management

刚才提到我“并没有完全建造西斯廷教堂。”这是事实,但我正在建立货运管理应用程序,这不像在表单上绘制控件那么简单(即使供应商会让您相信它)。

我不反对那个说出来的人,但我确实觉得我所做的事情的复杂性有点被误解,或者说不会发表声明。

是否有任何好的比喻可以说明项目对非程序员的复杂性?

35 个答案:

答案 0 :(得分:84)

演讲者几乎肯定是“绘画西斯廷教堂[天花板]”。有什么有意义的相似之处吗?

米开朗基罗对原建筑师提出的脚手架有一些问题。他最终构建了自己的框架。

米开朗基罗是一位雕塑家,他必须学习壁画以完成委托。

教皇朱利叶斯二世原本想要使徒画的12个人物。米开朗基罗在选择主题方面进行了自由交涉,并提供了描述超过300个数字的旧约圣经场景。他自己做了所有的绘画。

该项目不断耗尽资金(因为教皇不断与周边国家发生战争)。

让我们看看。严重依赖于技术主流,现金流问题,无法满足客户的规格......你是对的,听起来好像没有我听说过的软件项目。

答案 1 :(得分:66)

我会记得我曾经听过的一则古老的轶事:

  

一位汽车修理工问外科医生:“你为什么赚到那么多?你可能做的那么复杂?我的引擎工作对我来说看起来非常复杂和具有挑战性,而且我真的很擅长它!我可以修复引擎出错的任何问题!“

     然后外科医生过去,转动点火装置并启动汽车。然后他看着机械师:“好吧,现在解决它。”

答案 2 :(得分:52)

这不是火箭手术。

答案 3 :(得分:32)

一些比喻......

  • 复杂性方面,它本身就是从头开始构建汽车或船的需要工程师团队的软件项目就像构建航天飞机。唯一的区别是,如果你搞砸了,人们通常不会死。如果人们的生命受到威胁,那就更像是航天飞机了。 (不过,软件几乎从未像火箭飞机一样酷。)

  • 你的软件项目确实不是西斯廷教堂(是什么?),但它有点像建立货运管理系统,这本身就非常复杂。您可以在白板上绘制一些图表,或者碰巧带有系统设计和数据流图。 帮助他们看。

  • 问,“你有没有建一台电脑?”选择和订购所有组件,构建计算机,选择和安装操作软件,设备驱动程序,配置最终结果都将花费更少的时间,并且远没有这个货运管理项目复杂。

关于将它与他们所做的事情联系起来的建议是好的,但要确保你对他们所做的事情有足够的了解做出足够的类比。如果他们是一名训练有素的机械师并且你说它与重建化油器(而不是自动变速器)相当,他们可能会认为“没问题,所以它不是很复杂。”

Neil Ernst talks about software metaphors a bit,家庭承包比喻的适用性,并且还指出软件工程本身很难解释,因为它是在抽象中工作

Neil链接到Jim Waldo撰写的一篇文章,Software Engineering and the Art of Design,他指出

  

通过这种方式,我们所谓的软件工程更像是   建筑(生产建筑的真实建筑)比它更像   其他工程。有一个科学元素(建筑物有   遵守物理定律)但也有很大的艺术元素。   根据您生产的软件类型,两者的组合可能会有所不同   一些,但总有一个混合。

所以,也许宏伟的建筑和建筑专长是一个恰当的比喻。 (并不是说我们所做的事情接近西斯廷教堂,但我们应该接近我们的想法。)

不幸的是,将您的项目视为微不足道的人不太可能理解这一点。他们可能无法抽象地思考得到它。你可以期待的最好的是他们能够把握汽车或船只或房子的类比,或者帮助他们用图表它。

编辑:您对项目与“在表单上绘制控件”之间的相对复杂性提出了一个观点。也许你可以回应西斯廷教堂的评论,说“这是真的。但是,如果一个三个月的网络项目是你家后面的小棚子,这个货运管理系统 Rogers Centre < /强>

答案 4 :(得分:21)

如果它不像建立西斯廷教堂,也许更像是建造一座房子。建造房屋有很多不同的东西,许多不同的人参与不同的专业。没有什么是过于复杂的,但涉及到很多工作!

问题在于它真的就像建房子一样;它更像是建造一个一直在变化的房子。但是,出于复杂性的目的,这可能会更有效地说明您的观点。

答案 5 :(得分:18)

编程就像教一个宝贝。请耐心等待:想象一下,你想向宝宝解释如何购买胡萝卜。你将做与教授机器人相同的事情。

首先,他必须学会走路。步行子程序。我不会详细介绍,但他必须将脚放在另一个前面并平衡他的体重。你必须管理他跌倒或遇到障碍的例外情况。

然后他需要有关超市位置的地理规范。

必须告诉他使用步行子程序,直到他找到市场。如果他没有在合理的时间内找到市场(必须定义),他必须启动回国日常工作。

如果他找到超市,他必须使用胡萝卜侦察算法找到胡萝卜。他必须将每个对象与他的数据库中的胡萝卜3D模型进行比较。合理的时间(或超时)。

然后他必须评估一个地方用钱来交易胡萝卜,以便永久获得胡萝卜。这部分可能真的很棘手。

然后,他必须根据当前胡萝卜国际价格与在另一个地方获得价格较低的胡萝卜所需的资源来评估价格。

我只是完成整个过程的一半,你抓住了我的漂移。我跳过很多检查和例外,评估,识别等等。整个开发团队需要几个月甚至几年的时间来编程。它只会购买胡萝卜。

我想说的是,当你开发一个应用程序时,你必须“告诉”它的一切,几乎所有东西。对于未明确指定的每个细节,您都会有惊喜:“随机”行为,错误或简单关闭。您必须告诉程序在一般情况下该做什么以及在情况发生变化时如何适应。编程就像教孩子一项非常复杂的任务一样。

然后是最糟糕的部分。在整个过程中你无法握住宝宝的手。你确保他拥有一切并让他离开。 2个可能的结果:从开始到结束一切正常(从未发生过)或婴儿在任务中间的某个地方坐着,哭了,你不能问他出了什么问题。他只是在哭,不会停止。然后调试开始。

现在您可以更好地想象需要多少努力来构建管理股票交易所的软件,或者自动割草机或飞机!你需要多长时间教宝宝如何驾驶飞机?

答案 6 :(得分:18)

如果一个人不理解它,那么这个比喻对你没有任何好处。您应该尝试用他们能理解的术语来解释个体的复杂性。如果可能的话,试着将它与他们可能遇到的复杂工作环境联系起来。

对于会计师来说,你可以说:“这就像你拿计算器并自己审核美联储一样”

答案 7 :(得分:11)

没有

老实说,没有。

您可以做的最好的事情就是让最终用户扮演计算机角色,这样他们就必须仔细考虑每个用例,直到他们意识到这个过程本身是多么复杂。

答案 8 :(得分:8)

我经常与外行人一起使用的一个比喻是,构建软件并不像建立一座桥梁:

  • 如果您正在建造一座桥梁,您可以购买工字钢和铆钉,您可以倒入标准混凝土。如果你正在构建软件,你必须制作自己的工字梁和铆钉,你可能需要发明非标准混凝土。

  • 当桥梁完成一半时,没有人告诉你它应该在晚上作为免下车电影院运作。但在软件方面,最新的变更请求很常见。

  • 当桥梁完成一半时,您可以告诉。你不知道软件什么时候完成了一半。

  • 通过使用X射线,超声波和其他工具,您可以确保桥梁在使用过桥之前没有结构故障。但即使采用最佳测试方法,在使用软件之前也无法发现软件中的许多故障。而且很难知道纠正特定故障或发现最后一个重要故障需要多长时间。

所有这些因素都有助于解释为什么很难预测软件项目需要多长时间,以及为什么软件项目往往会迟到。

答案 9 :(得分:8)

为他们快速滚动数千行代码。 说“如果一个角色出错,整个事情都行不通”。

另一个:

就像写小说一样,除非有一个错字或语法错误,整个事情都没有意义。

答案 10 :(得分:5)

我无法自拔,但我只是必须发布该视频来自That Mitchell&amp;韦伯看:

Brain Surgeon - That Mitchell & Webb Look , Series 3 - BBC Two

除此之外,它可能有助于证明规划软件项目涉及许多与规划构建相同的问题 - 哦,比方说,一个小教堂。你有很多非常不同的方面需要管理,如果有人在基础上犯了错误,整个想法都会崩溃。

答案 11 :(得分:2)

业务应用程序的主要目标通常是帮助组织内部的通信。因此,当我试图描述业务应用程序的复杂性时,我经常倾向于打破X和Y之间的日常业务通信。并粉碎它!

这使得没有任何编程经验的人更容易转发复杂性。因为你不仅要做X和Y谈话,还必须弥补他们的语言。等等。

我希望这会有所帮助=)

答案 12 :(得分:2)

这是我最喜欢的描述软件工程的比喻之一:

  • 想象一下,你正在建房子。你必须有房子的计划,并决定要建造什么材料,以及如何组织建设过程。 (大多数人已经在他们的房子上完成了工作,所以他们对这涉及的内容有一些粗略的概念。)

  • 现在想象一下,你不是在建房子,而是在建造一座有100层办公室的摩天大楼。计划如何与房子的计划不同?材料如何需要不同?需要仔细考虑哪些因素?

  • 现在想象一下,你自己并没有建造摩天大楼,你正在建造一个飞向月球并在那里建造摩天大楼的机器人。现在计划将如何不同?材料如何需要不同?你明白为什么需要仔细考虑每个决定的后果吗?

如果你愿意,你可以用“货运管理系统”取代“摩天大楼”,我认为这个比喻仍然有用。

答案 13 :(得分:2)

您可以与之前的软件项目进行比较。

  

还记得旧项目X,花了大约6个月吗?好吧,新项目Y大致相当复杂。

如果做不到这一点,请将您的项目与需要实际物理工程的其他项目进行比较。有些项目就像设计和建造房屋,有些更像是一座桥梁。

如果您能找到贵公司所做的工程项目作为比较的基础,那就更好了,当然这取决于他们的行业。

答案 14 :(得分:2)

我认为缺乏技术背景的人过于简单化我们(意味着程序员)所做的事情是很常见的。也就是说,我认为许多程序员过于复杂化了我们的工作,或者至少做了更多的事情。

我冒险使用我们大多数人写的软件并没有真正做任何复杂的事情(在你引起骚动之前,我承认有很多很多的赘述)。我们喜欢把隐喻用于建造房屋或办公室,客户不断改变他的要求或者有完全不同的要求,好像这对我们的学科来说是独一无二的。好吧,如果你告诉大多数承包商这个故事,我怀疑他们会笑到你的脸上。他们对矛盾的要求,非感性要求和不断变化的要求不再比我们更能免疫。对于他们来说,纯粹的“瀑布式”方法对我们来说没有问题。

因此,我认为,帮助非程序员理解特定任务或项目难度的最佳方法不是想出一些比喻。这是涉及他们。向他们展示一些微不足道的例子,让他们深入了解实际需要做多少工作才能进行“微不足道”的改变。

如果您有单元测试,可以进行单线测试,然后在之前显示测试结果(应该全部通过),然后在红色条之后显示红色条。 “在那里,你可以指出。看看一行代码破坏的一切。我必须在那里修复每一件事”。当然,这是一个炮制的例子。

我认为类比不会让非程序员真正理解我们所做的事情的复杂性(实际上,这并不是那么复杂)。你必须真正让他们深入了解你正在做的实际工作,这实际上需要一个更简单,更聪明的类比的批判性思考。

答案 15 :(得分:1)

与他们讨论您必须为边缘案例场景编程的所有逻辑。

例如,他们认为发货的包含数量的报告非常简单,因为他们只选择了一个日期范围并且出现了一个数字。告诉他们代码如何查找尚未到达目的地的容器,它必须检查容器是否没有返回给发件人,如果容器由海关持有,因为它看起来很可疑,那么你必须连接到海关办公室Web服务以检查容器的状态,您需要忽略已取消的容器,因船舶沉没而在海上丢失的容器计为已装运,但仅 该船在离美国,英国,法国,日本或中国海岸120多海里处沉没,或在任何其他国家海岸30海里处沉没,在交通事故中被摧毁的集装箱被计算在内,前提是卡车司机是没有过错,容易失踪的容器在被丢失至少6个月之前不计算在内,等等。

这让人们了解程序员必须考虑的大量“小细节”,即使在简单明显的程序中也是如此。

答案 16 :(得分:1)

编写软件系统就像写一个故事。这是一种创造性的努力,其连贯性直接取决于作者。随着故事的进展,绘图点(要求)会发生变化,并根据需要引入,塑造和剪切字符(重构)。对故事(领域)的理解是不断发展的,只有在故事的相关部分真正被写入之后才能知道某些细节。

代码是思想的表达;因此,开发人员与作者相比具有更多的共同点。正如其他答案中所提到的,建造房屋(或汽车或桥梁)的类比并不适合。几个世纪以来,我们一直在抨击这些模式;我们只开发了大约60年的软件(作为一个行业~25岁)。如果机械工程是软件开发的可靠类比,那么我们就不会遇到估算问题。

答案 17 :(得分:1)

早在1982年,我就为英特尔设计了一些新的测试机器核心电子设备。它用于测试微控制器芯片(8X4X系列微控制器)。我被问到为什么这么长时间由一个产品工程专家(我在测试工程中)。但问题背后有一个态度。那时我大学只有一年了。

我问他,“你有没有设计过一台试验机?”

他很快就意识到了这个问题。

希望这有帮助。

JR

答案 18 :(得分:1)

我喜欢将编程项目与飞机进行比较。飞机的复杂程度很高。一个低级,简单但功能性的应用程序可能是二战双翼飞机。它的使用有限,但在正确的背景下,它是正确的工具。另一方面,当你开始研究商用喷气式飞机时,以及建造一个所需的细节/复杂程度,你会有一个完全不同的故事。它不仅必须能够飞行使用它的人在使用它时需要安全和舒适。如果飞机(app)崩溃或有过多的延误,乘客(用户)会感到沮丧/不满意。如果它足够发生,他们会找到一家新的航空公司。您可以沿着您需要的任何路径运行飞机的复杂性。

飞机的另一个巨大差异是飞行/维护飞机所需的技能水平和人数。一个人可以驾驶/维护一架双翼飞机,但你需要一个更大的机组人员,需要更多的训练/工时来处理商用客机。

答案 19 :(得分:1)

每个人都了解麦当劳。如果你有一大堆现金,你会得到一个特许经营权,有人进来并为你设置整个事情。软件就像获得特许经营权,然后自己做所有事情......

  1. 查找属性
  2. 出售物业
  3. 购买物业
  4. 让建筑工作人员建造一个看起来像其他McD's
  5. 的外壳
  6. 查找并购买必要的设备
  7. 安装设备
  8. 获取计算机
  9. 编写销售点软件
  10. 将计算机置于驾驶窗口并将代码写入xmit命令以打开鳍状肢
  11. 编写考勤卡软件
  12. 编写工资单软件
  13. 安装并计算机化安全系统
  14. 雇用合格的船员
  15. 训练人员
  16. 购买股票
  17. 编写软件以跟踪库存
  18. 编写软件以预测库存订单
  19. 你明白了。普通的Joe没有意识到有很多东西需要开发。麦当劳看起来像魔术。但是,获得(并保持)一个人的运作还有很多。

答案 20 :(得分:1)

只是皮肤变粗了。除非是老板,否则你没有来解释任何事情。而且,顺便说一句,你永远不会把它告诉那些认为你整天都在互联网上度过的人(具体而言,具有讽刺意味)。这适用于程序员,服务器人员等。

你不知道你没有做任何事吗?

编辑:我无缘无故地投票了......

答案 21 :(得分:1)

由于蹩脚的项目管理产生不切实际的估计而你迟交的项目......那么权力可以说是

“如果我们在项目中添加更多程序员,您认为我们会及时完成吗?”

您可以回复

“我的妻子正在生孩子,医生说需要9个月,我问我们是否再使用了2名女性,我们可以在3岁​​时完成吗?”

答案 22 :(得分:1)

让对方说话并提出疑难问题。可能也是一个有效的策略。他的观点基于哪些数字?

数字更容易理解。

你有多少

  • 列表项
  • 用例
  • 要求
  • 涉及类似项目的开发人员
  • 公司或所需的第三方产品
  • 用户
  • 位点
  • ...

你需要同步吗?也很好找到metaphers。

是否存在风险管理?失败的影响是什么?标准PC程序并不重要,但如果您的程序计算错误值或不再起作用会发生什么?

编程操作系统有什么困难 - 我知道如何使用它:) 不是一个有效的答案,对吗?

祝你好运

答案 23 :(得分:0)

我要问的第一个问题是谁是你的听众?这是管理层吗?为什么这个人理解复杂性很重要?

假设这个人对系统的复杂性有一定的掌握是至关重要的,你可以大胆地展示系统的概况,深入了解一个方面的细节,然后询问他们的输入系统可以简化的地方。这个人也有可能真正具备理解复杂系统的独特能力,所以对他们而言,并非复杂。无论如何,让他们参与并投入到系统的开发中,他们可能会从最严厉的批评者变成你的冠军。

答案 24 :(得分:0)

我发现的问题是,有时简单的事情比想象的要复杂得多。例如,他们可以简单地说,“每次发生这种情况,都要做到这一点。”这是简单的变化,但最终需要大量的代码或复杂/错误的行为。

为了解释它,它有点复杂。如果你的项目经理给你一个艰难的时间,因为这对他来说很简单,那么需要发生的事情会给你时间。说还没准备好,然后展示你拥有的东西。最终他们会知道,当你说它需要花费X的时间时,你真的意味着它需要花费X的时间。

答案 25 :(得分:0)

在某些项目中,我觉得要尝试将章鱼放入一个小盒子里。有些项目我觉得我正在组装一个由跑步电影组成的拼图游戏。可能不是向客户解释某事的比喻,但是:)

答案 26 :(得分:0)

我喜欢说它就像建造一艘船然后维持它:保持发动机良好状态,清洁,刮掉藤壶等物。当然,软件不会因为旧的,需求变化,环境变化而中断。

看看Steve McConnels的Code Complete,你会在那里找到一些好的比喻。

答案 27 :(得分:0)

在一次采访中,我记得白痴说了些什么......

有时我认为我应该将“一切都错”改为“一切都很复杂。”


那是软件。

或者他们实际上阅读,给他们:

I Sing the Body Electronic: A Year with Microsoft on the Multimedia Frontier,这可能是我读过的最好的书,可以让非专业人士深入了解软件开发。 (事实上​​,作为非CS专业,它是导致我继续使用软件的书之一。)

答案 28 :(得分:0)

编程涉及在彼此之上分层的众多条件和动作。如果一个条件不是100%正确,那么程序可能会执行错误的操作。计算机并不宽容。

就像国际象棋大师期待他的对手移动一样,程序员的工作是预测每个场景并在代码中解释它。

随着项目的发展,国际象棋棋盘会逐渐增长,对于单个程序员来说,完美的必要性变得越来越难以处理。

答案 29 :(得分:0)

我会把房屋建筑的比喻更进一步。每个项目就像使用略有不同的组件从头开始建造房屋,这些组件的材料具有不同的属性,并且以不同的方式相互交互。通常情况下,每个房子都建立在不同的行星上,而物理定律略有不同。

当然还有永远存在的客户在您建造房屋时不断改变房屋的设计。

所以是的,你可以说所有的房子都是一样的;屋顶,墙壁,门,窗户,管道,布线 - 但魔鬼总是在细节中。

反隐喻怎么样?软件开发项目不是组装线。

答案 30 :(得分:0)

我告诉人们这就像维护一个需要保持运转的引擎,并且每周都会做一些不同的事情。此外,它是不可见的,你必须弄清楚间接发生了什么。

这种描述并不能真正满足非技术人员的需求,但它让我感觉更好。

工程复杂性的很大一部分涉及人与人之间的互动(以及他们所代表的分歧,他们的目标,以及这些互动产生的不断变化的设计决策)。我从来没有能够向非工程师解释这一点,他们通常会告诉我,“如果你愿意的话,你可以随时在家工作。”

答案 31 :(得分:0)

我可能会避开这个房子的比喻。 3年前,当我们建造房屋时,我们对工程项目的不同感到震惊。我发誓水管工,其中一个修剪的木匠一定是喝醉了。

向这个人展示你的功能规格。他将开始了解构建应用程序涉及多少细节。

答案 32 :(得分:0)

这是一个花园。我的母亲是一个敏锐的园丁,她谈论她的花园就像我谈论我的代码库一样。

  1. 从未完成 - 总有杂草被删除(错误/重构),以及新的草本边界或菜地(新功能/要求)的计划
  2. 你必须应对意外 - 有一天,当她去除草并重新组织一张花坛时,她发现一群青蛙已经入住,阻止她做任何事情直到冬天才有人入侵(有点像在第三方图书馆找到诡异,或者在外部承包商处等待)
  3. 你可以浪费你的一生,从不觉得你完成了一半你想做的事

答案 33 :(得分:0)

我的方法完全不同:

  

我只是向他们解释好像他们是另一个开发人员,当他们问一个技术术语意味着什么时,我也解释一下,这通常会导致更多的细节,等等。我发现用户实际上实现了如何事情很复杂。

在我看来,类比是行不通的,因为它们无法与发展联系起来。

Darknight

答案 34 :(得分:0)

也许你不知道为什么它很复杂,但你可能会在复杂性上引用劳动力。

你可以说它太复杂了,10个人应该在这个项目上工作2年?