做 MVP 之前该先定下什么

MVP 不是把路线图上每个想法都缩小一号。它是最小的有用产品：让一群明确的人完成一条重要工作流，并为团队的下一个决定提供证据。

「证据」这个词，值得停下来想一想。

CB Insights 的 创业公司为何失败的分析 （在新标签页中打开）发布于 2026 年 3 月，考察了自 2023 年以来公开停止运营的 431 家风险投资支持的公司。其中 70% 是资金耗尽，43% 是产品与市场不匹配。

更有用的是它关于失败 何时 发生的观察：「产品与市场匹配失败的案例中，有三分之二是从未找到市场的早期公司」。

钱是结局的方式，学得不够快往往才是原因。同样的道理也适用于企业内部工具：它的第一个版本应当证明有一条重要工作流变好了。

所以第一个版本不是你雄心的展示，而是一件用来弄清某件事的工具。下面这些决定，决定了它能不能做到。

MVP 不是什么

三种误读造成了大部分损失，值得在规划开始之前就点名：

• 完整产品的廉价版。 到处降低质量，最后留下的是没人能评判的东西。不如砍掉范围，把剩下的做扎实。
• 原型。 原型回答一个设计问题，然后就被丢掉。MVP 是有真实用户的真实软件，必须是可维护的。
• 永久的架构。 第一个版本应当是能改的。难以回退的决定，值得比其他决定花更多心思。

有用的问题不是「我们最少能做多少」，而是「我们最少要做多少，才仍然能学到某件会促使我们采取行动的事」。

你真的需要定制开发吗

在给定制开发划范围之前，值得先问一句：你现在就需要它吗。

当你的工作流确实特殊、当你必须拥有成果，或者当现成工具无法按你的业务方式连接起来时，定制软件才是正确答案。

而当一个无代码工具、一张电子表格或一款现有产品，本周就能让你验证同一个假设时，它往往是错误的第一选择。

一个有用的顺序是：先用最便宜可行的方式验证需求，等你清楚哪些部分真的需要定制，再去定制。

许多成功的产品，都是从一套人工流程或一组拼装起来的工具开始的。只有在拼装开始产生痛感的地方，它们才变成定制软件。

太早定制，会把预算花在证明一个更便宜的测试就能告诉你的结论上。太晚定制，则会让你一直和不再合用的工具较劲。

在开始划范围之前就诚实地回答这个问题，而不是之后。

从用户的工作流开始

在谈技术之前，先说清楚谁会用这个产品、他们处在什么情境、要完成什么任务。这里含糊，含糊就会一路跟到每一个页面和每一个功能。

把主工作流写成一段简短的序列。比如：客户提交一个请求，团队成员进行审核，系统记录这个决定，双方都能看到下一步。

英国政府数字服务局把这一步正式称为探索阶段。其 服务手册 （在新标签页中打开） 对先后次序说得很直白：「在你决定构建一项服务之前，你需要理解那个需要被解决的问题」。

它建议这段探索通常持续四到八周，并以一个明确的判断收尾：究竟是否存在一项站得住脚的服务。

一段有真正「继续／停止」判断的短期限定调查，比一个到第五个月才发现同样结论的开发要便宜。

定义什么属于范围之内

然后把非有不可的工作和以后再说的工作分开。登录、权限、支付、通知、报表、对接、后台管理，可能都重要，但第一版不需要把它们都做到同样的深度。

好的范围为每一项功能都给出理由。当一项功能满足下列任意一条时，把它留在第一个版本里：

1. 没有它，第一批用户就无法完成核心工作流
2. 它降低了一项你已经识别出的交付风险
3. 它从第一天起就给团队所需要的掌控力
4. 去掉它将迫使重写，而不是追加

如果一项功能一条都不满足，那它是一个以后再定的决定，而不是一次删减。这样记录下来，通常就能化解要不要拿掉它的争论。

决定你怎么知道它奏效了

在开发开始之前，先就什么结果值得继续、什么结果该转向、什么结果该停止达成一致。没有这一条，任何结果读起来都是鼓舞人心的。

选择你在真实使用的头几周里就能观察到的信号，而不是需要一年数据才能看出的信号：

• 不用手把手带，人们就能完成核心工作流
• 不用提醒，他们会再回来
• 产品所替代的人工工作明显减少
• 有人来要下一个功能，而不是一个基础的修复

写下你预期看到什么、到什么时候看到。把它和实际发生的对照，正是早发布的全部意义。

把「完成」的含义写下来

在开发开始之前，先定义「能用」是什么意思。使用可观察的验收标准，比如：用户能提交请求、合适的人能审核它、系统正确记录结果。

GDS 关于 编写用户故事 （在新标签页中打开） 的指引，把验收标准描述为「一份你当作检查表使用、用来确认服务已完成其职责的结果清单」，其中每一条都写成 完成的标志是…… 这样的陈述。

它的价值在于，没有参与开发的人也能核对。

在版本层面， The Scrum Guide （在新标签页中打开） 把「完成的定义」界定为「对增量达到产品所要求的质量标准时其状态的正式描述」。

无论你是否采用 Scrum，这个想法都是通用的。一条经过约定并写下来的质量底线，可以避免「做完了」在每个人心里意思都不一样。

在设计表结构之前先定数据规则

