第 13 章 · Ship 的标准低到你不敢相信
到什么程度就可以发出去了？
Ship 的门槛比你以为的低得多：有一个别人点开就能用的地址。
就这样。不是功能完整，不是界面好看，不是你满意。
机制
别人拿到一个链接，点开就能用，不需要安装、不需要配置、不需要你在旁边。
它是 Ship 的唯一标准。
把标准定这么低，不是降低要求，是把判断的权力从你手里交给现实。
作品没发布的时候，它的价值是一个开放问题——它可能很好，也可能没人要，而你倾向于相信前者。发布之后这个问题会有答案。推迟发布推迟的不是工作量，是那个答案。
一个链接，加一句话说明。
少于这个，别人没法用；多于这个，是在推迟。
发布之后仍然可以改
这是最容易被忽略的一点：Ship 不是冻结。发布之后你照样可以每天改。
区别只在于，改的依据从「我觉得这里不够好」变成「有人在这里卡住了」。后者的信息量是前者的十倍，而且只有发布之后才拿得到。
现实案例
做完主路径之后，他列了一份「发布前必须完成」的清单：支持批量上传、导出多种格式、保存历史记录、做一个结果页的分享卡片。预计三周。
三周变成六周，清单上还剩两项。
某天他重新看那份清单，逐条问「不做这个，别人能不能用」：批量上传——不能批量就一个个传，能用；导出多种格式——复制文本就行，能用；保存历史——用完就走，能用；分享卡片——和核心任务无关。
四项全部可以不做。
当天下午他部署上线，加了一句「把播客音频传上来，拿到带专名修正的逐字稿」，总共两小时。
那六周没有产出任何用户会注意到的东西。
动手试
列出你现在的「发布前必须完成」清单，对每一条问同一个问题：
不做这个，别人能不能用？
能用，就划掉。剩下的才是真正挡住发布的。
绝大多数人做完这个练习会发现清单只剩零到一项。如果你剩下三项以上，大概率是把「我不想让人看到这个样子」翻译成了「这个还不能用」——这是两件事。
你的行动
把作品部署到一个别人能访问的地方，拿到 URL。
写一句话说明：这是什么、给谁用、怎么开始。
用无痕窗口打开一次，确认不需要任何本地环境。
检查标准
- 有一个别人点开就能用的地址
- 无痕窗口打开能正常工作
- 有一句话说清这是什么、给谁用
- 用户不需要安装或配置任何东西
- 我的「发布前必须完成」清单已经清空或只剩真正挡路的
容易搞错的地方
前者是事实判断，可以验证：别人能不能完成那个任务？后者是感受，没有终点。
把清单上每一项归到这两类里，你会发现大部分属于后者。
Verified Build 六项里，可访问的地址只是第三项。发布之后还有分发、反馈、迭代决定三项。
很多人把发布当终点，所以发布后就停了——那一轮其实只走了一半。
本章自测
- Ship 的唯一标准是什么？
- 为什么说推迟发布推迟的不是工作量？
- 「不做这个别人能不能用」这个问题，为什么比「这个重不重要」有用？