scope-cutting

通过转换问题来缩小范围。不要问“这要花多长时间？”，而要问“这个问题值得投入多少时间？”先设定投入上限，再塑造符合上限的解决方案。这就是 Shape Up 的核心洞见：时间固定，范围可变。

设定投入上限

在确定范围之前，先明确时间预算：

• 小批次： 1-2 周，由 1-2 人完成
• 大批次： 小团队最多 6 周

如果项目需要超过 6 周（或按 Linear 方法，1-3 人需要超过 3 周），那就太大了。拆分项目，或者放弃。

投入上限不是估算。估算是说“这要花 X 时间”。投入上限是说“这件事值得投入 X 时间”。如果塑造出的解决方案无法满足投入上限，就缩小范围，直到符合要求，或者终止项目。

缩小范围

针对规范中的每一项，依次提出以下问题：

1. 必需项还是锦上添花？ 如果不交付这项功能，用户仍然能获得价值，那它就是锦上添花。删掉它。
2. 没有它也能交付吗？ 能否部署一个不包含此项的可用版本？如果可以，就从 v1 中删掉。
3. 边缘情况还是核心路径？ 如果遇到此场景的用户不到 20%，就推迟处理。
4. 与基准方案比较。 基准方案是完全没有这项功能，而不是理想版本。总是优先考虑“这比什么都没有好吗？”，而不是“这是否已经尽善尽美？”

进一步缩小解决方案

如果反复缩减后范围仍然太大：

• 缩小广度，而非降低质量。 与其糟糕地支持 3 种身份验证服务，不如把 1 种做好。与其覆盖所有错误状态，不如完整处理正常流程。
• 移除整个功能界面。 删掉设置页。移除仪表盘。采用合理的默认值交付，而不是提供可配置选项。
• 为边缘情况设定处理上限。 “我们会处理最多 1,000 行的 CSV 导入。超过这个数量，请发邮件联系我们。”在规模需要自动化之前，先手动解决。
• 问：“客户会感谢我们交付的最简单版本是什么？” 这就是你的范围。

熔断机制（Shape Up）

如果一个周期内无法交付，默认取消。不自动顺延。团队必须重新提案，争取下一个周期。这可以防止项目变成永远拖延的僵尸项目。

指南

• 关键：绝不要牺牲质量——要缩小广度。精心打磨、做好一件事的功能，胜过漏洞百出、做五件事的功能。
• 绝不要估算，要设定投入上限。说“这件事值得投入 2 周”，而不是“这要花 2 周”。
• v1 的必需项绝不要超过 5 个。如果超过了，说明范围还不够小。
• 始终与基准方案（完全没有这项功能）比较，而不是与理想实现比较。
• 始终问“我们能在[投入上限]内交付什么？”，而不是“多久才能把所有东西都交付？”
• 绝不要自动结转工作。未完成的工作必须重新提案。

---

基于 Shape Up（Basecamp）和 Linear Method 构建。技能来自 productskills。