商务高管和产品经理将绕过大多数或所有的软件开发者
发表时间:2023-11-07 13:02:57
文章来源:炫佑科技
浏览次数:125
菏泽炫佑科技
商务高管和产品经理将绕过大多数或所有的软件开发者
图片来源:
随着有关人工智能发展的热门文章激增,我们软件开发人员深感担忧,我们将在不久的将来被人工智能取代并失去工作。 一些人认为,企业高管和产品经理将绕过大多数或所有软件开发人员,只是要求人工智能按照他们的条件创造他们想要的东西。 作为一个花了 15 年时间根据这些人提供的规范创建软件的人,我很难认真对待所有这些问题。
虽然编程需要一定的基础,但是学起来并没有你想象的那么难。 一旦掌握了语法、逻辑和技巧,大多数时候你就可以一步步编写代码了。 真正困难和复杂的问题通常涉及软件应该满足什么需求,以及如何设计优雅和高性能的解决方案。 创建软件*困难的部分不是编写代码,而是创建需求、分析需求,而这些软件需求仍然需要由人类来定义。
本文将讨论需求和软件之间的关系,以及人工智能如果要取代人类软件开发人员需要具备哪些能力或条件。
这不是一个错误,这是...等等,这是一个错误
在我的软件职业生涯早期,我主动参与了一个项目并加入了团队,以帮助提高团队的生产力。 该软件的主要功能是为电子商务网站提供定制产品配置服务。 我的任务是生成动态条款和条件。 条款和条件中包含的表述不仅取决于所购买产品的类型,而且还适应客户所在美国州的法律要求。 在开发过程中我想我发现了一个可能的缺陷。 用户将选择一种产品类型,这将生成相应的条款和条件,但稍后在工作流程中,软件将允许用户选择不同的产品类型和预定义的条款和条件。 这将违反业务要求中指定的功能,该功能已由客户书面确认。 我真诚地问客户:“我是否应该删除允许用户覆盖正确条款和条件的选项?” 我清楚地记得他的回答。 “这永远不会发生,”他断言。
这位高级管理人员已在该公司工作多年,了解其业务流程,并亲自负责监督该软件。 作为一个新手,我怎么能质疑任何人,尤其是一家付钱让我们为其开发产品的公司的高级管理人员呢? 我疑惑地摇摇头,但也没有多想。
几个月后,就在软件上线前几周,客户的一位测试人员发现了一个缺陷并将其分配给我。 当我看到这个缺陷的细节时app开发,我苦笑了。
我之前担心覆盖默认条款和条件,但我被告知永远不会发生这种情况,猜猜发生了什么? 猜猜谁对此负责,谁被要求解决这个问题?
解决这个问题相对简单,“bug”的影响也很低,但这种经历在我的软件开发生涯中不断出现。 我与很多软件工程师交谈过,并且知道我并不是唯一经历过这种情况的人。 问题变得更大、更难解决,因此成本也更高,但问题的根源通常是相同的:需求不明确、不一致或错误。
为了用人工智能取代程序员,客户需要准确地描述他们想要什么。 现在还不可能,我们还是安全的。
现在的人工智能:棋盘游戏和自动驾驶汽车
尽管人工智能的概念由来已久,但*近取得的显着成就引起了媒体甚至议会的高度关注。 人工智能在一些领域取得了巨大成功。 **个想到的就是桌游。 早在20世纪80年代,人工智能就开始应用于桌游中。 人们普遍认为人工智能已经在棋盘上超越了人类。 这并不奇怪,因为棋盘游戏中的变量是有限的(但游戏尚未完全解决)。
棋盘游戏总是从 64 个方格上的 32 个棋子开始,有明确且普遍接受的规则,*重要的是有一个明确的目标。 在每一轮中,可能的动作数量有限。 下棋就是遵循一套规则系统。 人工智能系统可以计算每一步棋的后果,选择*有可能吃掉对方棋子、占据优势的棋步,*终获胜。 人工智能还有一个非常活跃的领域——自动驾驶汽车。 制造商长期以来一直承诺推出自动驾驶汽车。 有些汽车具有自动驾驶功能,但也有局限性。 在许多情况下商务高管和产品经理将绕过大多数或所有的软件开发者,汽车需要持续监控; 驾驶员可能需要双手放在方向盘上,并且自动驾驶功能并不是完全自主的。
就像下棋的人工智能程序一样,自动驾驶汽车在做出决策时主要使用基于规则的引擎。 与棋盘程序不同,如何应对每种可能情况的规则并没有明确定义。 在单次行程中,驾驶员可能需要做出数千个小判断,例如避开行人、绕过双排停车位以及在繁忙的十字路口转弯。 做出正确的决定可能意味着安全到达购物中心还是被送往医院。
在科技行业,标准是 99.999% 甚至 99.9999% 的可用性——网站或服务在 99.999%(或 99.9999%)的时间内可用。 达到底部 99% 的成本并不高,这意味着您的网站或服务每年可能无法使用三天以上 - 87.6 小时。 然而,每增加 9 个,成本就会呈指数级增加。 当达到99.9999%时,一年只能允许31.5秒的停机时间。 这需要更多的计划和努力,而且成本肯定更高。 获得前 99% 可能并不容易,但显然比*后一小部分更容易、更便宜。
无论人工智能水平有多高,都不可能消除事故和死亡的风险。 当人类驾驶员驾驶车辆时,这些风险和后果每天都会发生。 我不知道政府会接受什么程度的事故和死亡人数,但我们必须期望自动驾驶汽车的事故和死亡人数至少比人类司机要低。
之所以难以达到可接受的安全水平,是因为驾驶汽车涉及的变量比棋盘游戏多得多,而且这些变量不是有限的。 *低的 95% 或 99% 可能是可预测的并且很容易实现。 然而,除了*低的 99% 之外,还存在许多边缘情况,每种情况可能有一些共性,但又都是独特的; 道路上还有其他人类驾驶的车辆、封路、施工、事故、天气条件,或者道路已铺设新沥青但道路隔离带尚未涂漆后行驶。 让您的人工智能系统能够处理和识别这些异常和边缘情况,更重要的是如何避免事件并做出适当的响应,这更加困难。 每个边缘情况可能有一些共性,但很少完全相同,这些变量使人工智能更难以确定适当的响应。
人工智能无法创建软件,只能编写代码
构建和维护软件更像是开车而不是下棋。 涉及的变量较多,规则基于判断。 当您构建软件时,您可能会得到期望的结果,但它不太可能像棋盘游戏那样确定。 软件很少是完美的; 添加了功能并修复了错误; 这是一个持续的过程。 然而,与软件不同的是,一旦确定了国际象棋比赛的结果,比赛就结束了。
在软件开发中,我们确实有一种工具可以使我们的软件设计更接近棋盘游戏严格控制的规则引擎:技术规范。 在*好的情况下,规范描述了预期的用户行为和程序流程。 这就是用户进行数字交易的方式:单击此按钮,创建此数据结构,运行此服务。 然而,我们经常得不到这样的规格。 我们经常会收到一份功能规格期望列表、餐巾纸背面潦草的线框图和模糊的需求文档,然后被告知要使用我们的*佳判断。
更糟糕的是,需求可能会改变或被忽略。 *近,我被要求帮助一个团队构建一些东西,帮助人们获取与 COVID-19 相关的健康问题的信息。 该应用程序将针对那些没有可靠WIFI的地区。 该团队希望我帮助构建一个可以通过 SMS(短信)进行调查的应用程序。 起初,我很高兴能成为其中的一部分。
然而,当我开始听到团队描述他们想要什么时,我意识到这将是一个问题。 对于零售公司来说,以 1-10 为范围询问您再次到他们商店购物的可能性是一回事。 但通过多项选择题询问您可能表现出的新冠病毒感染症状的多步骤调查则是另一回事。 我从不说不,但我确实提出了一路上所有可能的失败点,并希望团队明确定义我们将如何处理它们。 我们会使用逗号分隔数字,将每个数字映射到一个答案吗? 如果提交的答案与给定的任何选项都不对应,会发生什么情况?
经过所有这些问题,团队得出了相同的结论。 我们决定*好不要继续。 不管你信不信,我想说这实际上是一个成功的结果。 当提交的用户数据无效时,如果没有明确解决所有潜在错误,继续下去会更加浪费。
使用人工智能创建软件,让这些利益相关者直接与计算机对话以创建基于短信的调查的想法是什么? AI是否会询问如何处理通过短信收集调查数据时可能出现的所有问题? 它是否考虑到我们作为人类一路上可能做错的所有事情,以及如何处理这些失误?
为了从人工智能生成功能齐全的软件,您需要知道您想要什么,并能够清晰准确地定义它。 有时,直到我开始编写代码时,我才意识到潜在的困难和挑战。 过去十年,软件行业已经从瀑布模型转向敏捷开发。 瀑布方法在编写任何代码之前准确定义了您想要的内容,而敏捷方法允许您一路进行调整。
许多使用瀑布方法的软件项目都失败了,因为利益相关者认为他们知道自己想要什么,并且认为他们可以准确地描述和记录它。 然而,当*终产品交付时,他们常常感到非常失望。 敏捷软件开发被视为解决这个问题的方法。 人工智能也许*适合重构我们已有但需要使用更新的硬件或更现代的编程语言重写的软件。 仍然有许多组织的软件是用 COBOL 编写的,但学习如何使用它的程序员越来越少。 如果你确切地知道自己想要什么,也许你可以让人工智能比人类程序员团队更快、更便宜地开发软件。 我认为人工智能可以比人类程序员更快地开发软件,但这是基于有人首先弄清楚软件的功能和要求。
尽管瀑布法被亲切地称为“死亡行军”,但人工智能在使用瀑布法构建软件时可以表现得相当好。 谁的瀑布法做得不好? 是我们! 软件开发的关键在于编写代码的工作量,而不是将签名文档交给程序员团队来编写代码的部分。 人工智能可以把事情做得很好,但它还不能直接读取你的想法或告诉你你应该想要什么。
您是否也认为需求定义是软件开发中*困难的部分? 您在软件开发中是否遇到过由于需求不明确或不正确而导致的问题? 你是怎么解决的? 欢迎在评论区分享您的经验和教训。
炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等