网络应用开发：从 MVP 到发布，逐步进行

网站还是网络应用？了解您正在构建的内容

从区分开始，这将影响每一个后续决策。一个网站提供信息——人们阅读它，可能提交一个表单，然后离开。一个网络应用程序进行工作：用户登录，创建和更改数据，并在第二天回来继续他们停止的地方。一个软件即服务产品是一个你同时租给多个客户的网络应用程序，具有独立的账户和定期计费。

这不是一个语义游戏。这个标签决定了你的预算、时间表和风险。一个宣传网站可以在两周内上线。一个具有身份验证、角色、必须永远不丢失记录的数据库，以及必须永远不重复收费的支付的产品则完全是另一回事。

快速测试：你需要哪个？

• 如果核心价值是阅读内容，你需要一个网站。
• 如果核心价值是做某事——跟踪、计算、管理、协作——你需要一个网络应用程序。
• 如果你打算向许多客户收取该工具的订阅费，你正在构建SaaS。

大多数创始人在他们说“然后用户可以保存并返回”时发现他们需要一个网络应用程序。这句话暗示了账户、存储、权限和静态页面从未承担的支持负担。当你想要从头到尾构建这个时，一个全周期开发团队让你免于将五个各自拥有一个片段的自由职业者拼凑在一起。

产品发现和有回报的技术规范

在编写任何代码之前，你需要清楚用户是谁，他们雇佣你的产品来完成什么工作，以及你将如何知道它是否有效。这个阶段被称为产品发现，跳过它是软件开发中最昂贵的捷径。

发现回答简单的问题。今天谁有这个问题，他们用什么替代？如果有一个快速且可靠的工作流程，会让他们转变的是什么？他们需要什么条件才能付费？把答案写下来。模糊的目标会产生模糊的软件。

一个好的技术规范实际上包含的内容

一个技术规范并不是一本小说。它是一个工作协议。有效的技术规范描述：

• 用户角色及其允许查看和执行的内容；
• 关键屏幕及每个屏幕上可用的操作；
• 您存储的数据，以及保持其有效的规则；
• 您依赖的外部服务 — 支付、电子邮件、地图；
• 不可妥协的条件 — 法律、安全、性能 — 以可衡量的条件表述。

注意缺失的内容：像素级设计和框架选择。规范修复 意图，而不是实现。它应该让两个不同的团队大致构建相同的产品，并让您诚实地判断一个功能是否完成。

将发现视为一种投资，而不是一种形式。花一个下午去消除一个模糊的句子可以节省一周构建错误事物的时间。

MVP 范围：切割正确事物的艺术

一个 最小可行产品 — 最小可行产品 — 不是便宜的产品或破损的产品。它是提供真实价值给真实用户的最小版本，并教会你一些你无法从幻灯片中学到的东西。

困难的部分不是添加功能，而是削减它们。每个你发布的功能都是一个你必须设计、测试、保护、记录和永远支持的功能。因此，每个项目的问题是直截了当的：如果我们去掉这个，早期用户还会获得核心价值吗？如果是，去掉它，或者推迟到后面。

一个简单的范围界定方法

1. 命名你存在的唯一工作流程。保护它。
2. 列出其他所有内容。分为“该工作流程所需”和“可有可无”。
3. 发布第一个列表。将第二个列表放在一个你可以忽略的待办事项中。

从第一次发布中安全削减的常见内容：超过两个角色的角色层级、应用内消息、详尽的设置界面、原生移动应用和客户的分析仪表板。一旦需求得到证明，你可以逐个添加。

当我们像我们的工作一样界定早期发布时链接管理工具，这个学科是一样的：一项工作做得好胜过十项做得马虎。一个紧凑的 MVP 也能保持代码库足够小，以便你能快速改变方向，而你确实需要这样做。

选择技术栈：前端、后端、数据库、认证、支付

最佳技术栈是你团队能够发布和维护的无聊技术栈。新奇是你在凌晨 3 点遇到问题时所付出的代价。不过，一些原则可以帮助你做出明智的选择。

前端

对于一个有很多交互状态的应用——仪表板、编辑器、实时更新——组件框架是值得的。对于内容密集型产品，服务器渲染的页面加载更快，排名更好。许多团队选择一个同时支持服务器渲染和在应用需要时进行交互的框架。

后端和数据库

选择一个你团队已经熟悉的后端语言。关系型数据库是安全的默认选择：它强制结构，支持事务，并拒绝丢失你无法承受丢失的记录。只有在出现具体需求时才考虑其他存储——缓存、搜索、队列。

身份验证和支付

