构建软件最困难的部分不是编码,而是需求


在所有关于人工智能的发展有多么令人惊叹的文章中,有很多人都在担心,我们这些软件开发人员可能很快就会失业,被人工智能所取代。他们想象所有的企业高管和产品研究人员都会绕过大部分或全部的软件开发人员,直接让人工智能来构建他们认为想要或需要的东西。作为一个花了 15 年时间根据这些人创建的规格来创建软件的人,我很难把这些担忧当真。

编码可能是一项挑战,但我从来没有花超过两周的时间去弄清代码出了什么问题。一旦你掌握了语法、逻辑和技术,大多数时候,这都是一个相当简单的过程。真正的问题通常集中在软件应该做什么。创建软件最难的部分不是编写代码,而是创建需求,而这些软件需求仍然是由人类定义的。

本文将讨论需求与软件之间的关系,以及人工智能需要什么才能产生好的结果。

人工智能无法创建软件,只能编写代码
与下棋相比,创建和维护软件与开车有很多共同之处。其中涉及的变量要多得多,而且规则是基于判断的。在构建软件时,您可能会有一个理想的结果,但不可能像下棋那样单一。软件很少是一蹴而就的,功能会不断增加,错误会不断修复,这是一项持续性的工作。与软件不同的是,棋局的胜负一旦确定,就结束了。

在软件开发中,我们确实有一种工具可以让我们的软件设计更接近国际象棋中严格控制的规则引擎:技术规范。在最佳状态下,技术规格书会说明预期的用户行为和程序流程。用户是如何购买电子三明治的:点击这个按钮,创建这个数据结构,运行这个服务。然而,我们得到的很少是这样的结果。很多时候,我们得到的是作为功能规格的愿望清单、草图式的线框图和不明确的需求文档,然后让我们做出最好的判断。

更糟糕的是,需求会发生变化或被忽视。最近,我受邀帮助一个团队开发一款应用程序,帮助人们获取与 COVID 19 相关的健康信息。该应用程序将用于全球没有可靠 WIFI 的地区。该团队希望我帮助开发一款可以通过手机短信进行调查的应用程序。起初,我很高兴能参与其中。

当我开始听到团队描述他们的想法时,我意识到这将是一个问题。对于零售公司来说,用 1-10 分来衡量你是否有可能再次光顾他们的商店是一回事。但是,就您可能感染 COVID 后出现的症状进行多步调查,并提出多项选择问题,这就完全不同了。我从来没有说过不,但我确实提出了这一过程中可能出现的所有故障点,并希望团队明确规定我们将如何处理所有问题的答案。是用逗号分隔的数字映射每个答案吗?如果提交的答案与给出的任何选项都不对应,会发生什么情况?

在提出所有这些问题之后,团队得出了相同的结论。我们决定,最好还是不要去做。信不信由你,我想说这其实是一个成功的结果。如果不明确解决提交无效用户数据时可能出现的所有错误,就继续进行,会造成更大的浪费。

使用人工智能创建软件背后的想法是否只是让这些利益相关者直接与计算机对话,创建基于短信的调查?人工智能是否会就如何处理通过短信收集调查数据的所有可能问题提出探究性问题?它是否会考虑到我们人类在此过程中可能做错的所有事情,以及如何处理这些失误?

要想利用人工智能开发出一款功能强大的软件,您需要知道自己想要什么,并且能够清晰、准确地定义它。有时候,我只是为自己编写软件,直到真正开始编写代码时,我才意识到其中的困难和挑战。

在过去的十年中,软件行业已经从瀑布式方法过渡到了敏捷式方法。瀑布式方法在编写任何代码之前就准确定义了你想要的东西,而敏捷式方法则允许有足够的灵活性,这样你就可以在编写过程中进行调整。

许多使用瀑布法的软件项目都失败了,因为利益相关者认为他们知道自己想要什么,认为他们可以准确地描述并记录下来,但当最终产品交付时,他们却非常失望。敏捷软件开发应该是这一过程的解药。

人工智能可能最适合重写我们已有的软件,但需要重写以使用更新的硬件或更现代的编程语言。现在仍有很多机构在使用 COBOL 编写的软件,但学习如何使用 COBOL 的程序员却越来越少。如果你清楚地知道自己想要什么,也许你可以让人工智能比人类程序员团队更快、更便宜地制作软件。我相信,人工智能可以比人类程序员更快地创建已经创建好的软件,但那是因为有人在创建过程中发现了软件应该做什么。

实际上,人工智能在使用瀑布式流程(也被亲切地称为死亡行军)构建软件时可能会做得很好。你知道谁最不擅长瀑布式流程吗?我们人类。这并不是因为把签署好的文件交给程序员团队,让他们编写代码。而是在此之前的一切。人工智能可以做一些非凡的事情,但它不能读懂你的心思,也不能告诉你应该想要什么。