那个花了几年的一分钟

我发现，很多软件都有一种奇怪的功能。它们没有写在需求里，也没有写在帮助文档里，只存在于用户之间。

「下载以后，记得先改成横向。」我们的系统就是这样。

生成的是一张很宽的表格。在线预览没有任何问题，真正麻烦的是下载以后。文档默认使用纵向页面，右边的数据会超出纸张范围。于是几乎每个用户都会重复同样的动作：打开 Word，把页面改成横向，再继续工作。

没有培训，没有说明。大家只是慢慢学会了这么做。时间久了，这甚至不像一个问题，更像软件的一部分。后来我才知道，这件事已经讨论了很多年，却一直没有进入开发。

问题演变

阶段	发生了什么
现象	用户每次下载文档，都需要手动改成横向才能阅读。
最初的假设	在线预览必须保持纵向，因此导出需要另一套横向排版。
发现	用户从来没有要求两套排版，他们只是想正常阅读文档。
重新定义	网页预览与导出统一采用横向布局。

更有意思的是，没有人觉得这件事奇怪。用户习惯了，客服习惯了，开发也习惯了。一个本来应该被修复的问题，慢慢变成了流程的一部分。

这些年，团队一直围绕着同一个前提讨论：网页必须保持纵向，而导出的文档必须变成横向。既然需要两套排版，实现自然会越来越复杂。于是它始终排不到最前面，也没有人认真拆开分析。

后来，产品负责人把这个用户反馈交给了我。分析的时候，我没有先讨论实现，而是重新问了一遍：

用户真正遇到的问题是什么？

答案其实很普通。用户并不关心网页是横向还是纵向，他们甚至不会思考排版。他们只是希望下载以后，可以直接阅读。

如果横向才是最适合这个表格的布局，那么为什么网页一定要保持纵向？奇怪的是，这个问题一提出来，就没有人能说出原因。那个默认存在了很多年的前提，突然变得没有那么理所当然。

于是，我们决定统一网页预览和导出的布局，都改成横向。

过了一会儿，我去问开发同事：

花了多久？

他说：

真正改代码，大概一分钟。

我有点意外。他笑了一下。

剩下的时间，都不是写代码。

功能任务要创建，开发分支要拉，代码要合并，冲突要解决。测试人员要重新写测试、执行测试、验证结果，最后才能一起进入发布流程。真正修改代码的时间，反而是整个交付过程中最短的一部分。

临走前，他又补了一句。

其实这个问题一直没人分析。

而且它也不算特别紧急。

我们一直觉得，实现会很复杂。

那一刻我突然意识到，复杂并不是从代码开始的。复杂，是从一个很多年都没有被重新检查的假设开始的。

回看

后来我偶尔会想起这件事。用户花了几年调整页面，团队花了几年讨论实现，开发花了一分钟改代码。

真正漫长的，并不是那一分钟。真正漫长的，是让一个组织重新相信：

也许，我们一直问错了问题。