如何在智能人工智能时代解决正确的问题

在人工智能出现之前，实施能力稀缺。一个糟糕的需求可能会浪费一些工程师的时间。有了人工智能，这种能力就会急剧扩大。现在，一个糟糕的需求可能会以非常低的成本产生数百个错误的更改。因此，瓶颈向上游移动：朝向问题定义、背景、约束、决策和验证。

如果方向错误，所有额外的速度只会让你以十倍的速度到达错误的地方。

事实上，您必须在某一时刻解决项目周围的不确定性。当零钱还便宜的时候为什么不这样做呢？更改蓝图比重建建筑物的整个部分要便宜得多。

本文的目标是为您提供在实施之前尽可能减少不确定性的工具。

本文介绍了一个实用的框架，只需 6 个步骤即可完成此任务。 每个步骤都会生成一份简短的文档，使决策变得明确、持久且可供人类和代理使用。这是所理解、决定和同意的内容的共享记录。

使用您构建的框架：

正确的事情：真正解决实际问题的解决方案。

正确的方法：不浪费金钱、时间或资源。

尽可能高效：在开发过程中足够清晰，以防止回溯、等待或猜测。

结果是对齐。人类和人工智能代理都遵循相同的剧本：对问题和预期解决方案的清晰、共同的理解。这可以防止猜测、返工和意外。

···

为什么这很重要

软件开发中最困难的问题很少是纯粹的技术问题。它们涉及沟通和协调：将模糊问题转变为正确解决方案的关键组成部分。如果利益相关者不能就他们正在构建的内容、原因或为谁达成一致，即使是最好的工程师也无法挽救项目。不一致会减慢团队的速度并耗尽优秀的工程师的精力，因为他们缺乏完成工作所需的结构和方向。

代理的介入会使这些风险变得更大。一个工程师一天走错方向所造成的损害是有限的。部署一整支代理的同一个工程师可以更快地造成更大的损害：一个错误的假设不再保留在一个文件中，它会在人类审查之前被复制到每个代理生成的触及相同模式的更改中。

然而，许多团队将需求视为一次性事件，然后冲刺开发，假设其余的事情会自行解决。没有蓝图你就不会建造一座房子。为什么要在没有适当准备的情况下构建软件项目？

是的，这需要预先投资。但一旦你算上合规违规、声誉受损、竞争优势和大规模返工的成本，“我们没有时间”往往会成为一个非常昂贵的句子。

犯错的代价

把精力花在需要的地方

并非每个决策都值得进行同等数量的分析。这是该框架背后的原则之一：

撤销决定的成本越高，您在做出决定之前应该消除的不确定性就越大。

选择按钮上的标签是高度可逆的。迅速做出决定，如果需要的话稍后再调整。选择数据契约、系统边界或集成架构可能并非如此，而且如果选错了，挽回成本会很高。这就是审查所属的地方。

何时使用此框架

并非每个软件变更都需要六个文档。

多个利益相关者或团队需要协调。

步骤

这并不意味着预先预测一切。这意味着将你的准备工作花在错误的决定实际上会让你付出代价的地方，并故意让其余的事情保持灵活性。

错误修复、小型内部脚本或一次性原型通常不能证明这种准备程度是合理的。将完整的框架应用于每一个变革会产生官僚主义而不是清晰度。

当方向错误的成本很高时，该框架就变得有价值。当以下几个条件成立时使用它：

问题或期望的结果不明确。

解决方案取决于现有系统、数据或组织限制。

重要的架构或数据决策的逆转代价高昂。

几个人或人工智能代理将并行工作。

错误可能会造成重大的财务、运营、合规或声誉损失。

该项目足够大，返工会对其结果产生重大影响。

您也不必使用具有相同详细程度的每个步骤。对于相对较小的项目，框架可能只有几页的决策。对于一个大型、复杂的项目，每一步都可能需要大量的发现和讨论。

重点不是完成六个文档，而是在开始实施之前减少重要的不确定性。

当协调和错误成本证明合理时使用该框架。

而且框架并不能替代实验。当假设不确定时，原型、尖峰或其他实验可能是减少不确定性的最快方法。然后结果应该反馈到相关步骤中，而不是默默地改变项目的方向。

框架

项目准备框架通过一次处理一个决策域来系统地减少不确定性。每一步都建立在上一步的基础上，在变革成本仍然很低的情况下提出最重要的问题。解释、假设、决策和推理都记录在相关利益相关者可以审查的共享文件中。

框架是顺序的，但不是瀑布式的。稍后的发现可能会使之前的决定无效。当发生这种情况时，返回，更新受影响的工件并明确更改后的决策。目标不是阻止变革，而是阻止未经承认的变革。

下表是框架概览。

文档

目的

业务先决条件

PID.md

协调业务问题、范围、组织、目标

IT 先决条件

发现报告.md

了解现有的数据、系统、可行性、风险和约束

功能需求

功能需求.md

定义解决方案必须执行的操作

技术要求

技术要求.md

定义解决方案的工作方式

治理

治理.md

定义谁参与、谁决定以及谁负责

