为什么建议先做核心功能快速上线，再根据反馈迭代？

结论：先做核心功能上线，不是把半成品扔给用户，而是先交付一条完整、安全、可监控的核心业务闭环，用真实行为决定后续投入。首期只做“没有它用户就无法获得核心价值”的功能，其余功能进入有依据的迭代清单。

未上线前，团队掌握的是访谈、假设和内部判断；上线后才看得到用户从哪里进入、在哪一步退出、哪些异常最常见、是否愿意再次使用。一次做满所有设想，会把预算同时押在大量未验证假设上，也让团队无法判断究竟是哪项功能产生了效果。

在把业务目标转成可执行范围时，还可以对照 营销活动功能应该在第一期全部上线吗？；这些内容补充了需要放在同一项决策中考虑的上下文。

三种开发方式直接对比

方式	首次交付	优势	主要风险	直接建议
一次做全全部需求	长功能清单全部完成后上线	视觉上“完整”	周期长、假设多、反馈晚、改动成本高	除强制整体切换项目外不建议
核心闭环 MVP	一条端到端业务可真实使用	快速验证价值、流程和技术风险	若把 MVP 理解成低质量会伤害用户	新产品和不确定项目优先
分阶段替换 / 灰度	新旧系统并行，按用户或模块迁移	可控制业务连续性和回退	需要兼容、数据同步与双轨成本	旧系统改造和高风险业务采用

什么才算“核心闭环”

电商不是只做商品列表，而是用户能浏览、选购、提交订单、完成支付，运营能履约和退款；IoT 不是只画设备大屏，而是设备注册、数据上报、异常告警和人员确认可走通；企业审批不是只提交表单，而是发起、审批、退回、通知和状态追踪完整。

首期也必须有登录权限、数据备份、关键日志、异常处理、隐私与安全、测试和必要后台。可以暂缓的是拼团、积分、复杂报表和次要角色，而不是删除支付校验、访问控制或故障恢复。MVP 的“M”是范围最小，不是质量最低。

怎样决定保留和暂缓

优先级	判断问题	处理方式
必须做	缺少后，核心用户能否完成目标？是否涉及法律、安全或数据底线？	进入首期并写验收标准
验证项	价值不确定，但可以低成本验证吗？	用原型、人工流程或小样实现
应该做	能显著改善效率，但不影响首个闭环吗？	放入上线后首批迭代候选
暂缓	只有想象价值、无用户证据或运营负责人吗？	记录假设，不排期开发

功能优先级不能由“谁声音最大”决定。每项需求写清目标用户、解决问题、预期行为、成功指标和不做后果。支付平台、应用商店审核、硬件联调等高不确定项应提前验证，即使它们不是用户最显眼的功能。

上线后用什么反馈

行为数据看激活、核心动作完成、错误、耗时、留存和功能使用；访谈解释用户为什么失败或绕行；客服和运营记录真实问题；技术监控提供性能与故障证据。不能只听少数意见就立刻加功能，也不能只看点击量忽略是否完成业务结果。

每个迭代选择一个主要问题，设定基线和预期变化，发布后在约定时间观察。影响安全、财务或核心数据的变更先在测试和灰度环境验证，并保留回退。没有数据支持的想法仍可尝试，但应明确它是实验，不包装成确定需求。

滚水科技会在需求阶段把功能分为首期核心、验证项、后续候选与不做范围，按里程碑签约和验收，并通过 透明交付标准 留出后续迭代预算。若项目必须一次完成监管、数据迁移或组织切换，我们会说明为什么不适合普通 MVP，而不是机械要求快速上线。

参考依据

• The Scrum Guide：用于参考以可用增量持续检查和调整的思想，不代表每个项目都必须采用 Scrum。
• 滚水透明交付标准：用于说明滚水科技的分阶段范围、验收与变更原则。

快速上线只是降低错误投入的方法，不是成功保证。若首期没有真实用户、运营负责人或可观察指标，应先补齐验证条件，而不是单纯压缩开发周期。