开发一个 MVP 需要多长时间？按产品类型划分的真实周期

复杂度是预测 MVP 周期最好的单一指标。我们在估算项目时使用三个层级。

同样的层级也决定了预算。我们关于 SaaS MVP 要花多少钱的文章给出了每个层级的价格区间。

产品类型与这些层级的对应关系相当稳定。下表列出常见 MVP 通常所属的层级；根据具体细节，您的产品可能上调或下调一个层级。

Telegram 小程序通常属于简单或中等层级。它在 Telegram 内打开，所以不需要提交应用商店，用户账号也直接来自 Telegram。

每个 MVP 都会经历相同的阶段，只是各阶段之间的重叠比简单列表所显示的更多。

• 估算。您的需求简报变成一份包含范围、周期和价格的方案。在 Sakura，收到完整的需求简报后，大多数方案会在 2–3 个工作日内发出。
• 设计。先是用户流程，然后用可复用的组件系统搭建页面，最后是可点击的原型。
• 开发。前端、后端和集成，并且每周都有一个可以点击体验的可运行版本。
• 测试。在约定的浏览器和设备上测试每个流程，同时检查性能和基本的无障碍支持。
• 上线。部署、数据分析、如有移动应用则提交应用商店，以及真实用户到来后的第一批修复。

设计和开发是有意交叉进行的。第一批流程一经确认，就开始开发，而其余流程还在设计中。

设计通常先开始，也比开发先结束，但两者不应该严格地一前一后。如果设计交出一份完成的文件就撒手不管，开发时往往会发现有些页面实现成本很高，于是几周时间都花在返工上。

解决办法是用开发人员将要搭建的同一套组件来做设计。这样，确认后的页面几乎已经做好了一半，问题也能在成本还低的时候解决。

例如，AutoIntel 是一款面向德国二手车市场的 B2B 工具，最初从产品设计和基于示例数据的交互式原型做起。客户带着团队把原型走了一遍，在估算数据采集之前就确定了哪些字段和筛选条件重要。这个顺序让开发中最昂贵的部分始终聚焦于界面真正需要的东西。

正在规划上线日期？发给我们一份简短的需求简报，我们会告诉您产品属于哪个层级，以及现实的周期是多少。

有些功能在需求简报里看起来很小，开发时却会多出几周。需要留意的有这些：

• 集成。支付、登录服务、CRM 和第三方 API，每一项都需要配置、错误处理和测试。
• 角色与权限。每增加一种角色，每个页面需要处理的状态就会成倍增加。
• 原生移动应用。这意味着第二套前端，以及应用商店审核。Apple 的 App Review 会在 24 小时内审核至少 50% 的提交，在 48 小时内审核 90%，但被拒后需要重新计时。
• 多种语言。每段文字、每条错误提示和帮助说明都要有各个语言的版本，版式也要容得下最长的那一种。
• 内容迟到。最后一周才到的文案、价格、法律文本和真实数据会卡住测试。
• 决策缓慢。一个问题等一周才有答复，建立在它之上的所有工作都会被耽误。

缩短 MVP 周期的办法是做得更少，而不是做得更差。以下决定最能节省时间：

• 砍掉整个流程，而不是砍掉打磨。把次要流程放到后续版本，而不是每个流程都只做一半。
• 先上线网页版。响应式网页应用能覆盖手机和电脑用户，而且不需要应用商店审核。
• 使用成熟的服务。托管结账页面、现有的登录服务和邮件服务，比自己开发更快也更安全。
• 快速决策。指定一个人负责确认设计，并在当天内回答问题。
• 尽早找少量用户测试。Jakob Nielsen 的研究发现，只需 5 名用户测试就能发现大部分可用性问题，所以多做几轮小规模测试，比做一次大规模测试更好。

CarPixly 是一个面向汽车广告的 AI 摄影工作室，在 iOS 版本还在准备时，就先在自己的下载页面以 APK 形式发布了 Android 版本。能上线的平台先上线，其他平台以后再加，往往是接触真实用户最快的途径。

如果启动前就准备好几样东西，前几周会推进得更快。这些都不需要技术背景：

• 一份简短的核心流程清单。上线时用户必须能够完成的一到三项任务，用通俗的话写出来。
• 一位决策人。能确认设计、并在当天内回答问题的人。
• 现有账号的访问权限。域名、托管、数据分析、支付服务商，以及您已经在用的任何 API。
• 真实内容，或者交付内容的日期。产品将要展示的文案、价格、法律页面和示例数据。
• 您的上线限制条件。让日期变得重要的活动、投资人会议或销售旺季。

准备好这些，估算只需几天而不是几周，设计也能从真实内容开始，而不是用占位文字。

周期很少因为开发人员打字慢而延误。延误来自开发周围那些做出或没有做出的决定：

• 项目中途范围不断扩大，却没有书面的变更流程。
• 一轮反馈要一周，而不是一天。
• 没人写下“完成”的定义，于是最后几周变成了争论。
• 集成在范围里只写了一行，而没有考虑真实的边界情况。

固定范围加上变更流程，能把这些问题大多控制住。具体做法见固定价格与按小时计费。

上线是第二个计时器的开始，而不是第一个计时器的结束。发布后的头几周，通常是整个项目最忙的时候。

真实用户会发现测试遗漏的问题，提出一些小改动，并以没人预料到的方式使用产品。上线后应立即安排一段短时间的修复和快速改进，再考虑任何新功能。

之后，工作进入稳定的节奏：根据真实使用情况制定月度改进计划。每个 Sakura 项目都包含明确的问题修复保修期，后续工作可以按月度计划继续，也可以交给您自己的团队。

在仍能验证您核心假设的前提下，越短越好。用 Lean Startup 的话来说，MVP 的意义在于“尽快开始学习”。

如果您的计划远远超出了复杂层级，请问问自己想学到什么，一个更小的产品能否让您学到同样的东西。很多时候，更早上线的单一流程就能回答最重要的问题。

准备好规划您的 MVP 时，告诉我们您的产品。您会收到一份包含范围、周期和固定价格的方案，并且每周都能看到产品逐步成形的版本。