MVP开发：真实成本、现实的时间表，以及扼杀创业公司的那些错误

最小可行产品（MVP）本应是验证一个想法是否真的可行的最快、最便宜的方式，然后再投入真金白银打造完整版本。但在实践中，MVP开发恰恰是大量创业预算悄悄消失的地方——不是因为软件开发本身天生昂贵，而是因为"最小化"被一点点谈判掉了，一次一个"就再加一个小功能"，直到MVP实际上变成了一个拥有MVP预算的完整产品。

下面是MVP开发实际的成本区间、真实需要多久时间，以及把四周的开发拖成六个月的那些具体错误。

MVP到底是为了什么

MVP的意义不是推出一个未来产品的缩小版，而是尽可能便宜、快速地回答一个具体、可证伪的问题——真实用户是否会做企业赖以生存的那件事（付费、复购、推荐给朋友、每天使用）。任何无助于回答这个问题的功能，都属于第二版的范围，而不是第一版——不管它在计划会议上显得多重要。

现实的成本区间

确切数字很大程度上取决于复杂度，但以下区间反映了一个被恰当界定范围的MVP——而不是被误称为MVP的完整产品——由外包或专属开发团队打造时的典型花费：

• 简单MVP（带候补名单的落地页、基础预约流程、单一功能工具）：通常花费不多即可实现，有时还能借助合适的无代码或低代码工具。
• 标准MVP（用户账户、数据库、一到两个核心工作流、基础管理后台）：这是大多数软件创业公司实际需要的区间，通常由小团队用几周时间完成。
• 复杂MVP（有供需双边的市场平台、支付、实时功能）：花费明显更高，值得认真重新审视是否每个组成部分都真的是验证核心假设所必需的。

现实的时间表

一个功能列表清晰、团队能力过硬的MVP，通常能在六到十二周内上线。而时间表经常翻倍甚至翻三倍——不是因为开发变难了，而是因为三种具体的、本可避免的模式。

扼杀MVP时间表和预算的三个错误

• 以"就再加一个小东西"为名的范围蔓延。每一次单独的追加听起来都合理；但第十五次追加，就是发布日期推迟两个月的原因。解决方法是在开发开始前就写下并冻结功能列表，其他一切另列一个单独清单。
• 为产品还不具备的规模而构建。MVP不需要支撑一百万用户，在还没有一个付费客户之前就为这种场景做工程设计，是把时间和金钱花在了企业目前根本不存在的问题上。
• 在"完成"之前不给真实用户看。MVP的全部意义就在于尽早获得反馈；等到打磨完美的版本再给人看，恰恰违背了这个初衷，通常意味着发现核心假设错了的时间，是在钱已经花掉之后，而不是之前。

选择MVP开发合作伙伴时该看什么

合适的团队会对范围扩张提出异议，而不是照单全收；会在写下第一行代码之前，先问清楚这个MVP具体要回答什么问题；并且会诚实地说明哪些功能可以留到第二版。一个对任何追加需求都毫无异议地照单全收的供应商，并不是在提供便利——他们是在放任预算和时间表失控，因为更大的范围也意味着更大的账单。

OutDept会围绕MVP真正需要回答的那一个问题来界定范围，并拒绝无助于这个问题的功能——因为一个在找到产品市场契合点之前就耗尽资金的创业公司，不会有第二次MVP的机会。