第 23 章 · 什么叫真的完成了
凭什么说这一轮算走完了？
完成有唯一判定，否则每个人都会用对自己最宽松的标准。
- 这一章回答
- 凭什么说这一轮算走完了？
- 你会做出来
- 对照六项判定，标出自己缺哪几项
「完成」如果没有唯一判定，每个人都会用对自己最宽松的那一套。
机制
六项全中的一轮 Build Cycle：项目定义、可用的实物、可访问的地址、做过的分发实验、外部反馈、基于证据的决定。
六项是与关系，不是打分。五项全中仍然不算完成——缺的那一项恰恰是你最该补的，给个 83% 只会让你觉得已经够好了。
这六项为什么是这六项：它们各自对应一个常见的停止点。
- 缺项目定义 → 做了很久说不清在做什么
- 缺可用的实物 → 一直在准备，没有东西能跑
- 缺可访问的地址 → 东西在本地，别人用不了
- 缺分发实验 → 发布了，没有人看到
- 缺外部反馈 → 有人看到，但你不知道他们怎么想
- 缺基于证据的决定 → 有反馈，但下一步还是靠猜
六项按顺序排列，每一项都依赖前一项。所以缺多项时，先补序号最小的那个——跳过去补后面的，补不上。
为什么不是「上线成功」或者「拿到用户」
因为那两件事你控制不了。市场、时机、运气都会影响结果，用它们定义完成，等于让一轮的价值取决于运气。
六项全部是你能控制的动作。走完它们，无论结果好坏，你都拿到了一个真实的答案——包括「这个方向不成立」这种答案。
现实案例
周言：定义有、实物有、地址有、分发实验做了（发给 12 个播客主）、外部反馈有（7 个试用，若干条意见）、迭代决定有（停止，并写明依据）。六项全中。
他的项目停了，但这一轮是完成的。他拿到了一个确定的答案。
林舒：前五项都有，第六项一开始只写了「继续优化」。
「继续优化」不是基于证据的决定——它没说要验证什么，也没说下一轮的范围。补上「缩范围：只做记住列映射」之后，第六项才成立。
一个停掉的项目可以是完整的一轮，一个还在做的项目可能一轮都没走完。这是 Verified Build 和「成功」最不一样的地方。
动手试
逐项对照，看自己缺哪几项。
勾的时候用第二栏的标准，不要用自己的理解。「可访问的地址」的标准是别人点开就能用，不是「部署过了」。
你的行动
对照六项，标出自己的状态。
缺多项时，只做序号最小的那一项。它是后面所有项的前提，跳过去补不上。
六项全中的话，直接去下一章写 Builder Review。
检查标准
- 六项逐项对照过，每项用的是它自己的标准
- 我知道自己缺哪几项
- 如果缺多项，我在补序号最小的那个
- 我没有把「差不多了」当成某一项达成
容易搞错的地方
五项全中给个 83% 会让你停在那里。那缺的一项通常是最难的那个——分发或者决定——而它恰恰是这一轮真正的价值所在。
六项说的是你做过哪些动作，不是结果好不好。
周言的项目停了，但那一轮完整，所以他下一轮会更快。这比一个做了半年、从未发布、因此也从未被验证过的项目有价值得多。
本章自测
- 为什么六项是与关系而不是打分？
- 缺多项时为什么要先补序号最小的？
- 为什么不用「拿到用户」定义完成？