直觉：我曾四次有直觉，一次没有，以及由此产生的后果

这篇文章最初发表在我的博客smartpuffin.com上。

我有时会有这种感觉：直觉™。即使其他人都确信一切正常，但我还是会觉得项目、需求或功能可能存在问题。

当我察觉到这种感觉时，我就像一只嗅到气味的狗。我会循着气味不断提问，直到找到答案。

事情是这样的。

数据集扩展

我们的开发团队要求数据团队收集一些新数据，以扩展我们现有的数据集。我们原有的数据集包含 1000 条记录，现在需要 5000 条。我们向他们说明了我们希望如何安排优先级，双方也商定了时间表，我们都很放心地离开了。

第一个交付成果已经完成。他们发来一个包含1000行数据的大型共享电子表格。我们很高兴，因为这意味着我们很快就能拥有比以前多一倍的数据！

我编写了一个脚本，将所有这些新数据上传到我们的数据库。我发现数据中存在一些小问题，例如列混淆，或者数值列中包含字符串值，数据团队很快就修复了这些问题。没什么大碍。

一切准备就绪。我（真的！）正把手指放在回车键上方，按下这个键就能将数据上传到实时服务器。

但我犹豫了。我有一种预感。所以我没有按下回车键。

我问了数据团队最后一个问题（至少我当时是这么认为的）：

“我理解得对吗？这些都是全新的数据？上传之后，我们会有2000条数据，是这样吗？”

不，他们告诉我，他们决定在为我们收集新数据的同时，执行一个清理项目。这个电子表格中有600行需要更新，但只需要创建400行。

我花了点时间整理思路。之前竟然从未有人提起过清理工作。幸亏我问了！如果我当时上传了数据，就会出现600条重复记录。

我问道，如何从电子表格中分辨哪些是新增的，哪些是旧的？你们肯定有用于记录更新的ID列吧？

不，他们告诉我，根本没有这一栏。除此之外，没有其他解释。他们根本没意识到我们需要知道具体需要更新哪些项目——直到我问了才意识到这一点。

简而言之，经过多次讨论，他们为我们添加了 ID 列，标记了更新的项目，我们成功上传了所有数据。

但如果我当时没有那种直觉™，如果我没有问出这个问题，我们就会上传错误的数据，而且我们会在很久很久以后才发现这个问题。

平方英里转换

我在我们网站上看到一个功能，其中涉及到一些地理数学。我立刻就有了预感：肯定有漏洞。

事实证明我的判断是正确的，我们的网站上确实存在一个奇怪的漏洞，这个漏洞已经存在了 10 年，却一直无人察觉。

新 API 理念

我们的团队正在重建一款产品。原产品大约在15年前开发，之后的发展历程混乱不堪。

我的同事们对一个想法非常着迷。新的API旨在区分旧产品中相同的三种使用场景。

我刚加入团队不久，对这个想法也并非完全认同。我觉得自己理解得还不够透彻。我担心这对最终用户来说可能过于复杂。我估计要支持数据拆分需要大量工作，包括对现有数据进行分类以及确保向后兼容性。总之，我在新团队的头几天充满了各种猜测。

但我认为，我的同事们比我更了解这个领域，他们肯定已经考虑过所有这些问题。我假设他们在加入之前就已经估算过工作量并达成了一致。

他们向我保证，确实需要一些工作将现有数据归类到这三个用例中，但这相当简单。我团队里会有人负责这项工作，还会请另外两位数据专家协助。结果很快就会出来。与此同时，我们何不先着手实施呢？

我表达了我的担忧，但还是开始实施新的API。

一周后，我们开会查看数据划分情况。

负责数据分类的 3 位数据专家对每一条数据条目都存在分歧。

我问了他们一些问题，结果发现他们对用例的理解各不相同。而且，包括我自己在内的所有团队成员，对用例的理解也都不尽相同。

鉴于目前的情况，我的团队成员一致同意推迟该功能的推出，直到使用场景更加清晰为止。

