独立开发的完美主义：产品做到什么程度可以上线
type
status
date
slug
summary
tags
category
icon
password
wechat_gate
10 月 2 日，我花了不少时间设计语音转文本应用的 Logo。几轮微调之后，终于满意了，还在日记里写：往后很长时间应该不会再动它。
10 月 19 日，我又开始改这个 Logo。
这两条记录放在一起，有些好笑。单看每一次调整，都有理由；把半个月连起来看，我才发现，“再优化一下”可以没有终点。
独立开发的完美主义很容易藏在认真做产品的愿望里。图标可以更好看，页面可以更协调，功能可以再多一点。问题是，如果没有上线标准，每一个改进点都有机会推迟整个产品。
给第一版一个能结束的范围
那段时间，我同时推进几款应用。PDFMesa 的 Mac 版在 10 月 18 日记录了提交审核，10 月 26 日记录了审核通过。跑通这条流程，让我很有成就感。
但它只说明这个版本进入了商店。用户愿不愿意下载、能不能顺利完成任务、是否愿意付费，还需要继续观察。
这让我重新理解 MVP。它的全称是“最小可行产品”。对我而言，关键是选择一个足够小、又能独立成立的问题，把解决这个问题的过程做完整。
以 PDF 阅读器为例，假设第一版聚焦阅读本地文件，那么用户选中文件、打开、阅读、关闭后再次打开，这条路径就值得认真检查。至于更多主题、复杂工具栏、尚未确定需求的附加功能，可以另列计划。
这是一个示例范围，并非 PDFMesa 的全部功能说明。它想回答的是：这一版究竟承诺解决什么问题？
Basecamp 的《Shape Up》提出过“固定时间、可变范围”的做法：在时间受限时，缩小交付内容，给核心质量留出空间。我觉得它很适合用来约束独立开发者不断增长的愿望清单。延伸阅读：Set Boundaries
颜值值得打磨，也需要停止条件
我依然重视软件好不好看。图标、字号、间距和弹窗，会影响用户理解和使用产品。
但视觉问题也有轻重。小字号导致读不清、深色模式下按钮看不见，已经影响使用；两种都清晰的配色，究竟哪种更高级，往往还包含个人偏好。
如果把所有不满意都当成上线阻塞项，第一版就会不断扩张。
我给自己整理了三个判断问题：
- 这个问题会不会阻止用户完成核心任务？
- 它会不会让用户误解价格、权限或数据如何处理？
- 如果延后修改，用户要承担多大损失？
前两项需要优先处理。第三项帮助我安排剩余工作。一个细节应不应该挡住发布，要看它对用户的影响，不能只看自己今天有多在意。
一份能真正勾完的上线清单
回看这些记录，我准备把“差不多了”改成几项可以检查的事实：
- 核心任务跑通。 用真实输入走一遍主要流程，确认输出可用。
- 常见失败有交代。 空内容、无权限、网络失败等情况，用户知道发生了什么，也知道下一步怎么做。
- 收费与承诺一致。 价格、会员权益和商店说明对得上；涉及购买的功能，单独验证相关链路。
- 数据处理有边界。 保存、删除、同步等关键行为，不能只凭页面看起来正常就认定可靠。
- 审核材料完整。 截图、文案、测试账号和审核说明，与提交版本一致。
Apple 的审核指南也要求提交可正常使用的完整版本，并强调测试、元数据准确性和审核所需访问条件。提前列出这些事项，可以减少“代码写完了，提交时才发现还差一堆东西”的情况。参考：App Review Guidelines
这份清单也有边界。密码管理、支付、隐私等高风险功能，需要更严格的专项验证。“先上线”不能成为跳过这些验证的理由。
同样，构建通过、提交审核、审核通过、真实交易验收，是不同的完成状态。记录时分开写，才能知道接下来还欠哪一步。
我还没有解决完美主义。下一次看到更喜欢的图标，很可能仍然会心动。
但我至少可以先写清楚：这一版必须做到什么，哪些改进留给下一版。每多加一个上线条件，都问问自己，它能帮用户解决什么问题。
参考资料
- 026.11.04 23:40 沪 · 赵巷