关于「完成」这件事

我有个项目，从 2023 年开始做，到现在还没做完。

它不复杂，甚至可以说很简单：一个给自己用的读书笔记工具。需求是我自己写的，一共三页。第一页是“核心功能”，只有四条。

两年过去，那四条需求一条都没变，但我一次都没把它跑起来过。

它一直卡在“差一点”

第一版做完的时候，我发现搜索的排序不太对。改排序花了三个周末，改完之后觉得界面太丑，又重做了界面。

界面做完，发现移动端体验不好，于是重新设计了响应式。响应式搞定，又觉得数据模型有问题，把存储层整个换了一遍。

换完之后，第一版的排序逻辑不能用了，得重写。

我没有意识到，自己一直在做同一件事：在接近完成的时候，找到一个新问题，然后回到起点。

后来我明白了，我不是在追求质量，我是在逃避“完成”。

因为完成意味着交付，交付意味着被评判。哪怕这个项目只有我一个用户，我也要面对一个事实：它做完了，就这样了。

而“差一点完成”是一个完美的位置。它既有进展感，又不需要面对结果。你可以一直说“还在做”，永远不用回答“做得怎么样”。

配图占位 · 3:2 · 写满批注的需求文档

去年冬天我给自己定了个规则：元旦之前，不管什么状态，必须能用。

规则里有一条很关键——不许加需求，只许删。

于是我做的事变成了：搜索排序不准？那就先按时间排。界面丑？那就用默认样式。移动端不好？那就先只支持桌面。

结果那个版本，我在两周内做完了。它很粗糙，但我每天都在用。

用了一个月之后，我发现真正需要改的地方和我原来想的完全不一样：我以为需要更聪明的搜索，实际上我需要的是更好的输入方式——因为记笔记的时候，我常常在地铁上，一只手拿着手机。

这个问题，在项目“差一点完成”的两年里，我一次都没发现。

现在我会跟人说：完成的价值不在于“有了一个成品”，而在于它开始产生信息。

没完成的系统，你对它的所有判断都是猜测。完成的系统，哪怕很粗糙，也会立刻告诉你哪里真的不对。

这个道理听起来很朴素，但执行起来很难。因为“再改一下”的诱惑是持续的，而“就这样吧”需要一次具体的决定。

那个项目现在还在用，界面依然很丑。

我偶尔会想改，但每次打开代码，都会先问自己一句：这个问题，是我在用的时候真的遇到了，还是我只是觉得它不够好？

大部分时候，答案是后者。然后我就关掉编辑器，去读书了。