规划指南 · SaaS 与 Web 应用
SaaS MVP 的范围怎么定
MVP 不是把所有东西做小一号，而是让真实用户能完整走完一条路径，并配齐这条路径需要的角色、数据和交接。
讨论你的产品范围中国江门。全球工作。
从一条完整路径开始
用用户的话描述这条路径：他带着什么进来、做了什么、带着什么离开。如果某个环节需要另一个人或另一个系统参与，它就属于这次的范围。
一个客户门户：接收请求、指派给团队成员、显示进度，这就是一条完整路径。一个塞了六个半成品模块的后台不是。
角色和权限要提前定
谁能新建、编辑、审批和删除？每个角色能看到哪些数据？等界面做完再定权限，通常意味着重做页面。
把每个角色用一句话写下来，然后以每个角色的身份走一遍主路径。这里发现的问题，成本远低于测试阶段才发现。
数据和对接决定报价
列出产品必须读写哪些系统，以及某个系统不可用时应如何处理。同时写清限制：调用频率、分页、认证方式，以及同步失败时该告诉用户什么。
如果已有表格或旧数据库，用匿名样例说明其结构。迁移工作量常被低估，原因是现有数据从来没有被记录过。
有意识地不做某些事
计费、报表体系、原生 App、单点登录和高级搜索，通常属于第二阶段。把它们明确列为不在首版范围内并不丢人，这恰恰让首版可被验证。
用书面形式确认首版不做什么，这样不会有人在验收时才发现边界。
写得出、验得了的验收标准
为每个路径环节写明预期行为和出错时的行为。再确定由谁签字确认，以及什么算作证据：录屏、测试账号还是一份清单。
这样写出来的验收标准，会把"感觉差不多了"变成双方一小时内就能做出的判断。
常见问题
MVP 应该有多少功能？
足够让涉及的每个角色走完一条路径，不再多。如果某个功能既不服务这条路径，也不是合规要求，它属于后续版本。
需要先做一套设计系统吗？
不需要完整的。先确定首条路径的核心布局、表单模式和组件状态，随产品成长再扩展。
MVP 上线之后怎么办？
在定范围时就把交接一并规划：谁负责运营、谁负责修复缺陷、数据如何备份、下一阶段如何排优先级。支持条款在上线前谈，比上线后容易得多。
接下来会发生什么？
- 梳理目标、用户与核心功能。
- 确认交付内容、美元报价与关键阶段。
- 开始合作前，确认双方责任与验收标准。