你提出了一个看似简单的修改请求。也许是更新通知时间、更改报告筛选器，或者在表单中添加一个新字段。
在你看来，这可能只需要30分钟，慷慨一点也就一个小时。然后我给出了6-8小时的估算，你可能会想，“搞什么鬼？”
说实话？有时候，我真希望它能像表面看起来那样简单。
让我来解释一下实际情况。它比看起来要复杂得多。
为什么“小”改动并不小
你在表面上看到的，只是实际情况的10%。
假设你想更改任务提醒邮件的发送时间。“只要把它从今天改成明天就行了”，
当然，那可能只是一行代码。但是：
-
哪个系统发送这封邮件？
-
是否有其他地方对“截止日期”有不同的定义？
-
循环任务和一次性任务如何处理？
-
我们是否需要更新用户界面以匹配？
-
这会破坏经理升级邮件吗？
-
移动应用通知呢？
这一行代码的修改会触及系统的六个不同部分。
如果我们未能检查所有这些部分，一旦出现问题，你的运营团队就会不高兴。
会发生什么
当我们收到你“简单”的请求时，会发生什么：
第1小时：搞清楚这段逻辑到底在哪里。即使在 WeWeb 和 Retool 中，我们也需要找到逻辑所在。它是在工作流中吗？还是一个触发器？它可能隐藏在我们刚开始合作时的一个遗留集成中。这会浪费30分钟的搜索时间，前提是我们对系统还算熟悉。
第2-3小时：绘制出所有可能因这次修改而导致问题的地方。我们希望在解决你最初请求的同时，避免破坏其他功能。
第4-5小时：进行修改并测试。是真正的测试，而不仅仅是随便点两下。我们需要确保没有破坏其他任何东西。我们不能简单地推送一个修改，然后寄希望于一切顺利。
我们需要在预发布服务器上进行测试。通知是否正确触发？是否发送给了正确的人？如果这是你团队的内部工具，快速抽查一下（大约20分钟）就可以了。但如果是面向客户的呢？一步走错，你的客户就会收到垃圾信息。
第6-8小时：清理我们偶然发现的问题。既然我们已经深入其中，不如顺便修复其他三处用胶带勉强维持的地方。然后，我们进行部署。即使是低代码，这也不是即时的。这又需要15-30分钟。
为什么感觉比预期更糟
这种复杂性很大程度上是不必要的。它之所以存在，是因为：
-
系统在压力下快速构建
-
“快速修复”随着时间推移而堆积
-
没有人有时间清理基础
-
我们总是在救火，而不是预防火灾
在人们居住的时候翻新房子是很有挑战性的。你不能随便拆墙。
现在怎么办？
我们可以只做那一行代码的修改，并在2小时内完成，而不是8小时。但那样的话，下一个类似的请求也需要8小时。再下一个也是。
当系统过于复杂时，即使是最简单的修改也会变得困难。
我们需要彻底解决问题，而不是应用临时方案。
是的，前期成本会更高。但这之间的区别在于：
-
每次你需要小改动时都花费8小时
-
一旦我们清理好系统，同样的修改只需花费1-2小时
这不是什么光鲜亮丽的工作。没有新功能可以炫耀。但它决定了一个系统是为你服务，还是与你作对。
底线
那个“简单”的修改花了8小时，因为系统是随着时间发展起来的。它的复杂性从外部看不出来。
我没有虚报估算。我只是诚实地说明完成这项工作所需的实际时间。
主要问题不是“为什么这需要这么长时间？”，而是“下次我们如何才能加快速度？”