scoping-cutting

范围界定与功能精简

运用 15 位产品领导者的框架，帮助用户有效界定项目范围并精简功能。

如何提供帮助

当用户寻求范围界定方面的帮助时：

1. 了解假设 - 询问他们想要了解或验证什么
2. 确定投入意愿 - 弄清楚他们愿意投入多少时间和资源
3. 找到必要的核心 - 帮助他们确定首个版本必须具备什么
4. 以学习为目标进行设计 - 确保范围能够带来快速反馈，而不只是快速发布

核心原则

看投入意愿，而非估算

Ryan Singer：“我们要反过来问：我们愿意花多长时间，才能真正完成一件东西？”设定固定的时间预算（投入意愿），并设计出能在预算内完成的方案版本。调整范围，不要调整截止日期。

MVP 是验证工具

Eric Ries：“MVP 只是针对我们想要验证的假设，找到最高效的方式，来确认假设是否成立。”MVP 不是低质量产品，而是验证特定假设的最高效方式。

把清单砍掉一半，再砍掉一半

Eric Ries：“列出 MVP 必须具备的功能，然后砍掉一半，再砍掉一半，再开始构建。”创始人总是高估什么才算“最低限度”。要真正达到基准，就必须大刀阔斧地精简。

固定时间，小型团队

Jason Fried：“我们对任何单个功能的投入意愿都不超过六周……所以我们必须想办法，在六周内由两个人完成最简单、最有效的版本。”限制能促使人找到创新的解决方案。限制团队规模，保持专注。

造滑板车，而不是车轴

Eeke de Milliano：“如果你要为汽车打造最小可行产品，就别只造轮子和车轴，先造一辆滑板车。”MVP 应该是较小价值主张的完整端到端版本，而不是更大方案中的一个不完整部分。

使用“绿野仙踪”测试

Crystal W：“这其实是一种‘绿野仙踪’式体验。我们不必构建任何东西。我协调了一批实习生，就验证了部分价值主张。”在投入工程开发之前，先通过人工方式验证价值主张。用人来模拟自动化功能。

未能按时完成的项目就终止

Jason Fried：“如果到了时限，山坡左侧还有工作没做完，也就是说我们还在往上推，还不知道要怎么做，那这个项目几乎肯定会终止。”如果项目没能在规定时间内完成，就让它终止，避免工作永无止境。

将转向选项纳入流程

Paige Costello：“我们在产品流程中加入了一个概念：路线图上的项目可能会转向或删减。因为一旦项目列入路线图，我们就觉得必须完成它。”正式确立删减或调整路线图项目的机制，避免陷入沉没成本谬误。

帮助用户思考的问题

• “你想用这个版本验证的单一假设是什么？”
• “你愿意投入多长时间，再发布某个成果？”
• “如果必须提前一半时间发布，你会砍掉什么？”
• “有没有办法先手动测试，再构建自动化功能？”
• “如果这个功能没能按时发布，你会终止它还是延期？”
• “最小的什么成果仍能提供完整价值？”

需要指出的常见错误

• 估算时间，而不是设定时间上限 - 问“这需要多长时间？”，而不是“我们能在 X 周内完成什么？”
• 打造车轴 - 发布大型功能中尚未完成的部分，而不是完成较小的功能
• 从不终止项目 - 延长截止时间，而不是缩减范围或取消项目
• 对 MVP 过度设计 - 在验证核心假设之前构建过多内容
• 忽视“绿野仙踪”原型法 - 明明手动验证更快，却总是默认选择开发

深入了解

如需查看 15 位嘉宾分享的全部 19 条见解，请参阅 references/guest-insights.md

相关技能

• 路线图优先级排序
• 不确定性规划
• 问题定义