请勿手动处理身份验证或卡片处理。使用经过验证的身份提供者或经过良好审计的库来auth，并使用一个成熟的处理器来处理资金。他们已经解决了边缘案例——密码重置、欺诈、退款、税务——这些问题否则会消耗你的路线图。你的工作是仔细集成，而不是重新发明信任。

一个务实的规则：选择覆盖今天需求的最小技术集，同时留有明天的余地。每一个额外的工具都是另一个需要修补、监控和招聘的东西。

架构和可扩展性，用简单的语言

架构只是那些以后更改成本高昂的决策集合。把几个重要的决策做好，其余的就保持灵活。

从一个开始模块化单体——一个组织良好的应用程序——开始，而不是一大堆微服务。微服务解决的是大多数早期产品尚未遇到的组织扩展问题，并且从第一天起就增加了网络故障、部署复杂性和调试痛苦。你可以在稍后分离出一个服务，当真正的瓶颈告诉你在哪里时。

"可扩展性"的真正含义

可扩展性不是你提前购买的神秘属性。它是处理更多负载而无需重写的能力。实际上，它来自于一些习惯：

• 保持应用程序无状态以便你可以在负载均衡器后面运行多个副本；
• 将慢速工作——发送电子邮件、生成报告——推入后台作业；
• 缓存那些很少变化的昂贵内容；
• 在添加服务器之前添加数据库索引。

广告技术和市场使这一点生动。像广告网络这样的平台构建通过测量第一个并优化实际造成问题的查询来吸收流量高峰，而不是重建一切。过早扩展只是花钱解决尚未出现的问题的另一种方式。

仪表板、账户和日常使用的用户体验

消费者网站争夺第一次点击。产品争夺第百次点击。你的用户将生活在应用程序中，因此重要的体验是无聊且重复的：登录，找到东西，完成任务，信任结果。

为回访用户设计

• 确保每个屏幕上的主要操作明显且单一。
• 清晰显示状态——什么已保存，什么待处理，什么失败以及如何修复。
• 尊重空状态：新账户应该教导，而不是空洞地盯着。
• 保持导航稳定，以便形成肌肉记忆。

仪表板诱使团队将每个数字挤在一个屏幕上。抵制这种做法。一个好的仪表板一目了然地回答一个问题，并让用户深入了解其余内容。如果所有内容都被突出显示，那么没有任何内容是重要的。

账户和账单流程需要特别关注，因为它们涉及金钱和信任。市场如一个自由职业平台是否能让用户理解他们的余额、发票和权限，而无需发送支持邮件，这决定了生死。清晰不是装饰；它是留存。

安全性和你无法承受错误的数据

安全不是你最后添加的功能。它是一组从第一次提交开始就持有的默认设置。好消息是：大多数泄露来自一小部分可避免的错误。

• 永远不要信任输入。始终在服务器上验证，即使浏览器已经检查过。
• 使用参数化查询，以便用户文本永远不能成为命令。
• 仅以强哈希存储密码——绝不要以明文存储，绝不要可逆。
• 将每个操作放在授权检查之后——登录并不等于被允许。
• 通过HTTPS提供所有内容，并保持依赖项更新。

将数据视为一种责任

收集你所需的最少数据。你从未存储的数据无法泄露。对于你所保留的数据，知道它在哪里，谁可以访问，以及如果用户要求你如何删除它。定期备份——而且——这是人们跳过的部分——实际测试你是否可以恢复。你从未恢复过的备份是希望，而不是计划。

如果您处理支付或个人数据，则适用隐私和地区规则。请尽早为这些设计；将同意、数据导出和删除功能后期整合到成熟产品中是痛苦且昂贵的。

集成和 API：你的产品不是一个孤岛

现代产品的组装程度与构建程度一样高。支付、电子邮件、搜索、地图、分析、聊天——每一项服务都是其他人比您今年能做得更好的。您的价值在于连接它们的工作流程，而不是对每一项服务的重新实现。

防御性地使用集成

每个外部服务最终都会变得缓慢或宕机。为此做好计划。设置超时，谨慎重试，并以用户能够理解的方式失败。绝不要让第三方的故障默默地破坏您的数据或冻结您的应用。

设计您自己的API

迟早您会暴露一个 API — 对于移动客户端、合作伙伴或您自己的前端。一些习惯可以保持其理智：

• 在命名、结构和错误上保持一致，以便调用者可以正确猜测下一个端点；
• 从一开始就进行版本控制，以便您可以在不破坏用户的情况下进行演变；
• 对每个路由进行身份验证和速率限制；
• 在构建时进行文档记录，而不是之后。

