MVP 软件开发：范围、成本与时间表

MVP 软件开发出问题的地方是范围会议，不是开发过程本身。有人说出「最小可行产品」这几个字，大家点头认可，接着送来的功能清单里却写着用户账号、后台管理面板、计费、通知、仪表板，还有一个移动应用。那不是最小可行产品。那是一个完整的产品，而它花掉的时间会是你心里那个数字的三倍。

真正造成损害的词是「可行」。多数团队把它读成「好到可以卖给所有人」，可它的本意是「刚好够用来判断到底有没有人想要这个东西」。

最省钱的范围测试： 对每一项功能，问问自己会因为答案不同而做出什么不一样的事。如果一项功能改变不了任何决定，它就不属于 MVP。后台管理面板不会告诉你人们是否想要这个产品；它只会告诉你，等人们想要之后，这个产品会更好管理。把它放到第二步再做。

MVP 软件开发到底是为了什么

MVP 存在的意义，是用真实用户而不是各种意见来回答一个问题。这个问题通常是：会有人为它付钱吗，或者会有人频繁到足以说明问题地使用它吗？

这就重新界定了什么该被放进去。你需要的是那条能证明价值的唯一路径，端到端跑得通，而且完成度要高到让一个真实的人不用你坐在旁边也能走完全程。在这条路径给出答案之前，其余的一切都是可选项。判断标准也很直白：把这条路径交给一个从没见过这个产品的人，看他能不能一次走通。

这也解释了它与原型的区别。原型是用完就丢的，回答的是一个设计问题，往往连能跑的后端都没有。MVP 则是面对真实用户和真实数据的生产代码，一旦答案是肯定的就可以继续扩展。把两者搞混，在两个方向上都很贵：要么扔掉了你其实需要的代码，要么精心打磨了一个马上就要丢弃的东西。

哪些要进去，哪些要等一等

要进去的： 核心价值路径、这条路径所要求的最小限度身份验证、如果问题是人们会不会付钱那就加上收款方式，以及足够看清用户实际在做什么的埋点。

要等一等的： 后台管理界面、超出一两种角色的角色与权限体系、通知偏好设置、新手引导流程、没有人提过的第三方集成，以及所有以「反正都做到这儿了」开头的东西。

有两样东西经常被砍掉，但其实不该砍。一是埋点，因为一个没有分析数据就上线的 MVP 回答不了任何问题，钱等于白花了。二是删除或更正数据的能力，因为真实用户第一天就会出错，而手动到数据库里做外科手术很快就会让人受不了。

最常见的范围膨胀就是后台管理面板，而它几乎总是可以避免的。头几周里，手工跑查询搭起来更快，在十个用户的规模下也完全够用。准备一个只读连接，再把几条常用查询存下来，基本上就能应付眼下所有的客服问题。等到人工支持用户成为瓶颈时再去做管理面板，而那已经算是一个不错的问题了。

英国的真实成本

MVP 的报价取决于它能做多少件不同的事，而不是它背后的点子。我们在英国交付中看到的区间是：

每天 £100 到 £200 的离岸交付会改变这道算术题，同时带来我们在软件开发外包 中讨论过的协调成本。我们的定制软件开发成本拆解 说明了推高每一档价格的原因。

几乎每一份 MVP 预算都会漏掉两项成本。第一，上线之后总得有人来运维它，这是一个真实的月度数字，不是四舍五入的零头。把主机、监控、告警值班，以及依赖库的升级都算进去，才是这笔钱的完整样子。第二是第二个版本，因为如果 MVP 很好地回答了它的问题，紧接着的下一步就是在它之上继续搭建，而一份到发布为止的预算，恰好在你刚弄清楚该做什么的那一刻就花完了。

那个把三个月变成九个月的错误

为一个你还没有的规模去建设。

这种本能可以理解。没有人愿意写以后要替换掉的代码。于是 MVP 里加上了消息队列、缓存层、水平扩展和微服务边界，在五十个用户的规模下没有一样是真正承重的，可它们全都得在第一个人看到产品之前建好、测好并且运维起来。

诚实的说法是：MVP 完全可以在架构上很无聊。一个数据库、一个应用、简单地部署上去。如果它成功了，你会在真正知道负载落在哪里之后重写其中一部分，而那次重写会比你上线前的猜测更便宜，也瞄得准得多。

例外是那些以后改起来很贵的东西：你的数据模型、你的身份验证方案，以及任何触及个人数据的决定。在一开始就把这些大致定对，值得多花一周，因为它们正是日后拆解代价最高的部分。

如何在一个下午里定好范围

写下描述用户能达成什么的那一句话。如果这句话写不出来，问题就不在范围上，而在于你还没想清楚要验证的到底是什么。然后列出这句话所需要的界面，别的什么都不写。对剩下的每一项功能，套用本文开头的那个决策测试。

然后还是要把清单再砍掉三分之一。每个团队在第一轮都会把范围定得过大，而你现在删掉的那三分之一，几乎总是你在上线之后会删掉的那三分之一。

定一个日期，而不是一份功能清单。一个真的发布出去的三个月 MVP，比一个到第七个月还说「再有两周就好」的五个月 MVP 更有价值，而一个固定的日期会逼着范围讨论提前发生，那时候它还很便宜。

Mecanik 通过我们的软件开发 团队来界定并构建 MVP，包括由某个人劝你放弃后台管理面板的那一部分。如果你手上有一份功能清单却没有日期，那就从这里开始。

相关文章: 英国定制软件开发：买家完整指南 、英国金融科技软件开发：FCA、支付轨道与成本 、2026年如何构建Web应用：英国开发者指南 、面向代理机构的白牌网站开发 。

常见问题

MVP 应该包含什么？ 端到端跑得通的核心价值路径、这条路径所需的最小限度身份验证、如果问题是人们会不会付钱那就加上支付，以及足够看清用户实际在做什么的埋点。后台管理面板、角色体系、通知偏好设置，以及没有人提过的第三方集成，全都要等到 MVP 回答完它的问题之后再说。

在英国做 MVP 软件开发要花多少钱？ 单一路径、只有一种用户类型的 Web 应用，通常是六到十周内 £15,000 到 £35,000。两种用户类型加上支付和基础管理功能，通常是三到五个月内 £35,000 到 £75,000。带第三方集成或合规要求的多边产品，起步价在 £75,000 左右，需要五个月甚至更久。

原型和 MVP 有什么区别？ 原型是用完就丢的，回答的是一个设计问题，往往没有能跑的后端。MVP 是面对真实用户和真实数据的生产代码，一旦答案是肯定的就可以继续扩展。把两者搞混在两个方向上都很贵：要么丢掉了你需要的代码，要么为一个马上要扔的东西做了过度设计。

做一个 MVP 应该花多长时间？ 单一路径的应用是六到十周，一旦加上第二种用户类型和支付就是三到五个月。如果你的估算超过五个月，范围几乎肯定已经大于一个 MVP，值得在动工之前而不是之后就先砍掉一部分。

MVP 最常见的错误是什么？ 为一个还不存在的规模去建设。消息队列、缓存层和微服务边界在五十个用户的规模下不承担任何真实负载，却都必须在发布前建好、测好并运维起来。MVP 完全可以在架构上很无聊。例外是数据模型、身份验证，以及任何触及个人数据的部分，这些以后改起来很贵。