什么是 MVP，即最小可行产品？

今天再次带您谨慎地一窥我们的研发内部。我想说明我们如何着手新的开发项目。为此，我们有两种不同的方法。

我们直接开发这款应用

如果一款新应用的规模非常有限，那么开发风险就比较容易评估。成本较低，因为例如只需一名开发者在短时间内（不到一个月）进行开发。在这种情况下，我们确定一个功能范围，应用即被开发出来并面向公众发布。（link: phone-memos text: 电话备忘）、（link: meeting-cards text: 会议卡片）以及（link: herein text: Herein）便是如此。

功能范围对于「随手开发」而言过大

有时在对一款新应用进行初步讨论时，就能立即看出其规模将超出人月的界限。或者，如同（link: merlin-project text: Merlin Project）那样，产品具有战略意义。在这种情况下，我们称之为风险投资，自然会相应地更加谨慎行事。

在第一阶段，我们制作 原型图（在 Apple Keynote 中绘制的图像，呈现我们对应用的设想），并据此在脑海中模拟未来应用的操作与流程。但我们偶尔会触及想象力的极限，需要另一种技术手段：原型。

对我们而言，原型 是一个小程序，用于阐明某项特定技术、某个工作流程或仅仅一个概念。因此会开发许多小应用。由于这些测试应用的存续期非常短，我们力求快速达成目标。因此我们并不追求美观或整洁的编程。

在这一阶段，通常仍由我负责评估未来应用的财务方面：应用的开发将花费我们多少成本，以及我们能凭借它赚到多少。因为我常说：「七十年代已经过去了。我们无法只靠纯粹的热爱生活。」

总有一天，我们（希望）研究透了新应用的所有方面。届时会有一套展示外观的幻灯片。每当有必要时，新的或关键的技术都会在原型中经过测试，直至我们对结果满意为止。此外，还会有一份关于预期成本与期望收入的详细列表。然后我们便聚在一起（当然是通过 Zoom 远程），讨论我们的发现。

在这个环节，我们已经有很多新的应用创意被否决。可能是因为基础创意不佳、技术门槛过低，也可能是过高。而且，如果预估的用户数量过少，应用也不会被开发。当然，我清楚这些评估，即便是由团队共同做出的，也非常主观，未必在任何程度上与未来的现实相符。但总有一刻必须做出决定。

MVP 的发令枪

当我们对新应用的信心，以及开发它的动力达到足够高的水平时，我们便开始开发。

但此处同样需要谨慎。我可不想因为一次失误而拿团队的未来去冒险。而恰恰在此处，（link: project-management-glossary/risk-management text: 风险管理）的另一种机制开始发挥作用：制作一个最小可行产品。

据（link: https://de.wikipedia.org/wiki/Minimum_Viable_Product target:_blank text: 维基百科）记载，MVP 这一概念最早由 Frank Robinson 提出，并由 Steve Blank 与 Eric Ries 推广。其背后的理念直观且明显合理：开发一款仅配备最重要核心功能的新产品。借助该产品，便可在团队内部、战略合作伙伴乃至潜在客户群体的代表中进行测试，看是否存在对该产品的兴趣，以及预估的市场是否足够大。当然，与此同时也会测试应用的操作在既定假设下是否良好。

多年来，ProjectWizards 在开发中已确立了一种迭代式方法：

1. 依据制作好的原型图进行开发
2. 我们在小范围内查看结果，并判断其是否运作良好。
3. 如果不满意，对于软件中的较小问题，我们进行迭代；对于根本性的问题，则在原型图上重新绘制。

始终遵循一个准则：最快、最简单的途径决定做法。

就这样，MVP 的所有构件被逐步组装起来。从某个时间点开始，会有人（通常是我）开始试用这款新软件。

MVP 开发阶段的首次测试

尽管非常耗时，有时甚至非常令人沮丧，但概念与假设必须一再得到检验。也就是说，必须在新应用中使用示例数据进行操作。当然，起初它会在各个角落崩溃。但随着时间推移，情况会逐步好转。

到某一刻便会出现这样的问题：应当或必须在一个 MVP 上投入多少时间。对此没有规则，也没有规定。它会持续到您能为自己回答这个问题为止：这款新程序在真实环境中是否具备生存能力。

与最小可销售产品（MMP）的区分

最小可销售（或可上市）产品明显更进一步，至少在我的定义中如此。

MVP 仅供内部使用（包括若干关键人员）而构建，我还根本无法借此赚钱；而 MMP 则迈出了实质性的一步：这个版本可以销售。

与开源圈子的惯例不同，对我而言，一个 MMP 至少需要：

• 一个版本号 1.0
• 一份文档
• 一个网站
• 一个销售合作伙伴（App Store、Paddle 等）
• 以及更多

正因如此，我们也不使用 MMP 这一名称，而是称为版本 1 或 1.0。

从 MVP 到版本 1 的过渡何时发生

在我们这里，这是一个流动的过渡。我们确实会为 MVP 的定稿设定一个时间节点，而这反过来又正是版本 1.0 剩余功能开发的起始时间节点。

正如从图中可以看出的，它被规划为一个顺序流程。但在现实中，各阶段的界限有时会非常模糊。

MVP 何时算完成？

对此并没有真正确定的日期。如果我们判定对质量或功能范围不满意，那么我们就会继续开发这款应用，即便它只是一个内部版本。

如果您对这篇博客文章有任何疑问或希望参与讨论，欢迎您在我们的论坛中发帖。