规划

路线图.md

定义时间、顺序以及由谁进行

前四个步骤确定了我们所知道的以及我们打算构建的内容。这些步骤已经涉及决策和决策所有权。因此，第 5 步不引入治理。它将解决方案的构建、启动和运营所需的决策结构转变为明确的协议。

框架，一步一步

1.业务前提

webhook

人们应该能够对决策提出质疑，但不同意见应该导致决策所有者拨打电话，而不是导致决策在某人的收件箱中无人回复。

在本章中，我们将逐步介绍该框架。每个细节都详细说明了该步骤的目标、“战争故事”/示例、从该战争故事中汲取的经验教训以及有关如何创建文档的说明。

我在 GitHub 上创建了项目准备框架存储库，其中包含有关框架中每个步骤的单页程序和一些“战争故事”。我非常打算将其打造成一个社区项目，因此如果您有一些鼓舞人心的故事、改进或补充，请贡献力量。

为解决正确的问题奠定基础

此步骤解决了最昂贵的项目失败之一：解决错误的问题。它确保您专注于真正的业务问题，即利益相关者真正希望解决的问题，并具有明确的范围。它可以确保尽早获得支持和协调，并防止在没有人需要的事情上浪费精力。

工程师可以阅读生成的文档，了解其工作背后的“原因”，这使得日常决策变得更容易，开发更清晰，歧义更少，风险也更少。 一位客户曾经告诉我们他们迫切需要一个 webhook。我们放弃了一切并开始建造。当我们完成后，发现客户并不真正了解 webhook 是什么，他们实际上需要一个 API。

我们为一个不存在的问题提供了完美的技术解决方案。

经验教训

客户拥有问题，您拥有解决方案。如果您让客户定义解决方案，那么您就没有做好自己的工作。关于业务目标的简短采访会立即发现这一点。

如何：

创建 PID.md（产品启动文档），定义业务问题、目标、用户和成功指标。

阅读指南-使用模板

2. IT 先决条件

我们可以在现有环境下解决这个问题吗？

几乎每个解决方案都必须与现有系统和流程集成。它的成功程度在很大程度上取决于现有景观的实际支持能力。

此步骤通过了解数据、系统和依赖关系来评估在现有环境中解决问题的可行性。我们确保每个利益相关者在开发开始之前都知道什么是可能的，什么是不可能的。

实时仪表板

我们花了几个冲刺来构建一个系统来处理仪表板的实时数据。事实证明，数据源根本无法提供实时数据，只能每12小时提供一批数据。该产品运行完美，只是无法插入公司现有的生态系统。

这正是您希望尽早失败的事情。理想情况下，我们会发现我们正在“为一个没有铁路的组织建造火车”。

创建 discovery-report.md，以便在技术意外破坏项目之前主动将其暴露出来。

3. 功能需求

解决方案必须实现什么目标？

在这里，我们定义了解决方案实际上必须能够执行的操作。我们的目标是在优化实施之前了解用户、预期行为、频率和范围。用户故事对此有很大帮助。这里的清晰度也使下一步变得更加容易，因为充分理解的功能和目标更容易转化为技术决策。

基本自动化

四、技术要求 我们怎样才能使解决方案成为现实？

数据库心脏直视手术

这是我经常看到的被跳过的步骤。热情的工程师被技术上的可能性冲昏了头脑，而忽视了客户的实际要求。

我们曾经花费了几次冲刺来完全自动化一个每个人都确信是必不可少的流程。最后，我们每月一次花费了 100 多个小时，将手动需要 10 分钟才能完成的事情自动化。

此外，还创建了一个漂亮的 UI。第一个问题是是否有 API 可用。他们本身就是开发人员，从来没有打算使用 UI。

跳过功能要求，您就有可能在客户需要自行车时交付一辆法拉利（带有法拉利价格标签）。

在打开 IDE 之前，请确保了解用户是谁、他们希望如何使用该解决方案以及使用频率。解决这个问题的对话需要几分钟，而重建需要几周的时间。

创建功能需求.md 并总结其中的所有需求。还添加用户故事列表，以确定某些用户打算使用该解决方案的对象、方式和频率。

有了前面步骤中的文档，大部分迷雾已经消散，您的技术选择方向应该相当清晰。尽管如此，仍然有必要将其转化为具体计划并做出深思熟虑的技术选择，将之前的每一步联系在一起：“我们的业务目标是X，我们现有的系统是Y，我们的功能需求是Z，所以这就是我们需要构建的”。

架构发生在构建之前，而不是构建期间。

跳过这一步，你就会对半成品进行心脏直视手术，在构建过程中改变方向，或者修补你应该在几个月前、午夜时发现的缺陷，以便在最后期限前完成。

我们选择 PostgreSQL，因为它是我们团队的默认设置。后来我们才发现，客户之间的领域模型根本不同，并且经常变化。我们已经将这些假设深深地编码到我们的模式和应用程序中。最终的迁移并不困难，因为 PostgreSQL 是一个糟糕的数据库。这很困难，因为我们在了解领域之前就做出了昂贵的架构决策。