决定产品必须存储哪些信息、谁可以访问。隐私、权限、保留、备份与审计需求，在第一批数据库表和集成落地之前更容易规划。

对于处理欧盟境内个人数据的产品，按这个顺序来是法律要求，而不是偏好。

欧盟委员会关于 数据保护的设计默认原则 （在新标签页中打开） 描述了在处理设计的最早阶段就介入的措施，并要求默认设置做到「个人数据以最高的隐私保护水平被处理」。

欧洲数据保护委员会于 2020 年 10 月正式通过了专门的 第 25 条指引 （在新标签页中打开） 供你查阅监管机构的详细立场。

落到实处，这是一份该写下来的简短清单：你收集什么、为什么收集、谁能看、保留多久，以及别人要怎样才能让它被删除。

在设计数据库之前就回答这些问题，代价远小于事后再补。

审慎地选择技术与 AI

围绕产品及其约束来选择技术。现代框架可能很合适，但更好的选择取决于用户、数据、集成、交付需求，以及将来维护这套软件的人。

AI 值得同样的克制。在把它当成产品需求之前，先决定它是否支撑核心工作流、输出出错时会怎样，以及人如何复核或纠正它。

如今已经有可测量的理由需要谨慎。 2025 DORA report （在新标签页中打开）基于近 5,000 名技术从业者的回答，报告称「AI 的采用与软件交付稳定性之间仍然存在负相关」。

没有扎实测试与复核的更快产出，不会累积成更快的交付，只会累积成返工。

规划复核、权限与交接

在写第一行代码之前，就把评审节点排好。简短的演示、一份共享的任务清单，以及写下来、大家都看得到的决定，能让你在改方向还便宜的时候改方向。

美国政府问责署在其 Agile Assessment Guide （在新标签页中打开）中提出了风险层面的论据：带有持续评估的增量交付「可以降低资助一个失败的、或产出过时技术的项目的风险」。

从一开始就就归属与权限达成一致。项目应当有清晰的源代码仓库、有文档的环境、约定好的部署路径，以及一份不依赖某一个人私人账号的交接方案。

DORA 的 版本控制能力 （在新标签页中打开） 明确指出哪些东西属于其中：应用代码与依赖、环境创建工具、容器编排文件、云配置，以及提示词这类 AI 产物。

其给出的依据是：「研究一再表明，全面使用版本控制可以预测持续交付」。

GDS 的 版本控制指引 （在新标签页中打开） 补上了这条规则的另一半——复核：「每一次代码改动都由没有写它的人来复核」。

这些习惯合在一起，才让交接成为可能。如果重建系统要依赖某个人的笔记本电脑，你拿到的就不是交付物，而是一项依赖。

规划时间与预算

当范围合适时，一个聚焦的 MVP 常常可以按 6—8 周的交付窗口来规划。这是一个规划参照，而不是普适的承诺；集成、审批和未知的遗留系统都可能改变时间。

了解软件排期是怎么失准的很有用，因为它在两个方向上的偏差并不对等。

一项针对 5,392 个 IT 项目、发表于 Journal of Management Information Systems （在新标签页中打开） 的研究发现，成本超支遵循幂律分布，而不是正态分布。

多数超支幅度不大，但存在「一条厚尾，其中包含少量超支极端的项目」。按平均值做规划，会低估真正要紧的那部分风险。

这不只是创业公司的问题。GAO 的 联邦 IT 高风险评估 （在新标签页中打开）发布于 2025 年 1 月，其中记录道，联邦 IT 投资「过于频繁地失败，或者出现成本超支与进度拖延，同时对与使命相关的成果贡献甚微」。

而这是在每年一千亿美元以上支出的背景下。规模和预算解决不了这件事；范围上的克制与短反馈循环才可以。

为决策留预算，而不只是编码工时。调研、设计、开发、测试、上线、内容、第三方服务，以及上线之后的修补，都会加到“让第一版真正好用”所需要的工作量里。

一个具体的例子

设想一位想做预约平台的创始人：客户预约、服务方管理日程、双方付款并收到提醒，还有管理员统管全局。这是一款真实的产品，功能清单很长。

然而核心工作流很窄——客户找到一个可用的时段并预约，服务方看到这个预约。其余的要么服务于此，要么可以等。

一个有克制的第一版可能是这样的：

• 纳入范围： 服务方的可用时段、客户预约、一条确认，以及给服务方看的简单的即将到来的预约列表。
• 推迟： 应用内支付（起步阶段先手工收定金）、自动提醒、评价、跨服务方搜索，以及管理后台。
• 事先决定： 存储哪些客户数据、存多久，仓库归谁所有，以及作为验收标准，「一次预约成功了」到底指什么。

推迟清单并没有被放弃——它就是路线图。但先交付核心，才回答了早期唯一要紧的问题：服务方会不会保持日程更新，客户会不会真的来预约？

如果会，其余的就值得做。如果不会，再完善的支付集成也救不了它。

如何开始

目标不是预测一切。目标是让重要的假设显形、检验核心工作流，并搭起一个可以在不推倒已有工作的前提下改进的产品基础。

如果你有想法但还没有完整的规格，请从用户、工作流，以及你希望第一个版本支撑的那个决定开始。这三点足以开启一次有用的规划对话。