将您的数据模型视为合同。一旦另一个系统依赖于某个字段，改变它就变成了一种谈判。这是保持表面小而深思熟虑的一个好理由。

测试和质量保证，在用户发现问题之前捕捉问题

测试并不是为了证明代码是完美的。它是为了能够在明天无所畏惧地进行更改。这种信心使得一个小团队能够在多年而不是几个月内快速行动。

一个合理的测试金字塔

• 许多快速单元测试对于必须正确的逻辑——定价、权限、计算。
• 更少的集成测试来检查你的部分是否协同工作——应用程序与数据库和支付沙箱正确对接。
• 一小部分端到端测试，走过用户实际经历的关键旅程：注册、完成核心任务、支付。

自动化你本来会手动重复的工作。手动质量保证仍然重要，但要将人力注意力保留用于判断——这感觉对吗，文案清晰吗——而不是为了第五十次点击同一个登录表单。

每当一个错误逃到生产环境中时，添加一个测试。错误是成群出现的；你刚修复的那个有亲戚。测试是确保同样的失败不会再次发布的方式，也是系统应如何行为的最便宜的文档。

发布和分析：上线而不失联

发布不是一个戏剧性的时刻；而是一个受控的序列。先发给自己，然后给少数友好的用户，再给更广泛的群体。每一步都能让你获得真实的反馈，同时任何错误的影响范围保持较小。

在发布之前进行监控，而不是之后

你无法改善你看不见的东西。在真实用户到来之前，设置三种类型的观察者：

• 产品分析 — 哪些功能被使用，用户在哪些地方流失，激活路径是什么样的。
• 错误监控 — 这样一个损坏的页面会提醒你，而不是一个发推特的客户。
• 性能指标 — 真实用户的真实加载时间，而不是实验室的数字。

在测量时尊重隐私：收集能够帮助决策的信息，而不是你技术上能够收集的所有内容。然后提前达成一致，确定一个或两个定义此版本成功的数字 — 激活、留存、转化 — 这样你就可以根据信号进行引导，而不是争论感觉。

发布后的第二天是产品真正开始的时候。观察，与用户交谈，并在添加任何新内容之前解决主要摩擦。

成本、时间线以及导致两者膨胀的错误

首先两个诚实的答案：没有人能从一句话的想法中精确定价一个产品，而这个数字的驱动因素更少是“有多少功能”，而是有多少不确定性和风险每个功能都需要承担的成本。标准登录费用不高；而定制的计费引擎带有按比例分配和税费则不然。

实际上驱动成本和时间的因素

• 范围清晰度——模糊的需求是最大的隐性开支。
• 与挑剔的第三方及其审批流程的集成。
• 非功能性需求：高可用性、严格合规、重负载。
• 设计雄心——定制界面的成本高于干净、常规的界面。
• 团队连续性——重启和交接悄悄消耗预算。

导致两者膨胀的错误

经典问题在每个项目中反复出现。第一天就为一百万用户构建。添加没人要求的功能，而核心却依然粗糙。跳过发现阶段，然后在返工中为此付出代价。选择异国情调的技术来提升简历，而不是产品。将安全和测试推迟到“稍后”，这个日期永远不会到来。

如果您想要一个基于事实的估算而不是猜测，最快的方式是进行一次简短的范围讨论。告诉我们一个重要的工作流程，我们可以制定一个现实的预算和时间表围绕它。

你的 MVP 发布清单

在您上线之前使用此作为最后的检查。如果您可以诚实地勾选每一项，您就准备好了。如果没有，您找到了下一个任务清单。

上线前

1. 一个核心工作流程在慢手机和快笔记本电脑上都能端到端地工作。
2. 注册、登录、密码重置和注销都能正确运行。
3. 支付经过真实边缘案例的测试：拒绝、重试、退款。
4. 每条路径都检查身份验证和授权。
5. 输入在服务器上进行验证；查询是参数化的。
6. 强制使用HTTPS，代码库中的秘密已被清除。
7. 备份自动运行，您已成功恢复一个备份。
8. 错误监控、产品分析和正常运行检查已上线。
9. 空状态教会新用户首先该做什么。
10. 您知道本周要关注的成功指标。

在发布后不久

• 在前两周内每天监控错误和性能。
• 与您最早的用户交谈，并记录下他们的确切话语。
• 在构建任何新东西之前，先解决最主要的摩擦点。
• 保持一个简短、无情的待办事项列表，并保护核心。

第一次发布是一个开始，而不是一个丰碑。发布最小的诚实版本，从真实使用中学习，让产品获得下一个功能。这个循环——构建、测量、学习、重复——就是耐用软件的实际制作方式。

常见问题