经验教训：

适合工作的工具不是您最了解的工具，而是适合问题的工具。关于数据模型及其预期如何发展的一些对话将节省数周的返工和数据库迁移。

这一步是在组织的限制范围内选择最适合您的解决方案的技术。在 Technical-requirements.md 中总结您的发现及其背后的推理。对于每一个重大决定，都要问自己“如果我们做错了，以后改变的代价有多大？”

5. 治理

谁做什么、谁决定？

至此，业务问题、环境、功能需求、技术方向都已经搞清楚了。现在我们明确了执行的决策结构。如果没有治理，即使是最周密的计划也会因混乱、拖延和缺乏问责而瓦解。治理不是官僚主义，而是促成行动。

绕圈

一个项目停滞了数周，因为没有人知道谁可以批准关键的设计变更。该请求通过电子邮件链在三个团队之间传播，每个团队都假设其他人拥有该权限。当找到合适的人时，截止日期早已过去，导致客户失望和团队沮丧。

经验教训

6. 规划

何时、以什么顺序、由谁执行？

一团糟

当没有人确定谁发出呼吁或谁需要参与时，决策就会陷入困境，最终夭折。 RACI 矩阵或关于谁处于领先地位的简短会议可以避免数周的麻烦。

创建治理.md 以明确决策、升级、沟通和批准。包括一个 RACI 矩阵，其中详细说明了每个剩余决策的负责人、负责人、咨询者和知情者，以及如果他们所在的领域出现问题，早期步骤中的谁将继续参与。这些共同推动了项目的进展，而不是停滞在某人的邮箱中。

此时，您已经足够了解要构建什么、为什么重要以及构建它必须遵循的约束。现在，我们将解决方案分解为具有明确依赖性、时间表和所有者的可操作任务。目标是制定一个包含明确任务的路线图，允许代理或同事同时处理其中的许多任务，从而顺利到达终点线。

跳过这一步，您最终会遇到团队互相等待、任务太大或太模糊以及错过最后期限的情况。

我们开始了一个看起来很简单的项目，每个人都立即开始工作。没有人首先映射依赖关系：两个开发人员构建的功能依赖于尚未设计的 API。另一个团队针对后来更改的界面进行了集成。当我们发现问题时，几个人不得不停下来，撤消工作并按正确的顺序重做。

在任何人开始编码之前，我们可以通过弄清楚谁需要谁提供什么以及以什么顺序来避免堆积。良好的规划使依赖性、顺序和可交付成果变得明确和可见。就我们而言，这可以避免很多挫败感并浪费时间。

一个好的任务应该足够小，易于理解，有明确的结果，并使其依赖性明显。这使得人们或编码代理能够尽可能独立工作，而不是每个人都在同一个瓶颈后面排队。

将它们放在一起

实践中的框架

考虑一个想要构建人工智能辅助系统来处理传入案例的组织。最初的要求听起来很简单：“使用人工智能读取收到的文件，提取相关信息并自动决定如何处理每个案件。”

立即构建，但会以熟悉的方式出错。几周后，源文档变得不一致，关键数据存在于另一个系统中，案例工作人员实际上并不希望人工智能做出决策。他们需要帮助查找缺失的信息并确定队列的优先级。法律要求有人参与其中，但现在的架构很难添加这一点。该团队围绕无人检查的需求构建了一些技术上令人印象深刻的东西。

相反，运行整个框架，每一个惊喜都会在代价高昂之前浮现出来。

业务先决条件揭示了真正的问题：不是“自动决策”，而是“减少手动准备时间，同时让案例工作人员负责”。

IT 先决条件表明数据不一致以及解决方案必须适应的身份模型，然后任何代码才会依赖它们。

功能需求将范围缩小到分类、汇总和可追溯性，放弃了无人需要的自主决策。

技术要求从一开始就将人机交互和可追溯性构建到架构中，而不是稍后对其进行改造。

治理分配所有权，因此“人工智能可以决定吗？”在生产中询问之前已有答案。

结论

规划对工作进行排序，以便在团队扩大规模之前验证文档质量假设。

理想情况下，这些都不会比上面的版本花费更多的时间。它只是在实施之前而不是之后花费时间，因为撤销错误的假设不再便宜。

人工智能使实施成本降低。因此，决定实施什么变得更加重要。

人工智能使实施速度更快、成本更低。这种能力只有针对正确的问题才有价值。项目准备框架并不能消除不确定性，它可以帮助团队找到真正重要的不确定性并尽可能地处理它，同时这样做的成本仍然很低。它使最终的决策变得明确，并保留人类和人工智能代理在文档中对其采取行动所需的上下文。

优秀的工程从来不是编写最多的代码或花费最多的代币。现在比以往任何时候都更需要在约束下做出正确的决策，并将这些决策转化为创造真正价值的系统。代理软件开发并不能改变这一点，它只是增加了出错的代价。

在您的下一个计划中尝试项目准备框架。如果存储库出现问题，或者您有建议或改进或者想要分享战争故事，请在存储库中打开一个问题。