如果我没有发现这些用例考虑得不够周全，我们就会向用户提供半成品，而且我们也无法向他们解释为什么要拆分这些用例。

两个团队之间的合作

我负责监督跨团队任务的实施。

问题在于许多地方使用不同的API来获取相同的数据。这些API的工作方式略有不同，返回的结果也不同。用户看到不同的数值，并对此表示不满。

任务是把所有东西都清理干净。这项任务的目的是：

1. 在所有地方都使用同一个 API，原因如下：
2. 我们希望统一显示方式。

开发者1在三个地方实现了新的API调用。不知何故，其中两个地方的调用覆盖了原有结果，并根据某些条件显示了不同的内容。

所以我们仍然面临着和以前一样的矛盾。这个解决方案勉强符合目的 1)，但完全违背了目的 2)。

Developer2 在我举例说明的一处地方替换了 API 调用。结果发现，代码中后续部分又根据另一个条件覆盖了结果。

此外，在 Developer2 的职责范围内，还有一处地方使用了旧的 API。他们没有注意到这一点，也没有对那里进行任何更改。

同样，这个解决方案部分符合第 1 点，但不符合第 2 点。

我是在替换另一个地方的 API 调用时才发现这一切的。提交代码时，我突然有了预感。由于这项任务非常复杂，而且涉及多人，所以我决定一次性测试所有更改。

我发现他们彼此之间都不一样。

经过这些努力，客户仍然对不同页面上的数据感到困惑。开发人员的时间白白浪费了一次。而且，如果我没有决定再次核查，这个问题可能要过很久才会被发现。

当我失败时

很久以前，我们正在实施一套新的GIS系统。我们之前的系统以UTM投影存储坐标，这意味着一次只能处理地图上相对较小的区域。

在新系统中，我们希望拥有整个世界的地图。

我们很快做出了决定：将坐标以经纬度的形式存储，并始终以这种方式使用它们。当需要将它们显示在屏幕上时，我们会根据需要进行投影。

我们接下来的决定是将地图分割成图块，以便在屏幕上显示。同时，我们也决定使用经纬度坐标。这似乎是合乎逻辑的。

我花了将近一个月的时间才把这些瓦片按照经纬度坐标排列好。在球面上进行数学运算太难了，我犯了很多错误。这简直耗时太久了。我就是搞不定。

看到我如此吃力，一位资深开发人员提议放弃所有这些，决定采用平面投影坐标系中的图块，使用我们客户最常使用的投影方式。

我勉强同意了，因为我仍然认为使用“真实”的球坐标系才是“正确的”。我删除了复杂的代码，只用了三天时间就写出了新的代码。从那以后，它一直运行完美。

当时我还没有预感™ ——正如你所看到的，因为我没有很好地考虑这个决定的后果——实施起来的数学计算有多么复杂——团队浪费了一个月的时间。

如何自己动手

我发现很多人在做决定和处理任务时，没有全面考虑各个方面，包括技术方面、产品方面、业务方面以及数据收集方面。

即使是看似简单小的任务，往往也远比表面看起来复杂得多。我曾为开发人员写过一篇文章，帮助他们在编写代码时提前考虑各种特殊情况。类似的建议也适用于其他类型的任务。

尝试从各个角度思考这个问题。它涉及到哪些其他人？是否需要更改现有内容，例如代码、流程或数据？它是否与其他所有内容协调一致？是否存在逻辑缺陷？

这就像测试一样。你要列出正面案例、负面案例和特殊情况；你还要测试你的更改可能影响到的其他类；你要向用户寻求帮助；等等。

先花些时间进行调查研究，几乎肯定会比仓促实施后失败更便宜、更快捷。

了解实际涉及的内容有助于你确定优先级。如果任务太大，你可能会决定先做一件小事。

有时，在权衡所有因素之后，你可能会决定接受这项有缺陷的任务。你可能会决定忽略某个问题，或者做出某种权衡。但无论如何，你都会做出一个经过深思熟虑的决定，而不是随波逐流。