第 15 章 · 为什么你迟迟不发布
你在等的到底是什么？
不发布，作品就还停在「可能很好」；发布意味着它变成一个确定的、有缺点的东西。
- 这一章回答
- 你在等的到底是什么？
- 你会做出来
- 一份「还差什么」的清单，并逐条判断是否真的挡住发布
前两章给了你发布的标准和那句话。如果你照做了，这一章可以跳过。
如果你没有——东西基本能用，但链接还没发出去——那么这一章处理的就是你现在的状态。
机制
永远差一点。「再改一个细节就发」这句话重复了很多次。
它的机制和「活儿没干完」无关。
不发布的时候，作品处在一种特殊状态：它可能很好。 没有人用过，所以没有人能说它不好；你投入的时间还没有被定价。
发布之后，它变成一个确定的东西：有具体的缺点、有具体的反应、可能完全没有反应。那个状态比「可能很好」难受得多。
所以推迟发布推迟的不是工作量，是一次评判。而「再改一个细节」是推迟它最体面的方式——它看起来像勤奋，不像回避。
怎么分辨「真的挡住了」和「我不想」
对清单上每一项，问两个问题：
- 不做这个，别人能不能完成那件事？ 能，就不挡路。
- 这一项如果永远不做，我能接受吗？ 能接受但还是想做，说明它是偏好不是必需。
还有一个更直接的检验：把它发给一个人。 不是一个群，一个人，你认识的、真的有这个问题的那个人。
如果你连发给一个人都不愿意，那么你要修的不是产品。
现实案例
他的清单：批量上传、多格式导出、保存历史、分享卡片。
逐条过第一个问题——不做这个，别人能不能拿到逐字稿？四项答案都是「能」。
过第二个问题——如果永远不做，能接受吗？批量上传「不能接受，但那是有了用户之后的事」；另外三项都是「能接受」。
四项全部不挡路。他真正在等的是另一件事：他知道中文专名修正的准确率只有八成左右，而他不想让人看到那两成错误。
这件事清单上一条都没写。
这是最常见的情况：真正挡住你的那件事，往往不在清单上——因为它不是一个任务，而是一个担心。把它写出来，它就能被判断了。周言写出来之后发现，八成准确率对一个要花 26 小时做逐字稿的人来说，已经是巨大的改进。
动手试
做三件事：
- 列出清单，逐条过那两个问题。 划掉所有「能用」且「能接受」的。
- 写下清单上没有的那件事。 一句话：我真正担心的是 ______。几乎每个人都有这么一条。
- 把那句担心拿给一个目标用户判断。 不是问他产品好不好，是问「如果这个东西有 X 这个缺点，对你来说还有用吗」。
第三步经常会得到意外的答案。你介意的那个缺点，往往不是用户在意的那个。
你的行动
写出「还差什么」的完整清单，包括那条你没写进清单的担心。
逐条判断是否真的挡住发布。
然后发出去——至少发给一个具体的人。
检查标准
- 清单写完了，包括那条没写出来的担心
- 每一项都过了「不做能不能用」和「永远不做能不能接受」两个问题
- 真正挡路的项目为零，或者我正在做的就是那一项
- 我已经把链接发给了至少一个具体的人
容易搞错的地方
它看起来像勤奋。判断方法是看时间：同一句话说了几次？如果超过两次，它就不是计划，是模式。
周言介意两成专名错误，但对一个每期花 26 小时的人来说，八成准确已经改变了一切。
你对缺点的权重来自你盯着它看了很久，用户的权重来自他要解决的问题有多痛。这两个权重几乎从不相同。
本章自测
- 不发布时作品处在什么状态，发布改变了什么？
- 判断一项是否真的挡路，要问哪两个问题？
- 为什么「真正挡住你的事」经常不在清单上？
- 第 23 章 · 什么叫真的完成了 — 完成的定义